Programming Tips

[Trogdorgar]

I've been reading around the forums and seen a few things about how the game works, but I am thinking about getting into programming stuff like this, and was wanting to know how to program some of the stuff you did.

A. The "Thermal Expansion" Effect
B. The energy chains and packets
C. How did you set up the delay between packet sends: Was it basically TimeFrame+=TimeFrame*Generation
D. Any other helpful tips you could give to help someone starting out to get a general idea of programming these types of games.

[knucracker]

A: There is a little bit of magic sauce in the technique I use for the Creeper... (as in a technique that I developed specifically for getting it to work in flash at acceptable performance levels).  What I can say is that the problem is really no different than something like the Game of Life.  Imagine a two dimensional array.  Iterate through the array left to right, top to bottom.  Now set the state of each cell based on the state of surrounding cells.  Repeat the iteration, etc.  If you play with different rules as well as things like floating point values instead of booleans at each cell location, you will discover some interesting effects and toys.  So, choose your fav language and learn enough about the graphics libraries to render a two dimension array as a series of colored squares.  Then start to experiment.

B: Packets are routed along the pathways between structures using a path-finding algorithm called A*.  Internally, every structure in the game is represented by a base class called "Place".  Places can have connections to other places (the "paths").  Packets move from place to place.  At each place a packet runs the A* algorithm to find the shortest path to wherever it is going.  This tells the packet which of the available next places it should move to.

C: CW is a frame-locked game.  This is on purpose...  This means that the game loop does things like calculate creeper expansion, packet routing, and rendering.  Now not everything happens on every loop of the game.  But as the game slows down, _everything_ slows down.  This is a wise choice for a game like CW where performance can vary but you want fair treatment across different runs of the game.  Other game engine choices might be to measure the time delta between each game loop and adjust game physics based on that delta T.  This makes things run at the same wall time across fast and slow computers.  So for CW every game loop updates a counter.  Packets get produced after so many loops have passed (that's a simplification, but basically what goes on).

D: Write toys before you write games.... don't over design to start with.  Games are art.... they aren't bridges, roads, or power plants.  Engineering principles will guide your implementation but they won't help you make a fun game.  So you must be a competent software developer and skilled with the language and apis that you will use.  You must have played many games and have a preference for what you like and don't like.  You must have patience beyond description and persistence to match.  You will also be wise to give yourself small goals that you can reach.  Start with something simple and reach that goal.... then have the courage to set another higher goal and reach it.  Do this over and over and over.  And lastly, remember to work on games that you enjoy!  (Else you won't make a very good game).

[Aurzel]

that's so poetic virgil, you almost want to make me go into game developing

[Karsten75]

A young boy once asked Mozart how to write symphonies.  Mozart replied that the boy should perhaps start by writing lighter and smaller pieces of music (sonnets?).

"But at age 10 you wrote symphonies!" the boy exclaimed.

"Yes, but I did not have to ask anyone how to do it," replied Mozart.

Not meant as a comment on the capabilities of anyone posting on this thread, just an interesting thing I've read, and Virgil's advice brought it to mind.

[Aurzel]

sonnets are short poem's kar not short pieces of music, and is that true or something someone made up?

[Karsten75]

sonnets are short poem's kar not short pieces of music, and is that true or something someone made up?

I read it recently. But I read a lot, so unfortunately I don't remember exactly where.

[Commander Strife]

This game has already made me wanna go into game development, only poor thing that i haven't even got any tols to help me atleast learn.

[knucracker]

If you have never done much development before, then I'd recommend grabbing java and reading through some hello world tutorials.  Don't get in a hurry, it will take you a while to get going.  Also don't chase after a game at all costs.  Take time to learn and structure your code.  Think of it like learning a martial art.  Wax on, wax off... repeat :)

You will find that writing any software is kinda like playing a strategy game in itself.  Except it has a much larger scale than even Supreme Commander and you can play the same mission for many, many months.  You will also lose some, and you won't always be the best player.  But if you like playing the game, over the course of years you can do some really amazing and impressive things.

[Sauffaus]

Wax on... wax off.... Wax on...

rofl ... The Virgil Guide to Programming  ;D

[Timwi]

Virgil - what is the reason for using the A* search algorithm? Surely in CW, Dijkstra's algorithm would have been sufficient. The A* algorithm is intended to work with any weighted graph, including graphs in which some of the weights are negative. In CW, the "weights" are the lengths of the paths between the places, which clearly are never negative. For such a graph (where all the weights are non-negative), Dijkstra's algorithm is functionally equivalent to A*, but simpler to implement - and possibly more efficient too because it can use the assumption that all the weights are non-negative to its advantage. Sorry if I sound like a smartass :)

[mniip]

The A* algorythm is like this www.igaek.ru/bac.bmp?