GAME 3,4,5,...

smaller dreams:

1. Scorched Earth 3D: turn-based, or interactively
2. A heli sim: but I would rather play it than program it.
3. I've been told (many times) I should start small, like Tetris, Arkanoid and Invader clones. Meh.
4. Giant Pinball: multiplayer game where each player is a ball inside the pinball machine. Might make for interesting visuals, but I would need a bit of physics, and level design is extremely important. And what exactly would be the goal of the game?
5. Epic clone! Or, since Epic is really a rip-off of the Battlestar Galactica series, I could call it a BSG clone as well. Where most space-shooters have their dogfights in the middle of open space, I believe this makes for boring dogfights (point ship - empty guns). In Epic, you were a fighter pilot who defended the fleet against enemy attacks. I just really like the idea of small fighters dogfighting in the midst of giant battleships and transportships of the fleet. IMHO, it's more interesting to fly between those ships and having to dodge tankers etc than it is to fly in empty space.
6. A 4D Stunts clone used to be part of this list, but then came TrackMania. Shame on me for still not having bought it! It's great!

GAME2: Dune

(we continue the day-dreaming :-) )

I'll describe this in the setting created by Frank Herbert, because that's how I imagine it. But I mean no copyright infringement, and so I might have to relocate this.

Every player starts with a basic "sand buggy", capable of harvesting spice on the surface, and a little gun. By harvesting spice, and selling the part you don't need (your buggy runs on spice), you gain money. You can use this money to upgrade your ride, and possibly specialize its purpose. Someone who wants to be a pirate would secure himself a fast vehicle, incapable of harvesting by itself, but capable of stealing spice from another vehicle, and blasting them to smithereens. Someone who fancies flying could secure himself an ornithopter or carry-all, to move spice harvesters, scout for spice ground, or air-to-surface attack.

The original idea was that players could also have "parts" of vehicles, that they needed to connect through standard couplings. There are a number of disadvantages: the physics engine would need to be more complex, the network delays would be more visible, multiplayer might be less rewarding because of the higher degree of cooperation.

GAME 1: Earth, Wind & Fire

Can I dream for a second?
Or rather, for a couple of years? I'm only doing my first steps in Java 3D programming, and I'm already fantasizing about big-budget A-title games. Oh well :)

MMORTS; the new killer-genre!
Every user takes one of three roles.
Fire is the basic role: this user can command fighter units, and will engage enemy units
Earth is the builder: this user can create buildings, dig trenches and blow up/convert enemy buildings. Example buildings are garages to store friendly units (while players are offline), automatic turrets, to defend everything even while players are offline, and silos to store resources.
Wind is the economist of the group; this user will gather resources, control the units that transport and harvest the resources. They will also assign these resources to other players as they see fit. This makes them powerful, but also an attractive target for extortion, attack, etc.

• Alliances are not explicit, and only very loosely enforced by the system. If a player decides to switch sides, he should be able to do so very easily.
• If a machiavellian "Wind" player decides to deliver resources to two different, fighting factions, he should be able to do so.
• Because of the previous, "ownership" of buildings, or units, is a very relative thing. When a player goes offline, what should happen to his units? Divided over remaining players, or ready to be captured, or stored away until the user returns? If the units are not stored, a player is severely punished for going offline.
• The number of units controlled by a single user should be limited, in order to force cooperation, and to stop a single player from overwhelming a band of newer players.
• The https://games-darkstar.dev.java.net project looks promising, and might very well be an excellent way to program this type of game.

The beginning, part 2

Incidentally, I feel I was right in my comment about beginnings. Now that I have my first more-or-less complete program (and it doesn't even have a lot of OpenGL code!), I believe I'm much less inclined to continue working in Java and OpenGL.

In my defense, the weather has gotten a lot better lately, so it's much more fun to ride my motorcycle anyway. It won't make me rich, though. Quite on the contrary.

SO-CAL

I've been fiddling around a bit, and I've made me this little program to display cell-automata and process the rules. This program can simulate any 2-dimensional set of rules, although as the number of possible states for a single cell increases, the memory requirements of the program will increase dramatically.

Actually, I have spent more time debugging my life automata and the rules for the different simulations, than I have spent writing openGL code. :-)

A propos performance: if I draw a 500x500 field, I'm pushing 250000 triangles, times (1 RGB color + 3 vertices), times (3 integers) = equalling 3000000 integers. My GeForce 4ti can do this around 4 times per second :-) I think if I add lighting or textures, the framerate will drop considerably.

I feel confident this program showed me what I wanted to know: that I have a basic, working knowledge of OpenGL. All the dirty OpenGL tricks I don't know about, I'll just have to look them up on OpenGL forums when I feel I might need them.

The biggest problem is not so much how to do texture or light, or push triangles. The difficult part is to bring a structure to my source files, so I won't get lost in my own source if I leave it alone for 2 days. I still haven't found a satisfying general structure for my source, but I feel it will be a solution tailored to whatever problem at hand.

Apart from that, if I want to make a game, I'll have to tackle one more major issue: networking code! Woohoo! I've read a summary on how Carmack deals with the unreliable datagram problem inside Quake3, and his approach is surprisingly elegant and blunt at the same time: send your data, every timeframe, until a frame has been confirmed you know contained the data you're trying to send. Talk about flooding.

Along with the network challenge comes a second one: timing. As soon as the game is no longer single player, the two computers will have to agree on some kind of common timeframe. How to handle "collisions" in client-server applications, and how to handle them in peer-to-peer networks?

In summary, next on my todo-list: write a simple networked action game (I'm thinking 2-player asteroids)

And then: get cracking on that killer game that'll make me rich ! Mwuhahaha!