The Video Game Homebrew Crash of 2016

[+DZ-Jay]

Honestly, I would learn Assembly, but I feel like learning enough to write an Atari 2600 game would take at least a decade. I'd have better luck with bB IMO.

 

Learning Assembly Language is not much harder than learning any other language. I will admit that it does have a steep learning curve and it is indeed intimidating. It also is very terse, which requires careful thought and can be hard to understand.

 

The biggest challenge in learning Assembly Language is in making the cognitive leap of working at a very low-level which implies breaking down tasks to their minimal details. It is easy to get lost in such low-level detail, but with some practice (and I mean just a few days or weeks, not years as many would think) it becomes as second nature as using a higher level language.

 

At their most basic level, computers can only do three operations:

• Move values from one memory location to another
• Add one value to another
• Test the outcome and react

That's it. The rest are variations, or complex applications, of these operations. The trick is in breaking down every single task into these steps. Once you cross that point, it becomes much easier.

 

Think of it like describing the steps to, say, walking up a flight of stairs. Let's say you are teaching a child how to climb up the stairs, so you start by saying:

• Put your left foot on the step
• Lift your body
• Put your right foot on the same step
• Repeat until you reach the top

Simple. However, what if the child asks, "how do I put my left foot on the step?" Then you need to break it down more:

• Bend your left knee
• Lift your left thigh
• Move left foot slightly forward until it is above the step
• Bring down the left foot until it lands on the step
• Apply pressure to your left foot while lifting your body
• Move your right foot until it reaches the step
• Land the right foot on the step
• Repeat until you reach the top

Better, right? Then the child asks, "what's a foot?" and you have to go deeper into the weeds. It's the same with Assembly Language: the computer has a limited set of instructions but which, just like a child's limited vocabulary, is sufficient to describe its entire world at a low enough level. So, you start by identifying your task, then breaking it down until you reach a sufficiently low level for the language to support.

 

Say you want to add a value to another value in memory, both in locations identified by the symbols X and Y, respectively, so that you get X = X + Y.

• Get value of Y
• Add it to X
• Done

The computer asks, "what's a Y?" So you break it down:

• Get memory location for Y
• Fetch value from memory location of Y
• Get memory location for X
• Fetch value from memory location of X
• Add values of X and Y
• Done

Sure, but... "where do you want that again?"

• Get memory location for Y
• Fetch value from memory location of Y and store it in the accumulator register
• Get memory location for X
• Fetch value from memory location of X and add it to the value in the accumulator register
• Take value from the accumulator register and store it in memory location of X
• Done

Ta-da!

 

It's verbose and terse and confusing at times, sure, but it just takes a bit of thought which -- trust me when I say this -- becomes more and more natural as you keep doing it.

 

I went cold from programming in higher level languages professionally to CP-1610 Assembly Language (Intellivision) in 2010, and within a few months had my first game. Sure it was simple with a single screen, but I made it, so it is possible.

 

Making games is hard, gruelingly so. Very hard. I will even say, extremely hard -- but it is not because of the language. If I learned anything then is that making a game in Assembly Language is not the exclusive domain of wizards, and it is certainly not an arcane black art. Sure, it is challenging, but it is fully within the reach of us mere mortals. You just have to try and give it a chance.

 

-dZ.

Edited August 27, 2016 by DZ-Jay

[Thomas Jentzsch]

Sounds like the developer missed randomizing. That might be an easy fix, I wonder why it wasn't done.

Oh, I found the game has no random elements and is just looping over the bases. Boring!

 

Attached is a more random version.

Laster Blast (random) (NTSC).bin

[Kurt_Woloch]

Actually, the 6507 CPU in the Atari 2600 does know what a Y is... it's one of the CPU registers. The trouble is that there are only three registers in the CPU, so you have to pass nearly all values through one of them (except if you only want to increment or decrement a memory location). This is similar to the fact that you only have two hands, so you can only take two things at once (OK, more with tricks). That's why you're usually not done after adding Y to X, but you have to save the result to another memory location in order to free up Y (one of your "hands") for a different task.

 

 

Say you want to add a value to another value in memory, both in locations identified by the symbols X and Y, respectively, so that you get X = X + Y.

• Get value of Y
• Add it to X
• Done

The computer asks, "what's a Y?" So you break it down:

[+DZ-Jay]

Actually, the 6507 CPU in the Atari 2600 does know what a Y is... it's one of the CPU registers. The trouble is that there are only three registers in the CPU, so you have to pass nearly all values through one of them (except if you only want to increment or decrement a memory location). This is similar to the fact that you only have two hands, so you can only take two things at once (OK, more with tricks). That's why you're usually not done after adding Y to X, but you have to save the result to another memory location in order to free up Y (one of your "hands") for a different task.

 

 

None of what you just said invalidates the simple and high-level point that I was trying to make: that the biggest challenge of programming in Assembly Language is not the ostensibly cryptic language itself, but the critical thought needed in breaking down larger tasks into their minimal steps. Once you crack that egg, everything falls into place.

 

There is no need to think that Assembly can only be understood by geniuses and there is absolutely no reason to perpetuate the myth that it is harder for newbies than learning any other difficult skill, as long as they have the interest. Granted, programming the Atari 2600 is harder than most other retro-consoles because of the technical limitations of the primitive device; but there is plenty of documentation, community assistance, and general patterns and best practices to make up for it.

 

-dZ.

Edited August 27, 2016 by DZ-Jay

[+Gemintronic]

For a very short time there was an "SNES Game Maker" that was little more than a fancy IDE for assembly. The end user was presented with graphical code blocks that would offer GUI fields for arguments and values.

 

I think with the right presentation assembly can be greatly demystified. Same thing with C. Give me a pre-configured visual IDE instead of forcing a "rite of passage" to program in it.

[Andromeda Stardust]

 

But I can imagine how michelangelo felt after painting the sistine chapel and the first person who looked said, that is nice but I kind of get a kink in my neck looking at that. Hey, is that a painting of fruit that guy is selling in the lobby?

 

Mmmm, naked bodies in a church. Reminds me of this classic gag:

[SIO2]

Oh, I found the game has no random elements and is just looping over the bases. Boring!

 

Attached is a more random version.

 

I like it. You should also bump the free ship from every 1,000 to 10,000.

[Thomas Jentzsch]

 

I like it. You should also bump the free ship from every 1,000 to 10,000.

Still too easy? OK.

Laster Blast (random, 10k) (NTSC).bin

[gliptitude]

I don't feel like low quality productions injure or hinder the high quality productions. I can see how they might be considered a nuisence and annoying. But in general I think the really polished and complete games are evident and recognized. Unless it is somehow causing the really qualified people to become discouraged and refrain from making their games, I don't see how people buying more games is a bad thing.

 

.. I think the issue of "quality" is a real dilemma for video games. It is a much higher bar than other forms of art and entertainment. There are many many examples of amateurish films, paintings, performances, musical compositions and literary works which are exceptional in their own right and revered by the aficionados of those mediums. But there really is no video game analogue to this.

 

I think it's an unfortunate and unique and unavoidable aspect of the form. Playing video games, loving video games, being inspired by video games and having new ideas about video games does not enable you to make video games. You have to also be an engineer, in a very rigorous sense. Part of the outcome of this is that you are never going to see the level or volume of experimentation, variety and cross-pollination that exists in cinema, comics, sculpture, painting etc.

[Sdw]

As I'm soon to release my first game, reading this topic has made me a bit apprehensive.

Even if it's a quite simple game, the plan was to have a cartridge release as well, since, well, it's cool to have your game on physical media.

And also for me, the actual making of money on something you have created just for fun is a cool feeling. As it is now, I will probably be looking at a $3 profit per cart sold, and if the game sells 10 copies, that means that one month when I pay my internet bill or something, I can think "well, this was actually paid for by the game!"

 

Now, while the game is written in painfully hand-optimized assembler, it is a rather simplistic concept. We have tried to balance it and make it fun to play, and nice to look at, but it will not have every cool feature that everyone could imagine, and to me that is OK. I have other things I want to do, other demos and games I want to write, spending a year on polishing every detail to absolute perfection would make it "work". For me, creating games is "fun".

[RevEng]

Polish isn't about adding every feature a user could consider. Sometimes a game design can become better by dropping certain features, if they don't add to the player experience. Think of polish more like editing a book; you'll rewrite bits, remove some, add others.

 

There's room for simple games in the market; the objection here for ones that are subjective crap. Ones that were hurredly put together over a few weekends. From the video you shared, it's pretty clear your own game is in the "simple" category, not in the "crap" one.

 

I do think if a game is very simple, very complex, or just off the beaten path, there's more of an obligation to get that communicated to the customer somehow, so they can make an educated purchasing decision. The easiest way to do that is to release a ROM.

[Thomas Jentzsch]

As I'm soon to release my first game, reading this topic has made me a bit apprehensive.

No need to worry AT ALL.

 

I can assure you, that your games looks at least 10 times more polished* than the ones we are talking about. And I am sure you invested 10, maybe 100 times more time into development.

 

* Except for the generic score font that is.

[alex_79]

As I'm soon to release my first game, reading this topic has made me a bit apprehensive.

This fact alone is a good indicator that you're not part of the people Andrew was referring to when he started this thread.

 

Now, while the game is written in painfully hand-optimized assembler, it is a rather simplistic concept. We have tried to balance it and make it fun to play, and nice to look at, but it will not have every cool feature that everyone could imagine, and to me that is OK.

It IS ok!

It's not the complexity of the game, but the effort you put to refine and polish it that makes the difference.

 

Making an actual release and also making some money out of it is perfectly fine and as you said, it might as well be part of the fun. Nothing wrong with it.

 

The people Andrew and many others have issue with are those who just want to put something on cart but don't put any effort to create something worth to be published. What is on the cart doesn't matter, it just has to be released, better if in limited, numbered edition to artificially inflate the price. If they're just graphics hack of existing games or slightly altered examples found in programming tutorials it's also important for those people to NOT give credit to the original author and take all the merit...

Edited August 30, 2016 by alex_79

[+Random Terrain]

. . . or slightly altered examples found in programming tutorials it's also important for those people to NOT give credit to the original author and take all the merit...

Yeah, if you see a "game" that looks similar to the video below, it's probably a barely changed version of the Tinkernut demo:

 

youtube.com/watch?v=L17tOAcilBk

https://www.youtube.com/watch?v=L17tOAcilBk

 

[Sdw]

* Except for the generic score font that is.

 

The font has been redrawn since the version posted in the video, it looks a bit more like the C64 version now at least...

[SIO2]

Yeah, if you see a "game" that looks similar to the video below, it's probably a barely changed version of the Tinkernut demo:

 

 

That looks just like my Skrat World game.

Edited August 31, 2016 by SIO2

[+Nathan Strum]

Yeah, if you see a "game" that looks similar to the video below, it's probably a barely changed version of the Tinkernut demo:

 

[troublemaker]

Just three questions:

1. Where can I get the ROMZ?
2. Is there a pre-order list?
3. Will it come with a box?

[/troublemaker]

[Mr SQL]

Honestly, I would learn Assembly, but I feel like learning enough to write an Atari 2600 game would take at least a decade. I'd have better luck with bB IMO.

 

Excellent point - even without the unique racing-the-beam architecture, Assembly takes a lot more time to program in.

 

BASIC is much faster to program a game in and encourages creativity - games can potentially be created in an amazingly short timeframe compared to Assembly because they can be written in just a few lines of code compared to literally thousands.

 

Try out some of these awesome 10 line BASIC games like Space Invaders, Temptest, Boulder Dash and Blitz that were written for the 2016 Vintage Programming contest:

 

http://gkanold.wixsite.com/homeputerium/games-list-2016

 

Blitz was written in Virtual World BASIC, an alterative to bB with enhanced graphics capabilities. You can download the CD and some examples here if you'd like to try it out or want to enter a game in next years programming contest.

 

 

As I'm soon to release my first game, reading this topic has made me a bit apprehensive.

 

Sharing your game on other sites as well can help give you more well rounded feedback

[DanOliver]

Some of the greatest games are pretty simple, video and otherwise. Just like in movies, lots of special effects will sell some tickets, but that alone can't make a movie great. To me polish means tweaking how the game reacts to user input...smooth, makes sense, player doesn't ever struggle to move. Second is the difficulty level, fun to play while learning how and then also ramps to difficult and then to almost impossible. Give them an experience, feel natural.

 

This tweaking normally requires very little code changes, hopefully. But it takes a lot of playing, time and very critical eye. You also have to have some level of player in you too. I'm not a great player so I can test the starting and middle level. For the hard I have to guess based on the middle level settings. For impossible it's more technical, figuring out if your joystick movements and windows to accomplish a tasks are possible. If say player has to move 10 lines vertically to accomplish a goal and they can only move one line per frame and you give them 8 frames they can't win, not cool. So something needs a tweak.

 

If you can get others to test that's great too. IMO that can't be remote, you have to see how they react, how they do, and say nothing while they play. If remote then a video of them playing and the screen is the next best choice. However, player testing is not a substitute for the designer. They'll make suggestions maybe, consider them if you want, but don't lose track that it's your vision and rep on the line.

 

But, if you really aren't happy with a game then screw it, do another. Release the ROM. Do you want just anything with your name on it or your best effort? Second game will go faster and be better. Only you can judge.

[gauauu]

 

Learning Assembly Language is not much harder than learning any other language.

 

I dunno, most other languages have signed vs unsigned variables, and handle 16-bit math for you. Those things aren't that complicated, but the fact that you have to think about them all the time adds some difficulty.

 

I can teach my 8 year olds some simple C to update a position, like so:

int xPos = 250;
int xDir = 1;

void update() {
   x = x + xDir;

   if (x > 300) {
      xDir = -xDir;
   }
   if (x < -300) {
      xDir = -xDir;
   }
}

He'd understand the concepts there pretty quickly. Translating that into 6502 assembly? Forget it. There's just too much complication with the 16-bit math and fiddling with signs.

[iesposta]

Some of the greatest games are pretty simple, video and otherwise.

...

If you can get others to test that's great too. IMO that can't be remote, you have to see how they react, how they do, and say nothing while they play. If remote then a video of them playing and the screen is the next best choice. However, player testing is not a substitute for the designer. They'll make suggestions maybe, consider them if you want, but don't lose track that it's your vision and rep on the line.

...

 

That's what I was trying to say in my giant post.

My first game, Flappy, I made very quick, it is simple as you know.

It is changed because I didn't want a joke, I wanted a challenging, funny, fun game akin to Barnstorming.

(I like Barnstorming, others hate it, that's another discussion. )

 

Now I wish I would have seen more people play it.

I polished it for myself, but now I see skilled players as well as newbie players can not press the button the way it's natural and simple for me. I guess playing Joust as a teen taught me this. Press really fast to move up, real steady to hover in one spot, press less often to descend, and stop pressing to fall to the bottom, which even there I didn't put death, but you can rest without button pushing if you're lucky enough to get 3 random pipes that are bottom open. If you rest too long a glitch feature causes your player to be at random heights and the next pipe will kill you, so then you learn to flap and not rest too long.

I would have added Flap Settings, maybe even going as simple as hold the button moves up, any tapping hovers, and no tapping falls as one option.

 

Playtesting while observing others would have shown a way to make my game enjoyable for more people that just Joust players.

[+McCallister]

 

That's what I was trying to say in my giant post.

My first game, Flappy, I made very quick, it is simple as you know.

It is changed because I didn't want a joke, I wanted a challenging, funny, fun game akin to Barnstorming.

(I like Barnstorming, others hate it, that's another discussion. )

 

Now I wish I would have seen more people play it.

I polished it for myself, but now I see skilled players as well as newbie players can not press the button the way it's natural and simple for me. I guess playing Joust as a teen taught me this. Press really fast to move up, real steady to hover in one spot, press less often to descend, and stop pressing to fall to the bottom, which even there I didn't put death, but you can rest without button pushing if you're lucky enough to get 3 random pipes that are bottom open. If you rest too long a glitch feature causes your player to be at random heights and the next pipe will kill you, so then you learn to flap and not rest too long.

I would have added Flap Settings, maybe even going as simple as hold the button moves up, any tapping hovers, and no tapping falls as one option.

 

Playtesting while observing others would have shown a way to make my game enjoyable for more people that just Joust players.

I would call this game the ultimate button tapper! Once you get that down, it becomes a test of endurance and therein lies the challenge (and enjoyment!)

[Andromeda Stardust]

Yeah, if you see a "game" that looks similar to the video below, it's probably a barely changed version of the Tinkernut demo:

 

youtube.com/watch?v=L17tOAcilBk

https://www.youtube.com/watch?v=L17tOAcilBk

 

Still better than Mythicon!

[Andromeda Stardust]

 

That's what I was trying to say in my giant post.

My first game, Flappy, I made very quick, it is simple as you know.

It is changed because I didn't want a joke, I wanted a challenging, funny, fun game akin to Barnstorming.

(I like Barnstorming, others hate it, that's another discussion. )

 

Now I wish I would have seen more people play it.

I polished it for myself, but now I see skilled players as well as newbie players can not press the button the way it's natural and simple for me. I guess playing Joust as a teen taught me this. Press really fast to move up, real steady to hover in one spot, press less often to descend, and stop pressing to fall to the bottom, which even there I didn't put death, but you can rest without button pushing if you're lucky enough to get 3 random pipes that are bottom open. If you rest too long a glitch feature causes your player to be at random heights and the next pipe will kill you, so then you learn to flap and not rest too long.

I would have added Flap Settings, maybe even going as simple as hold the button moves up, any tapping hovers, and no tapping falls as one option.

 

Playtesting while observing others would have shown a way to make my game enjoyable for more people that just Joust players.

I still need to get Flappy. I have two one-button Atari games now, Wall Jump Ninja and Jump VCS. Might as well add a third to the list. Wall Jump Ninja is an incredible test of reflexes while Jump VCS is somewhat more of an endurance test.

[Lauren Tyler]

 

Excellent point - even without the unique racing-the-beam architecture, Assembly takes a lot more time to program in.

 

BASIC is much faster to program a game in and encourages creativity - games can potentially be created in an amazingly short timeframe compared to Assembly because they can be written in just a few lines of code compared to literally thousands.

 

Try out some of these awesome 10 line BASIC games like Space Invaders, Temptest, Boulder Dash and Blitz that were written for the 2016 Vintage Programming contest:

 

http://gkanold.wixsite.com/homeputerium/games-list-2016

 

Blitz was written in Virtual World BASIC, an alterative to bB with enhanced graphics capabilities. You can download the CD and some examples here if you'd like to try it out or want to enter a game in next years programming contest.

 

 

 

Sharing your game on other sites as well can help give you more well rounded feedback

 

If I'm reading this correctly, I just need to brush up on Tiny BASIC syntax and things like that and I should be good to go?