|
Too Fast To Be Fun - Part 1 by (22 January 2001) |
Return to The Archives |
Introduction
 |
|
Hi all, It's been quite a while since I wrote my last article here on flipcode. It almost looks like everything has been documented or something; I rarely see anything new these days. Maybe that's because of the rather fast development of hardware 3D accelerators and CPU speeds: I think this caused a rather important switch from 'technical knowledge' to more 'theoretical knowledge', a switch that many coders find hard to make. A decade ago, you were the king if you knew how to do a specific effect with a VGA card. Five years ago, you where da man if you understood BSP trees. Nowadays, it's hard to be above average. A game is good if its art looks (and sounds) good; the code behind it is important, but expected to be OK. Expectations are the key problem here. If someone posts an IOTD with some nice graphics, no-one is going to encourage the poor guy to actually write a game with it. The reason is simple; encouraging someone to design a space game based on a space 3D engine is the same as saying 'hey, get a large team, write a product design, lead the team and then you'll have a game that kicks ass'. You're not going to get away with a simple game anymore. People expect more. Too much, actually. Even the breeding grounds of the game industry, the demo scene, suffers from this. No longer do technological masterpieces automatically win contests, like they used to. I know, 'spot' is a technological masterpiece, and I've seen more, especially 64Kb intros. Nevertheless, demos, just like games, require relatively little technical knowledge, and lots of good art. The hard part of winning a demo compo is no longer writing this amazing optimized inner loop; instead it has become a management and networking contest. The true hardcore coder is introverted, weird, primarily technologically interested and thus has major problems keeping up with the pace of nowadays game and demo coding. He thus tries to find interesting areas that still require his skills, and his skills alone, and he finds his destiny in obscure challenges like emulators, 64Kb (or even 4Kb) intros and other platforms like the GameBoy or the Playstation. Coding like that is still rewarding, but there's a problem: The latest consoles are as powerful as yesterday's PC's, and the latest handheld consoles are as powerful as yesterdays consoles. That means that tomorrow, a calculator or a watch will be the only area that's still worth some good old hand optimized assembler. Poor coder. After the watch and the calculator, he will be finally extinct. So what do we do? There are two solutions: One, we adapt and start writing code that works on everything, focused on features rather than speed of one specific core feature. Or two, we slowly adapt because we have to earn a living, and we identify interesting territory so we can have some fun in our spare time. I go for the second option. Here are some areas that are still interesting, and require extreme coding and optimization skills. They also require no artistic skills, so that you can do it all by yourself, locked away in your computer room with some pizza and coke. 1. 64Kb intros. They can be fun, but for this to work, we need to make some agreements. First: Software rendering is cool. Hardware rendering too, but only if it's more than just polygon stacking. Second: Using public domain textures is OK. Third: Generated textures are the best. Just like generated meshes. Third: Lowres is cool. 2. Emulation. Can be very easy, but only when the emulated device is at least 8 times slower than the 'host device'. Try to emulate an SNES, and you start to have problems. No artistic talents are required, and you get to play lots of games for 'testing purposes'. 3. 'Lower devices'. PDA's are cool. So are some programmable calculators and the GameBoy. Especially if you use them to emulate even older devices, or if you write 4Kb intros for them. 4. AI. Did you know that AI is really in it's infancy? And I don't mean that deterministic kind of AI that is used in games; I'm talking about natural behavior, natural language, real logic, that sort of stuff. 5. Puzzles. There are some challenges out there that could use some brain and cpu power. A good example was the recently solved 'Eternity' puzzle; the man who solved it won 1 million pounds... There must be more. Let me know if you have good ideas. In the meantime, I'll elaborate on the above fields in more detail in a series of articles that I intend to write in the next couple of months. I hope that you will find something that is interesting enough for you to spend some quality time on. The emphasis will be on low-level technological knowledge (not neccessarily provided in the documents) and optimization; the goal is to find good reasons for writing good code. By the way, if you know anything about the following subjects, I would like to invite you to write a doc about it. I know nothing about these subjects, but I would really like to read a decent doc about them: 1. GameBoy programming 2. Real-time raytracing Let's have some fun. :) - Phantom. |
|
Article Series:
|