4 ms·

My favorite little trick of these was that the bushes and the clouds in Super Mario Bros. were the same shape (presumably to save space): http://www.todayifound

by jmduke 13y ago

My favorite little trick of these was that the bushes and the clouds in Super Mario Bros. were the same shape (presumably to save space): http://www.todayifoundout.com/index.php/2010/01/the-clouds-and-bushes-in-super-mario-bros-are-the-same/ http://www.todayifoundout.com/index.php/2010/01/the-clouds-a... I would never want to enter the game development industry but I would love to shadow them for a few weeks. It sounds like a culture of required innovation (and, you know, eternal crunch time).

dsirijus 13y ago
Unstable, underpaid, overworked and extremely competitive market. Also, pinnacle of engineering in both frontend and backend; eats web dev for breakfast.
- pestaa 13y ago
  What about web game dev now? We're almost seeing entire operating systems running in JavaScript. Can we please just keep producing game binaries for the desktop where it actually runs like it's meant to? /rant
  - dclowd9901 13y ago
    I'm currently developing a game using Impact.js, and it's no picnic having to work within the limitations of the browser.
    - pestaa 13y ago
      Which is sort of my point. There's so much we haven't explored in the compiled world, but we're busy reinventing all the same things in a slow fragile sandbox.
  - CodeCube 13y ago
    Writing JS games is fun :) I've got a little html5 game engine I'm working on: https://github.com/joelmartinez/flatredball-js https://github.com/joelmartinez/flatredball-js Here's a live sample (that you can edit in real time) - http://joelmartinez.github.io/flatredball-js/#rain http://joelmartinez.github.io/flatredball-js/#rain It's not as much about reinventing things in JS, it's about exploring what is possible in that environment. I'm not a huge fan of the "compilers" that just take an executable and compile it to JS ... I'm more going for a "native web" experience.
    - pestaa 13y ago
      Let's not pretend a bouncing ball is exciting regardless you see it in the browser or not. (Except if you're seeing your own stupid ball animation, of course.) Writing games in any language is fun, so by all means keep doing what you enjoy. :) But let's not forget all these problems JS implementations see have already been solved extremely well on the desktop.
      - jplur 13y ago
        I hear this on HN quite a bit, but it's not that big of an issue. Most game developers don't need the raw speed of a native system. They do need to create something that can be played by everybody, and is easy to develop for. The very fact that we're seeing so much html/js game dev (including games packaged with a browser as native apps)says it all. Game developers don't pick up a language/platform lightly, if they're making games for it, it's a good choice. However, regarding mobile platforms, you can forget all I've said.
        pestaa 13y ago
        It is not my concern that some indie developers use whatever they are familiar with. We've been playing those funny stick figure flash games on rainy days anyways. They can be fun to play and fun to develop. However, it is the big studios that should not push to this platform. They had compile-time guarantees, insane ecosystem, known performance tradeoffs. And now some of them want a huge pile of (as in million+ LOC) game engine running on top of a broken scripting language. And for what in exchange? So that the installer's gone and assets are delivered on demand? MMOs have been doing this for years on the desktop. In short, if you do it for fun, please use whatever feels good. If you do it for the money, please do your research and don't make my browser freeze -- I'll just go to Kongregate where the former publishes their games.
        forrestthewoods 13y ago
        "The very fact that we're seeing so much html/js game dev" We are? Games that make money? Most games may not need the raw speed of native, but they do need the raw latency. If a game is being programmed in a garbage collected language you're gonna have a bad time.
- GuiA 13y ago
  Writing your own games (either in your free time or as an attempt to make a living from it) is extremely fun though, and I would recommend that any developer pick up an intro to game dev book and have at it :)
  - gravitronic 13y ago
    Can you recommend a book on game dev for senior developers? IE I do not want to be hand-held through how to program, just the physics and concepts of good structure for game development.
    - marshray 13y ago
      As a senior dev who's just started to dabble in games I've found Game Engine Architecture by Jason Gregory to be very useful and high quality. Oh looks like there's a second edition coming out at some point http://www.amazon.com/dp/1466560010 http://www.amazon.com/dp/1466560010
      - dyselon 13y ago
        It's a fantastic book, for sure. Gamasutra published an excerpt of it when it came out, going over some of the section on the main game loop: http://www.gamasutra.com/view/feature/132587/book_excerpt_game_engine_.php?print=1 http://www.gamasutra.com/view/feature/132587/book_excerpt_ga...
      - seivan 13y ago
        Woah, thanks!
asperous 13y ago
Just the clouds you say? I count 12 distinct tiles on that screen. They were incredibly efficient with space-- the rom for that game is 40kb.. less than two uncompressed htmls of the front page of HN!
- Mahn 13y ago
  > They were incredibly efficient with space Not saying they were not, but compressed 64 color graphics/palettes and 6502 machine code would usually not take an enormous amount of space.
ANTSANTS 13y ago
That's a little different from the tricks described in the article, though: Not a last-minute hack, but a deliberate space compromise of the kind that these games absolutely were built around. Ever notice that a lot of old games have very repetitive worlds? Most of them are built around what some call a "room sprite": a prefabricated room that can be placed anywhere in the world. The world, then, is not much more than a big array of of indices into an array of expensive room sprites. That's relatively straightforward, but it gets interesting when you store some information about an instance of a room separately from the "sprite" itself. Simplest example: If you store the hardware color palette and/or tilemap information separately, you can use the same basic room in different dungeons and make it look significantly different each time. If a game has a generic "item room" (like the ones in Metroid or Zelda), you can bet that each instance of that room only needs to specify a single byte representing the item to be found in it. A more interesting application are the doors in Zelda: They're not a part of the "room sprite" itself. Instead, for each possible north, south, east, and west door, there's a simple bitflag that enumerates a few possibilities: "no door on this wall, there is an open door, there is a locked door, there is a door that you must trigger an event to open, etc." I don't know if Zelda does this, but it would be pretty easy to allow rooms to be flipped horizontally or vertically as well. Just these few techniques, a dozen rooms, and thoughtful game design would probably be enough to get a few decent dungeons that would take hours to beat, out of a modicum of kilobytes. My favorite example of this idea: If you really explore the original Metroid, you'll find a lot of hidden bombable paths that don't always lead anywhere. For instance, all item rooms have a pipe underneath them that can be entered by bombing a nearby block, but in most of the rooms, the pipe doesn't lead anywhere. If you don't know any better, it seems like the designers are just playing with your curiosity. In hindsight, it's totally obvious that this was a trick to let the game designers choose whether or not to put a secret passageway behind a particular item room just by lining up a different room next to it! Once you get this, you see it everywhere in the world. You start recognizing different room sprites, and memorize the where their hidden paths are located. With that and the realization that the game only ever scrolls along one axis at a time, the seemingly impossible task of mapping out the entire world ("do they really expect me to shoot every single wall?") quickly becomes a simple effort of pattern memorization. Sadly, most people who try the original Metroid today get tired of climbing up those long vertical shafts and starting with only 30 health and quit before they even get a chance to discover this metagame.

by jmduke 13y ago

dsirijus 13y ago

Unstable, underpaid, overworked and extremely competitive market. Also, pinnacle of engineering in both frontend and backend; eats web dev for breakfast.

pestaa 13y ago
What about web game dev now? We're almost seeing entire operating systems running in JavaScript. Can we please just keep producing game binaries for the desktop where it actually runs like it's meant to? /rant
- dclowd9901 13y ago
  I'm currently developing a game using Impact.js, and it's no picnic having to work within the limitations of the browser.
  - pestaa 13y ago
    Which is sort of my point. There's so much we haven't explored in the compiled world, but we're busy reinventing all the same things in a slow fragile sandbox.
- CodeCube 13y ago
  Writing JS games is fun :) I've got a little html5 game engine I'm working on: https://github.com/joelmartinez/flatredball-js https://github.com/joelmartinez/flatredball-js Here's a live sample (that you can edit in real time) - http://joelmartinez.github.io/flatredball-js/#rain http://joelmartinez.github.io/flatredball-js/#rain It's not as much about reinventing things in JS, it's about exploring what is possible in that environment. I'm not a huge fan of the "compilers" that just take an executable and compile it to JS ... I'm more going for a "native web" experience.
  - pestaa 13y ago
    Let's not pretend a bouncing ball is exciting regardless you see it in the browser or not. (Except if you're seeing your own stupid ball animation, of course.) Writing games in any language is fun, so by all means keep doing what you enjoy. :) But let's not forget all these problems JS implementations see have already been solved extremely well on the desktop.
    - jplur 13y ago
      I hear this on HN quite a bit, but it's not that big of an issue. Most game developers don't need the raw speed of a native system. They do need to create something that can be played by everybody, and is easy to develop for. The very fact that we're seeing so much html/js game dev (including games packaged with a browser as native apps)says it all. Game developers don't pick up a language/platform lightly, if they're making games for it, it's a good choice. However, regarding mobile platforms, you can forget all I've said.
      - pestaa 13y ago
        It is not my concern that some indie developers use whatever they are familiar with. We've been playing those funny stick figure flash games on rainy days anyways. They can be fun to play and fun to develop. However, it is the big studios that should not push to this platform. They had compile-time guarantees, insane ecosystem, known performance tradeoffs. And now some of them want a huge pile of (as in million+ LOC) game engine running on top of a broken scripting language. And for what in exchange? So that the installer's gone and assets are delivered on demand? MMOs have been doing this for years on the desktop. In short, if you do it for fun, please use whatever feels good. If you do it for the money, please do your research and don't make my browser freeze -- I'll just go to Kongregate where the former publishes their games.
      - forrestthewoods 13y ago
        "The very fact that we're seeing so much html/js game dev" We are? Games that make money? Most games may not need the raw speed of native, but they do need the raw latency. If a game is being programmed in a garbage collected language you're gonna have a bad time.
GuiA 13y ago
Writing your own games (either in your free time or as an attempt to make a living from it) is extremely fun though, and I would recommend that any developer pick up an intro to game dev book and have at it :)
- gravitronic 13y ago
  Can you recommend a book on game dev for senior developers? IE I do not want to be hand-held through how to program, just the physics and concepts of good structure for game development.
  - marshray 13y ago
    As a senior dev who's just started to dabble in games I've found Game Engine Architecture by Jason Gregory to be very useful and high quality. Oh looks like there's a second edition coming out at some point http://www.amazon.com/dp/1466560010 http://www.amazon.com/dp/1466560010
    - dyselon 13y ago
      It's a fantastic book, for sure. Gamasutra published an excerpt of it when it came out, going over some of the section on the main game loop: http://www.gamasutra.com/view/feature/132587/book_excerpt_game_engine_.php?print=1 http://www.gamasutra.com/view/feature/132587/book_excerpt_ga...
    - seivan 13y ago
      Woah, thanks!

asperous 13y ago

Just the clouds you say? I count 12 distinct tiles on that screen. They were incredibly efficient with space-- the rom for that game is 40kb.. less than two uncompressed htmls of the front page of HN!

Mahn 13y ago
> They were incredibly efficient with space Not saying they were not, but compressed 64 color graphics/palettes and 6502 machine code would usually not take an enormous amount of space.

ANTSANTS 13y ago

That's a little different from the tricks described in the article, though: Not a last-minute hack, but a deliberate space compromise of the kind that these games absolutely were built around. Ever notice that a lot of old games have very repetitive worlds? Most of them are built around what some call a "room sprite": a prefabricated room that can be placed anywhere in the world. The world, then, is not much more than a big array of of indices into an array of expensive room sprites. That's relatively straightforward, but it gets interesting when you store some information about an instance of a room separately from the "sprite" itself. Simplest example: If you store the hardware color palette and/or tilemap information separately, you can use the same basic room in different dungeons and make it look significantly different each time. If a game has a generic "item room" (like the ones in Metroid or Zelda), you can bet that each instance of that room only needs to specify a single byte representing the item to be found in it. A more interesting application are the doors in Zelda: They're not a part of the "room sprite" itself. Instead, for each possible north, south, east, and west door, there's a simple bitflag that enumerates a few possibilities: "no door on this wall, there is an open door, there is a locked door, there is a door that you must trigger an event to open, etc." I don't know if Zelda does this, but it would be pretty easy to allow rooms to be flipped horizontally or vertically as well. Just these few techniques, a dozen rooms, and thoughtful game design would probably be enough to get a few decent dungeons that would take hours to beat, out of a modicum of kilobytes. My favorite example of this idea: If you really explore the original Metroid, you'll find a lot of hidden bombable paths that don't always lead anywhere. For instance, all item rooms have a pipe underneath them that can be entered by bombing a nearby block, but in most of the rooms, the pipe doesn't lead anywhere. If you don't know any better, it seems like the designers are just playing with your curiosity. In hindsight, it's totally obvious that this was a trick to let the game designers choose whether or not to put a secret passageway behind a particular item room just by lining up a different room next to it! Once you get this, you see it everywhere in the world. You start recognizing different room sprites, and memorize the where their hidden paths are located. With that and the realization that the game only ever scrolls along one axis at a time, the seemingly impossible task of mapping out the entire world ("do they really expect me to shoot every single wall?") quickly becomes a simple effort of pattern memorization. Sadly, most people who try the original Metroid today get tired of climbing up those long vertical shafts and starting with only 30 health and quit before they even get a chance to discover this metagame.