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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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