Zorn

Development Diary

This page lists the past status texts, forming a kind of development diary.

2007-02-09 Network revamping

Code development continues to be slow, but it's still progressing. Updates are currently focussed on bugfixes and code cleanup or restructuring, rather than new features.

The current effort has resulted in a new, automatic network-object-update system. Previously, when an object (ship, asteroid etc.) was created, an appearance message was sent to the clients on the spot. Now, the server remembers when it had last successfully told each client about the object, and sends the correct message if necessary. If the client's network connection is not fast enough, the message will be dropped at sending time, the "time of last update" is not updated, and the server will try again next time. Add some message prioritization due to scope, distance from player etc. and you have a pretty spiffy self-governing system.

This is the latest and most prominent example of a development I've unfortunately witnessed: As the code becomes more and more clever / self-regulating / powerful / concise, the code readability is reduced. Not because I forget to comment what I'm doing, but because of more and more indirect and hidden behaviour. If someone else wanted to check "What happens when an object is spawned? How are the clients told?", it's no longer back-to-back in a single piece of code, but spread out into different modules. I guess the only thing I can do is leave a trail of breadcrumbs in the comments. We'll see how that works out.

2007-01-06 New release!

I've finally gotten around to a new file release from CVS. This is version 0.1.7. The most notable improvements include:

Round times and time factors. There is a 5-second break before and a 10-second break after each game round, which lasts 5 minutes by default. This time is configurable, as is a global time factor, allowing the game to be sped up or slowed down.
Powerups! Destroyed asteroids may now drop powerups (yellow on the radar). Picking up a powerup will result in bonus score, replenished energy bars, or new weapons. New weapons include a faster shot, a more powerful shot, and a spreading shot. Enemies can have these new weapons, too, and will then drop them when destroyed.
Line-mode for non-accellerated displays. All objects are drawn with simple, non-shaded lines, which is quite a lot faster in software rendering, making Zorn playable on quite old computers. However, the current font mechanism still uses textured rectangles.
A stand-alone server, thanks to new network handshaking code. Network congestion is also handled, albeit very primitively. More work on this will follow.

2006-12-15 Going slow

Due to some personal factors, work on Zorn is rather slow at the moment. Most work has been done outside of CVS for the moment. CVS should be updated soon, with a new release to follow.

There are three current work areas:

Change in the server-client handshake to allow stand-alone server processes. The "local client" is not sent any data beyond some initial text until it sends some on its own. Stand-alone servers will simply never use the local client. Alternative: once congestion control is up, the local client will cease to be flooded once it no longer accepts data.
Implementation of the time engine code. Game play is now split into seperate rounds. At the beginning and end of each round, time stops for a while. The standard round length can be set in the configuration. As a bonus, the global time factor can also be configured, allowing the entire game to be slowed down or sped up.
Line-mode for non-accellerated displays. All objects are drawn with simple, non-shaded lines, which is quite a lot faster in software rendering, making Zorn playable on quite old computers. However, the current font mechanism still uses textured rectangles. This needs to change, either to a line-based font or by direct pixel transfer.

2006-08-12 Focus on playability

The current focus is on making the game playable, in the sense of meaningful gameplay. This implies dividing games into rounds, and having round end conditions, such as a fixed time, or clearing the arena of asteroids.

My main focus is now to create a fully functional and internally correct game. This should explain why there are no more features upcoming, why the graphics are still so bad, and why there is no sound. Though I could work on those, and (as experience shows) get them running after a fairly short while, I'd rather have the game framework completely worked out before any such change. With luck, this will make future enhancements a lot easier to integrate.

Smaller changes to date are:

Players are invulnerable (but can't fire) for five seconds after spawning.
After the death of a player, there is a three second delay, after which they respawn in the center.
Shots start a bit ahead of their ships, no longer in the middle.
Players can now correctly set their names with the main menu.

2006-07-28 Graphical updates and py2exe

I've been a bit busy lately, but I've finally updated the project a bit. Several improvements were made:

The setup.py script now also supports building MS Windows binaries with py2exe. This took some effort, since some packages have problems with py2exe, but I think I've solved them.
The main display is now no longer orthogonal, but perspective. This allowes for simpler depth tricks (though simulating depth by actual depth may no longer be a "trick").
The background grid was replaced with a 3D starfield display, which is even an OpenGL display list thanks to the point above.
You can zoom in and out, by default with the PageUp / PageDown keys.
Collision may have been sped up a bit through a more elaborate object list. However, psyco may have problems with this.
Shots no longer collide as circles, but as lines. This will allow shots to be sped up.
The main menu should work a bit better now, though it's still not completely functional (changing the name does not do much).
A few bugfixes.

I'm currently revamping the network protocol. This will allow stand-alone servers (to date, the local connection always generates an active player). Next up is a thread-safe network engine, to allow the server and client to run in seperate threads as well.

Release 0.1.6 should be coming up soon. This will be the first release to include binaries for the MS Windows operating system family. New screenshots are also in order.

2006-03-05 Menu functional.

The score box and main menu have been moved to the new GUI system. The main menu now allows you to change your name, the server hostname and port, and to (re)start a single player game, or host or join a multiplayer one. The menu doesn't close itself yet, but that's just a minor annoyance. It will probably take some effort to fix, though.

Further improvements involve the green enemy guys. They now fire only when there's somthing to fire at, and will actively pursue players. This makes them quite a lot tougher.

Standing goals for the next time are:

Replacing the grid background with nice parallaxing stars.
Create "NPC handlers" to keep an eye on enemies and asteroids. This requires callbacks on object creation and death, which will be a lot of work.
Make the level parameters (size for now) customizable.

2005-03-05 GUI system running

The gui system is running. Widgets, events, the works. However, the only thing it's doing so far is duplicating the barely-functional menu and the chat box. But at least everything's running under the new system. Except for the score box.

There are several next steps. First are the small steps, like converting coordinate units, changing input names, fixing cursor movement. The next big step should be getting the menu to change networking parameters, so you can change your name, log on and off, reset the area. Further (visible) goals are:

Replacing the grid background with nice parallaxing stars.
Making the green enemy ships only fire when there's something to fire at.
Create "NPC handlers" to keep an eye on enemies and asteroids. This requires callbacks on object creation and death, which will be a lot of work.

2005-12-30 Client encapsulation

I finally put all client-side code into a Client object, just as I did with the server code. The main loop now reads like "get time, handle server, handle client". I'm not really satisfied with this thoroughly opaque main loop. I think I'll head back in the other direction again. My ideal main loop should be about 1 to 2 pages of code. And I don't like having three physics engines, I should pare them down to one again.

I've also started designing the input-event-widget-graphics system. It's quite far-reaching, but I hope it will be powerful without being complex. It should allow a menu that actually does stuff, and handle the chat box, scores, and everything else in a consistent manner.

2005-12-27 More configurations

The current version now allows one to configure:

Keyboard layout
Joystick support and layout
The font (file) to use

The server class now contains all the server logic, as well. Plus, I finally stuffed the "what if an object has zero health" code into one function.

2005-12-18 Chatting and more!

The current version (it's no longer a mockup, really) now includes:

A chat box, to chat with other players. Not pretty, but it works.
Network setup in the configuration file.
Explosions!

I also found, and fixed, a memory leak problem in the object collection code.

Further development continues nicely. On the external side, I'm thinking of putting joystick control back, and making it configurable. The keyboard should probably be configurable, too. On the internal side, stuffing server and client logic into seperate classes is also going well. The plan is now to concentrate on the object collection classes, to speed up collision tests.

2005-11-13 Client-side prediciton

The current version is progressing nicely from a "mockup" to the real thing. The last patch set added client-side prediction to lessen network loads, and started moving object management to object collections and physics engines.

Develompent now continues on:

Moving the graphics engine object management to the same collection as the physics engine
Creating an object factory to handle appearance messages
Seperating graphical and non-graphical objects
Placing movement and collision handling inside the objects

These changes should enable a new class of objects, namely those of graphical effects (like explosions) that have no physical effect.

2005-06-02 Mockup version feature complete

The mockup version is feature complete, and could, in theory, be played. The current version adds:

Armed adversaries. These are rather dumb, but still fly around firing like mad, and are worth several points.
A configuration file. The window size and player name are configurable.
A scoreboard. Each player gets a unique name, and the associated score is shown. However, removed players don't necessarily dissappear from the board.
An in-game menu (accessed with the Escape key). This menu is non-functional, but gives a nice overview of the keys used.

With the appearance of the adversaries, the current weak points of the system so far becomes apparent: sending a movement message for each object in each frame to each player is horribly inefficient, and this affects the performance at the moment. What is needed next is a client-side movement prediction (a forerunner of the triple physics engine model), and an object storage that allows the fast finding of objects in a given region.

2005-06-02 Mockup version just about playable

The mockup version is (just about) playable! The current version contains:

Multiplayer capability over TCP/IP networking.
Asteroids floating through the arena. These will replenish when their number becomes too low.
Collisions and shield energy. The faster the collision occurs, the more damage both colliders take. Asteroids split if they run out of health.
Weapons and weapon energy, to fight back against the asteroids (or other players). The weapon energy depletes when firing, but slowly regenerates otherwise.
A player score. Killing asteroids will add to your score, while dying (from shield loss) will cut it in half. The score is made possible through the new font engine.
A radar screen, showing the players, asteroids and even the arena boundary. The radar display is distorted, so that it shows everything at all times.
Rudimentary joystick controls, though these are currently disabled by default.

So, what does this mean? The addition of a score means the mockup is "playable", in such that to or more players can get together and compete in it. The score gives feedback about each player's performance, and a more skilled player should be able to maintain a higher score.

However, the game is currently completely unbalanced. Additionally, only one player's name is shown, and there is no way to distinguish one player from another on the screen. A greater score display, player names or colors, and a chat funtion are still necessary to make playing meaningful.

For the future, aside from a continuous code clean-up and the above points, I plan to start on a user interface "menu" to replace command line options, to start on a sound engine, and to add non-trivial adversaries in the form of server-controlled ships. Internally, I should start reducing network usage, and implement the multiple physics engine system.

2005-03-08 Mockup version looking good

The mockup is slowly growing. Now you can actually move around. The player inputs are passed through the network engine, and the graphics engine dutifully draws all added objects, but the input engine, physics engines and bridges are all simulated. This should gradually change.

Next on the list: Piping the server's response through the network engine (maybe time to work on some physics engines?), and then allow more than one player to connect.

After that, it should be a short step to add asteroids, player projectiles, and some collision...

2005-03-02 Mockup version underway

I'm working on a mockup, as time permits. This should allow me to actually embed the individual components in a working frame, which should eventually expand to the real thing.

I'm partly copy-and-pasting code from an old asteroids-style gamelet I never finished. Just goes to show you should never through anything away. Incidently, an asteroids game sounds perfect for a first milestone. Multiplayer, of course.

2005-01-26 First version of the network engine

The network engine is currently up, though only in CVS so far. The disconnection issue is solved, for now, in that the engine generates a "CLS" message when the connection is closed or an error occurs.

2005-01-20 Network engine being written

The network engine is coming along nicely. Currently, it has the bare minimal functionality (offline or online message passing), as long as you don't do anything fancy like, say, disconnect. This is where the design gets tricky, and where the API isn't completely finished.

Oh, and no, the code's not available yet. Patience.

Ben Deutsch