Older blog entries for chakie (starting at number 268)

Been a bit bad at keeping my diary up to date. Christmas was busy and I've been busy at work too. I kinda like it here, no complaints. Keeps me busy with pretty fun work, all Linux related development.

Much more work done on Civil, and many simplifications done. I guess I'll have to start readding some complexity back once I get deeper into the realtime aspects of the game, but that's a later problem. For now simple is good. I don't actually think we'll ever run into too hard problems with realtime stuff, as Civil isn't a fast paced FPS or RTS. It is more like a slow RTS where nothing happens faster than once a second, as the game scale is quite strategic. We could for instance make one game world second correspond to 5-10 seconds or the real world, or maybe even make it adjustable so that the players can get faster action when there isn't too much action.

I'm so tired. Got up far too early this morning after a night where I slept badly. Well, in one hour I can go home and take a nap. Aaah... :)

Progress on Civil is good and I've done some real nice stuff. I managed to pretty easily simplify a lot of stuff that was just too complicated, thus throwing out hundreds of lines of old code. It's sometimes good to get back to old code after being away for a while, as it makes it easier to spot those things that are just more or less braindead.

All the setup stuff and scenario loading seems to work ok now, tonight I'll start on making the server keep time and actually run the main game loop. This is where I expect some more code to be written and some problems to creep up. I think the server will get a separate thread that manages the incoming data in order to make the main loop as simple as possible. Only time will tell how well it all works out in the end.

Lots of Civil hacking. I'm actually getting somewhere, and hundreds of lines of old and obsolete code is getting mercilessly slaughtered. Much fun is being had. ;)

I also tried to get GStreamer to compile. Well, it compiled ok and also installed ok. I didn't bother reading any docs at all, so I didn't find anything evident that would actually show it stream some G:s. There was a gst-player package, so I tried that too. It didn't compile at all. Complains about some undefined functions that just don't seem to be available in either GStreamer or the player itself. The link line that barfed out seemed to link in hundreds of Gnome libraries and it looked just too messy, so I didn't bother trying to find out what it actually does, why it does it and what can be done to not do it.

So much for that testing then... All libraries should IMHO always have a simple "Hello world" application that shows in some trivial way that the lib is actually working so that one doesn't have to try to install all kinds of different extra stuff just to see the lib doing something.

Archit: I think most people that want to follow IRC discussions do it live on IRC... :)

Been doing some more Civil stuff. It's real fun to work on it again, although I don't have that much time to spend on it. Fortunately Python is a fast language to develop in.

A slow weekend, nothing much done on Civil, but I intend to get some stuff done today. The source has been neglected for a while and with a few months distance to it I can see some things I want to clean up. The graphics could be separated a bit better in "setup dialog graphics" and "in-game graphics". Those two share very little apart from some mouse pointers, so they should IMHO be separated.

Sourcewise I started looking a bit at the new server that has to be created. It'll be brutally simple and just contain the main game engine and a minimal amount of extra code to provide for the necessary networking system to be set up.

I'd also like to clean up the setup dialogs a little bit to make them clearer from a UI perspective. The data that is shown on each dialog isn't always that clear and the player can be a bit confused at times. This may also have to wait for a while until I have the main game up and running again.

I've been thinking a bit about the RTS engine, and come to the conclusion that it doesn't need to be as "realtime" as many other engines. One second in the game propably simulates 1-10 seconds real time, and there isn't too much that happens on a strategic scale in 10 seconds. Thus the engine can propably do its updates only about once a second and the players can see units perform actions at a maximum of once per second. Having the engine calculate updates once a second also takes away some of the effect of network lag. One player always has to connect to the other player's computer to play, and thus is at a network latency disadvantage compared to the player that has the server locally. But if the server performs updates once a second it has some time to receive the orders from the remote player too. Of course, if the order misses the current calculation turn it will be mercilessly delayed for one second. If this is very bad, I don't know.

I started doing the conversion of Civil from turnbased to realtime based. Nothing major yet, just some browsing around the code and getting familiar with it again after a few months pause. Did some basic coding which just guarantees that the current CVS version is broken. :)

I think this will be a good thing, and it shouldn't actually be that big a change code wise. I hope...

I decided to start working a bit on Civil again. It needs some loving to get to a stable 1.0 release. Actually, I have some more or less grand plans for it, which mean some pretty fundamental changes. Again. :)

After careful thought I've come to the conclusion that keeping Civil as a turnbased game as it is now is after all a bit too complex and makes the gameplay a bit on the slow side. So I'll start looking at changing it back to a realtime-ish engine. It all started out as a realtime engine a few years back, but got converted to turnbased at some point. TB as we do it does add some unnecessary complexity making the code larger and harder to maintain. I'm very proud of the code, it is easy to work with, but there is a lot of it.

The changes would roughly be:

  • introduce an external server where both players connect to. This server keeps all the game logic and determines what happens and when
  • the game UI:s (map etc) the players see are just dumb "terminals". The players give orders which are submitted to the server for processing.
  • the server sends out data for everything that happens, such as movements, formation changes, combat etc.
  • time would move in an accelerated fashion, with maybe 10x speed.
  • I think this makes for a funnier game after all... :)

This makes the clients a lot simpler, still keeping roughly the same amount of code for the actual logic, this time just moved out into a separate process. Having both players connect to the server makes them equal from the server's point of view, which is good.

Of course, this change does introduce the problem of networking again. Somehow I don't think it will be such a big problem after all, as this is a much slower game compared to a FPS game or even other RTS games. It doesn't really matter too much if a few packets are a second late. I'll use TCP anyway, so data won't get lost.

Civil has over the years been such a fun project that I can't stand to see it go without any attention. It deserves to get done properly.

Work has been suprisingly fun, although I still feel I have so much to learn. This whole embedded Linux thing is a whole new world for me, I've never really don anything like that before. Been playing with various embedded evaluation boards and tried to set up suitable environments for development.

mikehearn: indeed, now I found it. I stand corrected. :) It is apparently not always a visible option, so I must've always searched for it when it was not selectable. The previewing makes Evolution more sluggish than it needs to be, as just scrolling among messages with the cursor keys meant that it had to render every single message.

259 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!