Done with the general cleanup. It has not been comitted yet, because it'll have to get acknowledgement from Simon and Lasse first (in order not to break their project for university).

Getting tired of looking at the new untextured level that Lasse made I decided til put on some texturing. I started with making the powerups (tomatoes) red, instead if the current green-brownish thing. Then I watched a video tutorial on UV mapping in blender and got inspired. So now the level is textured, with light maps for the floor mesh as well. It really helps putting on some lighting. It starts to look like a real game.

Tonight I'm going to Simons place and hopefully be really productive on SW (or perhaps just play some Wow as usual :P )

Okey... I think I've nailed the servere windows performance bug. It was a one liner actually. The only performance bug left is easily fixed and concerns sending to many net packets from the client. Just need to implement a simple form of flow control.

After the bug was nailed I've begun to fix the scheduleDelete issue mentioned in my last post. This has also brought along a lot of cleanups to the code, which feel very good to do.

The cleanup consists of:

• Move controllers to a Controllers class in order to send messages to them all using the Controllers class as target.


• Deprecated ShardEvents

Simon and Lasse have been making great progress on the little game AI project they've based on the SteamWinter engine. They have been doing an A-star implementation and are using this and the state machine (+ other thins) to make a nice enemy. It actually begins to feel like a real game :)

I've been implementing misc. things to make their life a little easier/fun (god knows there are enough things in the engine to mourn about):

• Server triggered sounds on client


• Server send status messages


• Instant collision calculations (no need to wait a tick before result anymore). This has made an enormous performance boost on startup time.


• No need to copy *.py files to files where binaries is... they're now located amongst the assets as they should've always been


• Bue has been restructuring the src code file hierarchy to be more sane

The current tasks is firstly to fix a bug in scheduleDelete(actor), that keeps the actor hanging around in python but not in the shard registry. This results in the collision handling trying to lookup an actor that does not exist in the shard anymore.

The second task is to boot into windoze (dammit) and see if I find _the_ performance bug that has been hunting us all the time.

Bue is currently rewriting the .scene loading in python. I is currently written in c++, but it has turned out to be smarter to move this into python for two reasons: The instantiantion of objects must be done in python under all circumstances because of boost::python shard_ptr hack (ie. boost::python is doing the hack), the other reason is that it makes it much easier for the game script developer to add custom scene data in the scene file.

Simon and Lasse are finishing up their project and are about to write the report as far as I know.

Progress update

As usual I've been busy at work. Having a deadline 15. August. Anyway, I've managed to do some hacking on steamwinter and here is the list of stuff done:

• Implemented a new actor type that has collision handling like World of warcraft. This new actor is called PhysicInteractor. You can set an interaction force on the new actor type, but also on RigidBody actors. This means that the new actor is able to move other actors with interaction force less that its own. Very convenient.
• Cleaned up the net code
• Made server tick into packages of max 1024 bytes, since it seems that windows is not as good as linux in handling large packages.
• Made a new branch for simplified protocol that uses RMI.

The moving of some of the protocol to RMI is coming along nicely. A simple example of a console connecting with the server:

Cryptonite Console Version 0.1 (build Wed Jul 25 00:01:27 CEST 2007)
File console.cfg requested for reading...
Loading configuration file 'console.cfg': OK!
Waiting for connections on port 12346...
>
> # Connect to the game server
> s = connect('localhost',12345)
Connecting to server localhost:12345
>
> # Get the remote session object
> rs = s.remote()
>
> # Lookup the root object on the game server
> rroot = rs.lookup("Root")
>
> # Load a scene on the game server
> rroot.loadShard("scene/test2.scene")
>
> # Join the scene on the game server in order to get ticks etc.
> rroot.joinScene()
Unhandled packet ALST
Unhandled packet CRTE
Unhandled packet FCAC
> Unhandled packet TICK
>
> # For fun, list the known objects on the game server
> rs.list()
[('TEST', 3L), ('IdentifiableLock', 4L), ('Root', 5L), ('Session from 12346', 6L),
('Shard', 7L), ('TestAxis2', 13L), ('Cross2', 14L), ('QTestBug', 15L),
('Terrain', 16L), ('TerrainLALA', 17L), ('Barrelddd', 18L), ('Barrelddd', 19L),
('Barrel 0', 22L), ('Barrel 1', 23L), ('Barrel 2', 24L), ('Barrel 3', 25L),
('Barrel 0', 26L), ('Barrel 1', 27L), ('Barrel 2', 28L), ('Barrel 3', 29L),
('Player', 31L)]
>

Happy birthday

Happy birthday SteamWinter... Well, actually it was on the 1. july, but better late than never. So what have been accomplished so far: We have written an game server engine, and rewritten it again just for good measure. The second version of the engine is highly scriptable and can read scenes from a scene xml file. We can handle collisions, rigid bodies, triggers, timed events and everything can be extended or used in python scripts. A reliable network layer has been added on top of UDP, in order to only require a single port to be open in the players firewall. An auto-introspective RMI implementation has been created in order for scripts in both ends (client/server) to easily communicate. Special high performance requests can skip the RMI layer (e.g. server tick sent to clients). A simple client has been implemented with a minimal gui for connecting to the server. The client can render the state as told by the server and a few simple visual effects have been provided. Sound and music is also a part of the client, but is currently in a unknown state.

On the design part we've also accomplished a lot: The setting has been initially set to be below ground in an icey environment. A rough story has been suggested and a great deal of concept art draw. A single piece of concept art has been modeled in a 3D editor and integrated in the game (a tortoise). Various game mechanics has been though of and a few of them tested.

So, what have we learned so far...

First of all, it turned out to be much more difficult to keep people exited about the project or to take responsibility of some of the parts. I would have hoped to be much further right now and actually have a fully playable game. The lesson learned is that just because people like playing games, does not imply that they actually want to make them... well, they probably want to but they don't really want to. And you just have to really want it to stay motivated. Taking on a project like this is a huge task and the more I delve into it, the more impressed I am with some of the great games out there.

Second, we have been in need of content since day one. We do have some great concept art, but actually content such as sounds, models, backgrounds, stories, quests etc. has been hard to come by. We still need a hole lot of this in order to get an impressive game.

All in all it has been a great journey so far, and we can see the light at the end of the tunnel. But much work lies ahead before the first real beta version will get released.

So, what are the plan for the year to come you might ask. Some of the things I would like to do is:

• Client up net handlers now that RMI can be utilized. This will bring great flexibility, since you will be able to customize messages between client and server using scripts.
• Move scene loading to script. Currently all scene loading is done in C++, this remnants of the days of the pure C++ engine. Now it is just very awkward to use. Moving it to script world will make it very easy for game writers to insert their own custom xml in the scene files. Further more it will clean up the loading a lot.
• Scripted Client GUI. Currently the gui is handled in C++, but since this is not very dependent on speed, it should be move into scripting. This will also make it easy to customize the GUI.
• Enhanced scripting support on client. Currently the server is highly scriptable. The client lacks behind in this fashion. Delivering a bunch of common functionally to the scripting world on the client is the first and largest step. e.g. Easy dialog displaying, associate buttons with script actions, customized menues. When this is exposed to the client, we get it exposed to the server as well for free via the RMI (if allowed by engine security)
• Sound and music
• Effects on the client should be reviewed and improved
• The server should drop the dependency on the OGRE library
• Models: 2 bosses, 4 normal enemies and 20 gizmoes (barrel, pipe, plant etc.)
• A well though out and tested game mechanic for cooperative playing
• A nice and motivating story..
  

There is probably a lot of other stuff to get done, but this is from the top of my head.

Enough about the birthday...

Because Simon and Lasse are probably going to base a university project on the engine I've set the net stuff I told you about in the previous blog on hold. I've made a branch for it and will pick it up again as soon as possible.

Instead, I'll implement some kind of default intelligence into the non-rigid body actors that are collidable. Currently you will have to handle this all by yourself, meaning that if it is not handled an actor will go through walls. This is the first issue that I'll handle.

Net changes

The client scanning part triggered a larger cleanup session than I initially imagined. The timing is probably not the best, but it will minimize the protocol part and make i quite stable. At the same time it will get easier to extend client/server functionallity because this will be implemented using RMI instead of protocol magic tags. This leaves only non-connection oriented packages to be specially handled. Currently this is the TICK packet ( from server to client) and the ACTION packet ( from client to server). When this is cleaned up I'll get into the new type of actors that provides WoW style collisions.

Still alive :)

Busy at work...

But this is what I've been up to the last approx. 14 days. Refactoring the client net stuff in order to support scanning of servers. Added new client side menu system. It is not complete yet because the scanning stuff needs to get finalized first. Updated the scripting docs to look a bit more fancy and hopefully easier to use:

http://www.steamwinter.com/files/script_api_docs.html

That's about it for now :)