next »

[Sheepolution]

When I look at pixelart from SNES games, some look really great. For example:



Those graphics look really awesome. If I look at the "show me your pixelwork" thread, you don't see much that can match this piece of art. You would expect that our tools are way better than back then, but still they make amazingly art.

I'm just wondering: How did they make games back then?
What tools did they used, what language? I really would like to know.

[ink.inc]

assembly

[ragnor]

deluxe paint, modtracker, fasttracker, djgpp, turbo c, masm etc...

[agersant]

Those graphics look really awesome. If I look at the "show me your pixelwork" thread, you don't see much that can match this piece of art. You would expect that our tools are way better than back then, but still they make amazingly art.

The quality of an art piece does not rely a lot on the quality of the tools you used to make it. It mostly takes practice (and a bit of talent). That's why Renaissance paintings do not suck too.

[moi]

Tile extractor.
You make the level for the bitmap in a paint program (using the grid and copy+paste where necessary) and the program extracts tiles graphics and tilemap automagically.

Much easier and much much less artistically limiting than starting by creating an awkward set of tiles and trying to make a level out of it.

Also: they used real artists instead of NES nostalgic kids with a retro fetish. (in this case walt Disney artists)

Also: if you look at the stones, I'd say chances are high that these are digitized from paintings

[J-Snake]

Programming games required much more skill in those days.

Who are you telling this?




The physics are assembler-optimized. Notice that those physics can kill every new age pc with a few more blocks. If you are not doing it well the processing power will linearly scale to the blocks-amount, it is tried to make it independent from the amount of blocks.

I also use some glue next to assembler to make it better stick together (nah just joking).

Anyway, but you have to admit that those games were a lot simpler, too.

[J-Snake]

....It was necessary to build the game they wanted to make, and with all of the features they wanted it to have.

The real trick they used is this: They simply didn't make the game they wanted to make.

Anyway, I am making games not everyone can make, even on recent hardware. It is just a matter on what you want to spend serious attention. There is more thought spend on the movement-system alone in TrapThem than in all other grid-based action-puzzlers. Not to mention the challenge I face with TrapThem-physics. Just try to apply it in a large environment in a Metroid-Rethought. Now you need to think about optimization more than ever, even on recent hardware, or you simply don't make the game you want to make to make things simpler.

[J-Snake]

That's nothing different today. Crysis2 was bound to what is feasable on a console and it was a hell of a challenge to create a performant engine for it.

[J-Snake]

Have you seen TrapThem-physics?

[J-Snake]

What point of those 4 do you think is the most challenging one.

[J-Snake]

2 is the hardest point by far. The outstanding point is that it scales with the amount of blocks. That is what separates it from Minecraft and all the other grid-based puzzlers where physics are based only on local information. That is why you haven't seen TrapThem-physics before in a game. The idea of these physics were shown in a dig-dug intro. In the intro he actually cuts out a piece of ground and it falls down. But in gameplay only local physics like in boulder-dash were implemented.

That is an example of not making a game you initially wanted to make.

I had ideas how to make it possible for almost an arbitrary number of blocks. If a large amount falls down distant pieces will be updated less frequently (but you won't notice it in your local space) since you can only solve a global amount of content by mapping relevant pieces of it into your local processing-headroom. Another important thing to exploit is that the speed of destruction is limited by the speed of your player. It means you can keep up with keeping the block-structures organized while the player is destroying the environment.

But the biggest problem is the reconnecting after a cut out shape was recognized. It is something that happens instantly (so the main challenge is how to make it less instant). When a complex and very large block falls down and connects to anoter one I am not even sure atm. the problem is solveable at all in rt. But I will look what I can do.

[J-Snake]

I didn't give the 4 color-theorem much consideration yet so I cannot make sophisticated statements about its relevance atm.

Can you please try to remember that game? How old is it approximately and what exactly is it about?

[moi]

Qix?

[J-Snake]

nope

[JobLeonard]

Here's another forgotten technique: colour cycling
http://www.effectgames.com/demos/canvascycle/?sound=1
Hand-made dithering with some really smart choices in palette swappes, and presto: animation with almost no bytes or processing power required!

[J-Snake]

Solve my problem and you will achieve something really special.

edit: Oh, I see your post was supposed to be on topic, sorry.

[Ben_Hurr]

Here's another forgotten technique: colour cycling
http://www.effectgames.com/demos/canvascycle/?sound=1
Hand-made dithering with some really smart choices in palette swappes, and presto: animation with almost no bytes or processing power required!

God that's amazing.
Color cycling truly is the lost art of game making.

[JobLeonard]

@J-Snake: I was actually wondering if I should say something like "Anyway, ontopic", but that could imply that I thought your discussion wasn't interesting and I didn't want that either

@Ben_Hurr: Yes, but to be fair it requires a rare combination of the right artistic and technical talents and skills to do properly. I think Mark Ferrari is quite in that sense.

You need artistic skills to create a good scene. Specifically, I think it helps if your strengths lie with painterly scenes, and if you have a good skill in making textures. Obviously, you'll need a really good sense of colours (duh, it's about exploiting the palette after all). On the technical side you require the know-how about palette swapping. And somehow, you need to make a link between all of that at the intuitive level.

Have you read the interview?
http://www.effectgames.com/effect/article.psp.html/joe/Q_A_with_Mark_J_Ferrari

[InfiniteStateMachine]

Here's another forgotten technique: colour cycling
http://www.effectgames.com/demos/canvascycle/?sound=1
Hand-made dithering with some really smart choices in palette swappes, and presto: animation with almost no bytes or processing power required!

holy crap that's awesome.

What games are there that have used this technique?

[iffi]

Wikipedia says that Sim City 2000 used it quite extensively.