Cybearg

Ah, I see. Are 64 cards enough for a decent set of background tiles, or is it pretty limiting? Reusability is obviously going to be very important. Alright, awesome! Will that bankswitching be an option for burned carts as well, or only on the Flash Cart? And what kind of sizes will be available then? Right, I am making list files. I just don't know where it specifies how many bytes are free/used. Does it specifically state it somewhere? I figured it out. I didn't realize that IntyBASIC has such dynamic memory management. In batariBasic, you have to specify specifically what memory locations are being mapped to variables. For instance: DIM my_variable = $50 This would map "my_variable" to the memory location $50. This could then be used as a single variable: my_variable = 9 REM this would cause $50 to hold 9 Or as an array, if referenced like so: my_variable[0] = 5: my_variable[9] = 9 REM this would cause $50 to hold 5 and $59 to hold 9 Apparently in IntyBasic, you only DIM arrays. You don't DIM single variables and instead just dynamically assign them, like so: DIM my_array(3): REM 3-index array my_variable = 1: REM creates a new variable and gives it the value 1 It's just a bit different than what I'm used to. The dynamic memory management is awesome, though! Yes, please! That would be great! Aw... Well, maybe you'll think of an efficient way to add that in. It's awfully convenient. So sprites count against the memory available for background cards?

So then there is no bankswitching and no possibility of future bankswitching, but by using those valid areas (that are otherwise left empty?), you can get up to 48k from the main 16k + 4 x 8k? If I understand between the manual and what you say later, there are 64 pre-defined ROM cards, and then the rest of those 256 ROM cards (which act as background tiles) can be defined in the game ROM, correct? With an additional 64 in RAM that can be modified during game operation for dynamic backgrounds and such? Is that the same as the 64 GRAM cards, or is this something different? How is that done? The assembly file will be a lot larger than the compiled binary, but don't binaries come in standardized sizes with junk code to fill the empty space? 2600 ROMs are always 2, 4, 8, 16, or 32k, so you can't tell by looking at the file size how much of that is filler and how much is code. So you can't define something like DIM my_variable = 30 and it always has to be in arrays? I just mean, is there a way to define a value in binary rather than hex, decimal, or character? I have no idea how I would implement that myself. In batariBasic, you can define a value in decimal like a = 10, hex like a = $0A, or binary like a = %00001010. Being able to handle numbers in binary is very convenient when visualizing bitwise operations. No, I don't think I explained it right. In batariBasic, you can define individual bits like so: def lowest_bit=a{0} def highest_bit=a{7} ...and then use them like: if highest_bit then lowest_bit = false It was very convenient. Can that be done here? Alright, I'll check it out. Does using 8x16 sprites halve the number of cards you can have, then, or is there no impact? Well, at least there's two! That should be enough for quite a few interesting things. I've got the latest. Just downloaded it yesterday!

I just looked over the manual. Very exciting stuff! Can't wait to try it! I have a few questions, though: Is there any form of bankswitching, or are we limited to the 16k available in the $5000 to $6fff range? The 8k in $D000-$DFFF and $F000-$FFFF are meant for just graphics, correct? Would defining graphics in this area allow the program to automatically find them when referenced, or will something special have to be done? The manual mentions "characters", "cards," and "sprites," but doesn't make a clear distinction between what they are. What is the difference, exactly? Can they all be custom-defined? Is there (or will there ever be) the possibility of multicolor sprites, like how some kernels of batariBaisc for the 2600 can do different colors per sprite line? Is there any way to look at the value of a character/card that has been defined in the background? For instance, let's say I made a platformer out of characters/cards/tiles/whatever and I wanted to react differently depending on what the player sprite collided with, like spikes, water, lava, ground, ice, etc. How would one interface with the Intellivoice module? Is there any equivalent to the AtariVox's saving capabilities with the Intellivoice or other product? I know the manual mentions that there is currently no way to tell if you're running out of memory or ROM space. Could that be changed in future releases, particularly with the ROM? I'm uneasy with the idea of suddenly being all out of space. The manual mentions dimming arrays, but surely single values can be dimmed as well, right? Would that take the form of a one-index array, or as defining an array without the index? The manual describes how to display decimal, hexadecimal, and characters, but how would one displaying binary values? Can one define a label for individual bits, as with batariBasic's DEF function, to turn a byte into 8 easily-readable booleans? If one is comparing a boolean value, such as IF A = TRUE where A is 35, does it return any non-zero value as true? If I understand correctly, Mode 0 limits you to 4 colors for the background that you define from the 16-color palette, but you get access to more "cards", while Mode 1 gives you access to more colors, but at the cost of far fewer cards? How many possible cards are lost with Mode 1? How big are the cards? 8x8, I assume? How much of the screen is actually used by IntyBasic? batariBasic, for example, shows the contents of the screen in a sort of letterbox, probably due to timing limitations. Can IntyBasic display full screen content, or is it likewise limited (and if so, by about how much)? How does one actually define sprites, or are they defined as cards (as the syntax seems to imply)? How would this work for sprites that are 8x16 if cards are 8x8? Can background cards contain multiple colors? If so, how would the different colors be defined? If not, then can cards somehow be overlayed in the background to create the impression of multiple colors, or what options are there? I'm sure I'll think of more questions, but that's a start.

I hadn't heard of IntyBasic. Now I'll have to check that out! If you're just starting, I'd recommend 7800basic before batariBasic, though. batariBasic (for the 2600) comes with so many limitations, it's more about trying to get a decent game to work out rather than making your dreams come true. 7800basic gives you the power of something close to the NES, but with very easy-to-learn BASIC. Probably because it doesn't have a 6502, so it doesn't have the familiar 6502 Assembly, and I haven't heard of any good C alternatives for it (though if you have, let me know!).

What about the 7800? EDIT: My question is answered in the link as an apparent "yes".

Maybe someone else explained this already, but the score does that because once the score reaches its max/min values, it wraps around to its max/min values: -1 becomes 999999 and 1000000 becomes 0, since it can't hold any more/less information. I assume it probably uses 3 Binary-Coded Decimal numbers to display its score. Theoretically, since those 24 bits can hold a number up to 16,777,215, there should be a way to show/handle numbers using the non-BCD format. Then you could use the high bits of the high byte to capture whether the number is positive or negative and, bam! You've got a 3-byte signed integer. It would probably take a lot of careful Assembly to do it this way, and it might gobble up a good chunk of processor cycles. Alternately, I guess you could just tweak the score display code a little to check a separate bit for the sign and the append a negative sign and count up if negative.

Same problem here, except with being employed. After a day of work, I'm more inclined to procrastinate than program.

This is what I say, too.

When working with batariBasic, there are some limitations that come into play; the games all have the identical 6-digit score at the bottom of the screen and a handful of other modular options, but one can tell that it's a batariBasic game at a glance. What sort of limitations of that sort does 7800basic have? Although I know that it must be limited compared to what a pure Assembly game can technically achieve, visually and technically speaking, are there any big hurtles to making the game look/do pretty much anything one wants (within the technical limitations)?

It even has a female protagonist, so you'll be hitting the latest fad as well.

It looks like this line: player0x=50:player0y=50 Might be missing its leading space? Alternately, try including all those declarations within the loop and see if that helps. Some kernels can be finicky about not putting declarations in the drawing loop.

But now we don't have to, because 7800basic!

Thanks for all the advice from both sides! I guess I'll see if I can at least prototype my idea(s) in the 2600. If that goes well, I might get some feedback and decide where to go from there. Not only does my idea have some gameplay that may be a bit complicated to translate to the 2600, but the tone may be a bit more serious than is typical for these kinds of whimsical games. I dunno...

Clearly Jim Davis searches Google for obscure links to Garfield. I doubt that he remembers a licensing deal from 1984 for a 2600 game that never came to be.

I'd love to make another homebrew game, but I have somewhat limited time now that I have a full-time job. Still, I have a couple ideas in mind--mostly action-platformers or Zelda 2-style RPGs (because they look like they'd be fun to make). I was wondering: would it be more worth making a game for the 2600, or a game for the 7800 (using batariBasic and 7800basic respectively, of course)? I'd kind of like to make both, but is the 2600 market oversatured at his point?

Aren't you worried that you might be making a bad reputation by putting out proposals for such early-stage games? If, a year or two down the road, you had solid experience and a great idea and then you tried to pitch your concept for funding, people may be wary of donating because they can see from your Kickstarter profile history that you tried Kickstarting an unfinished game that failed to meet its goal.

I got an OUYA, but have mostly just used it as a PLEX media box. It works alright for that. Overall, OUYA has a lot of problems, in my opinion. While I really love the physical design (the box and controller look and feel nice and I love the OUYA controller's battery compartment designs), about everything IN the system irks me. In my experience, many of the apps are buggy or slow/prone to stuttering. On top of that, the OS's GUI is an absolute mess and very frustrating to navigate. And, of course, it's very lacking in quality games. What may be the worst thing is how oblivious OUYA is to its own shortcomings. It is showy as hell, reminding you at every opportunity that it's a game-changer and so amazing, when in reality it's poorly designed on many fronts and largely irrelevant. It will only become more irrelevant as major consoles open up to more indie stuff (like the PS4, PS Vita, and Nintendo DS have with games like Shovel Knight) and the "media box" functionality gets taken over by more specialized, smaller options like the Chromecast. People say that OUYA is a "retro box," but I never understood that. Hook a 360 controller up to any PC with Windows XP or later and you've got a retro box+. Why would I want a dedicated console to playing those things when my computer could do it, instead? In my opinion, OUYA fills a ghost niche. People thought that they really needed the OUYA, but then they discovered that they didn't.

Thanks, guys! Let me know if anything's wrong. It MAY not be available for tablets, but I'm not sure. I'd like it to be, but I might have to release a patched version with ultra-high-res graphics before it will pass Google's tablet app requirements (currently the graphics max at 1080p). Thanks so much for the response! I greatly appreciate any feedback, particularly in the Google Play store, and any retweeting or sharing of the game is that much better! I'm glad to hear that the difficulty curve is good. Assuming you're playing the full version, the first time you play you will only ever be given colors from the inner-most row of blocks--never anything beyond. However, once you beat the first 23 levels and unlock new game plus, you can get colors for any block that's exposed. That is, if you break away a few blocks from the first row, you may get colors from the exposed blocks in the second row. This makes it a bit more challenging for people who have mastered it the "easy" way. Heartbreak was originally conceived during the 2013 Game Jam (the heart theme of Heartbreak was the theme for Surgeon Simulator as well). Then, for whatever crazy reason, I decided I wanted to try making it for the 2600, to prove how simple, yet elegant the game's design was. I'm really glad I did--the gameplay got a couple major overhauls thanks to my work with the Atari 2600 version. Also, those of you with an ear for retro games may recognize the Android version's sound effects...

If I can be perfectly frank, there are a number of reasons I see why your Kickstarter has gotten down to 68 hours remaining (at the time of this writing) with only 85 dollars to show for it (by the way, I would be delighted if I could earn 85 dollars off of my own game, Heartbreak, but I don't think that's likely, so feel fortunate that you have that much support). First off, as mentioned already, all we see is placeholder art. First impressions are lasting impressions. On top of that, you didn't even record the video with FRAPS or something, instead opting to point your camera at your monitor like the most amateur of let's players. Secondly, you don't inspire confidence in your game. You talk about how things need work and look wonky, then your updates boast that an elementary school child is one of the programmers. You never say what's awesome about your game, and you never imply that you have the skill, experience, or vision to actually create something worth backing. Third, you don't demonstrate why the game is fun to play. The first level is you running without stopping, firing a hail of bullets, and nothing stands in your way. If you put a rock on the right arrow and fire keys, it's like the game could play itself. That doesn't seem engaging or interesting, to be perfectly honest. Granted, there are games that are just about annihilating tons of enemies, but those games tend to have a lot of visual and auditory flare to create a strong, cathartic experience. The music, construction paper-y style, and overall ease of gameplay makes this look very not-challenging and not especially satisfying, either. For a good example of crude graphics with fun gameplay, look at Two Finger Death Punch. Finally, you never explain what you need five thousand dollars FOR. Do you need it to purchase some important toolset or something? What happens if you don't get that five thousand dollars that you are asking for? Realistically, your game isn't even in the alpha stage. It's more of a prototype. It could have been made during a 48-hour Game Jam. It needs a lot more time and a lot more polish. If you want my advice, I'd suggest finishing the game on your own time and your own dime, then promoting it on Greenlight and other places. Once you release a game or two with some following, then you are in a position to possible succeed at Kickstarter. Please don't be an example of why people call Kickstarter and Greenlight a haven for scammers.

Thanks for everyone's replies! Heartbreak just got its first two reviews posted today: “It’s a smooth mother with great looks, a lot to offer the causal gamer, and plenty of interactive action to boot.” – AndroidAppsReview.com “Difficult, but good-looking and sounding and with plenty of modes and levels, Heartbreak is a tricky little gem of a game.” –TheSmartphoneAppReview.com I'll have to look into the possibilities. Thanks for the request! I'm a bit limited in some ways as Heartbreak was made in Gamemaker, so I don't have direct control over the source code, but I'll see if I can put it on the Amazon and Humble Stores. I'm not sure if I'll be able to keep things like achievements or a leaderboard, though... I'll need to see what's possible. Everything is compatible with Etch.

I wish I could have done that when I was 9... Be sure to send it to Equestria Daily.

Joyride on Pinata. Seeing as I'm driving against traffic on a motorcycle, I probably wouldn't survive, nope.

Guess you'll just have to share it with all your family and friends, instead.

https://www.youtube.com/watch?v=IKF_GxV1jVM Hello! Anyone up for giving my first game release a try? I'd love to hear some feedback!

That would be awesome, but I can't find the actual code anywhere--just links to poorly-documented source that I'd need to compile myself (and I have no clue about that).