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.

Bugs bugs bugs..

I caught some sickness, hence the late blog. I'm back on track now. This doesn't mean that nothing has been done though.

While trying to fix the trigger problem mentioned in the previous blog enty (causing the server to crash because it would reference actors removed from the system), I identified several other issues. Most of them were easily fixed, but one in particular was especially hard to get nailed. It had to do with the way that boost::python converts shard_ptr from python to c++. This is done (when passing by copy or const reference) by creating a new shared_ptr that points to the same pointer but has a custom deleter. This deleter keeps a reference to the python object in order for python to find the python object when passing the shared pointer back to python. The deleter will not delete the pointer itself, but just deref the shared_ptr kept in python. This means that we could not compare shared pointers that we got from python to c++ calls, because they were entirely new ones for each call! This took me quite a while to figure out.

I've also managed to get consistent naming for the scripting and c++ calls, and documented the global functions for scripts.

Projections on the floor works now, but unfortunately they drift a little. Need to figure that out.

Yesterday I drew a very simple animated man in blender. He has the animations: run, stand, beginrun. Now you can control him instead of the tank as requested by Simon. I still need some tweaking before it looks okey though, but it is a step in the right direction.

Simon has been working on creating a set of states for the finite state machine. Especially for the tortoise model. This means that it will patrol a little and attack any players within a given radius. Pretty nice I think. We've discussed how to make it easier to model the behaviour without scripting a lot of states. For now the way to go is to add paramters to the actors that the state can query. From these parameters the state machine can figure out how to behave e.g. aggression = 200 -> go attack.

Debugging, debugging, debugging..

Simon has begun implementing a simple test level. This also means that he finds a lot of bugs and missing "must have" features in order to get his job done. I created a scale associated to an actor on order to make it scaled on the client side. This is very useful for rendering trigger areas. I enabled correct loading of config files, because when i tried to connect to a server Simon created I discovered that it didn't read the config file but just fell back to localhost. Now you can override the material used on the client from server side. You can enable rendering of triggers. Currently only as a semi-transparent sphere or cube, but soon as a projection on the "floor". Also made a bunch of other fixes. Unfortunatly Simon identified a problem with the way triggers behave when listening actors are deleted. This can make the server crash and has to be resolved. I haven't figured out the best solution yet though. The script api docs generator is done now and most of the script api has been documented. Still missing the global functions though. But things are slowly forming.

Small feature update

Implemented some of the missing features as described in the previous blog. Now you can right click on an actor and get the world position of the click point. Furthermore I implemented a debug section in the scene file where you can globally override selected attributes on other elements of the scene file, such as 'showAABB', showName' etc. I've also begun the rendering of triggers, but they are not quite done yet. Finally, I've made some documention strings for the script bindings, but this is a very cumbersome job and will be made in stages. But we severely need some API docs, so it will have to be done soon.

Saturday meetup

This saturday me and Simon met in order to do some syncronuous hacking on SteamWinter. Actually, we didn't hack much but found a much better way to define levels using the .scene files. More specific the triggering markup was way too complicated to understand and needed a brush over. Further more, we identified some other features/bugs that need fixing before we can actually make the simple level required as a part of a flight2 release. I've already done some of the stuff:

• Make areatrigger into sphere and boxtrigger
• Make 'system' a valid target for a trigger. Used when it is not an actor that is interested in a trigger event
• Revised .scene format
• Show names properly and not a generated name as previously
• Print version number to console upon start (only linux for now)

The are no missing part before we can actually make a simple level, but these are the things that should get implemented as soon as possible to easy the level editing:

• Visualization of trigger areas
• A debug mode flag indicating that all names and triggers should be rendered
• Document the script bindings!
• Build time printed to console on windows
• Click to get world position
• Tutorial of creating a simple scene

After that I'll release flight2.... probably with some flight3 features as well.

Flight3 status..

Even though flight2 hasn't really been released yet, I've begun to implement flight3 features. The only missing flight2 part is the "create small test level" part. This part is mostly handled by Simon. Since I don't wanna get bored I've just started the flight3 stuff :)

Flight3 is all about editor. Currently I've corrected the way the move tool works - Made a meshviewer - and more importantly added support for remote properties in addition to the already existing remote method calls (on the transparant proxy objects). This really paves the way for a nice editor, since properties are easy to make dropdowns etc. for.

Next steps is to create more tools, and the ability to write results to a .scene file. I believe the latter part will be the hardest one to implement.

AI is coming..

Finally I got some AI running. For this initial AI I settled for an event driven hierarchical finite state machine since it provides at lot of possibilities to the AI script writer. You can create your own states in script or in c++. I've also spend some time to get it to run on windows and I think I'm nearly there.

I've verified that the windows package now installs with all the correct dlls.. pwfeeww. One of my friends, Simon, has begun to create a simple level just to explore the fleksibility of the framework. He has already found quite a few things that need to be improved, but that is just great. Also, one of my other friends, Bue, has made a patch to the server console to make it autoscroll. This is really great, since scrolling each time a log line is output becomes very annoying and impossible if many lines are written out.

When I've got the state machine to run nicely on windows, I'll get to the editor part of the framework. This is very exciting, because that'll speed up level creation and hopefully motivate other people to make some simple levels. But is also quite a large task.

Status update

I've been on vacation the last week, so haven't had much time to hack. Anyway, I used some of my relaxing time to think about the design of the new AI framework.

I have several things that should be possible: Easy extensible through scripting, possible to define AI through XML scene files, possible to handle AI in c++. I thought a lot about it and think I've finally found the correct design. So now it is time to hack, yay.

I've also used some time to get steamwinter running on a clean windows install. It seems that every person that have tried it so far have had VC2005 installed + some other tools. These come with a bunch of DLLs that tanxoid need. The package I had created did not distrubute these DLLs. To make things worse Microsoft decided to create something called Side by Side DLLs (SxS) that should make the DLL hell disappear. Well, the solution they came up with it not exactly elegant, and I've been fiddling around with DLL manifests and the like a lot to get things to work. I still haven't verified that it works yet, since I need a clean Windows install, but a friend has a clean install and I'll get him to test it as soon as possible.

I just cannot understand why people are so excited about VC2005... I really think it sucks donkey balls big time.

SteamWinter flight2b1 (Chucky) released

Flight2 beta 1 has been released. Get it at http://projects.steamwinter.com/thegame/.

All in all the Week of changing the scene has been going very well. You can now tell what scene to be loaded using a simple gui interface. I also found some time to implement a lot of other stuff as can be seen below. This is mainly because of the easter holidays.

Changes are:

• Reload and load of new scenes possible
• Gui for quitting and entering scene to be loaded
• Client side console with command mode and script mode
• Client side python implemented
• Remote scripting from client implemented
• Server side locking possible (when multiple users are editing a level)
• Beginning of editing capabilities, but with no possibility to safe (move actor)
• Gracefully handle connection timout (not thouroughly tested though)

This week is Week of joining the server. What is actually missing is the listing of available servers. I think I'll move this to later on though. What I would like to hack on right now is the editor, because I have got a lot of easy to implement ideers. But I will resist to do that, and stick to the rest of the plan for Flight2, which is primarily: Hierarical finite state machines for controlling actor behaviour. This means that the focus for this week is the same as for next week.

SteamWinter flight1 (Gremlin) released

The first official release has been made. It's called flight 1 codename Gremlin. You will see a couple of flights before the final release version. Currently the plan for the rest of the flights can be seen in the todo file.

The main things to do in flight 2 is:

• Make it possible to (re)load a scene from the client side.
• Implement basic event driven hierarical state machine for AI
• Handle disconnections gracefully

The windows build is currently very stable. I've decided to postpone the linux sdk, since I'm the only person developing in linux. This week is the "week of changing the scene"

Week of the stable windows..

I've had a very nice weekend indeed. Lots of wow gaming and a little bit of hacking on the game, not much though. I'm now level 28... yay.

I did manage to fix the most severe bug in the windows build. It concerned the time stamping of network packages that got completely wrong because of an uninitialized variable in the client code (shame on me). It took me quite a while to discover that bug, but when it was demolished all network problems disappeared.

What I believe to be the final windows bug is identified and I'm planning to fix it this week. This means that the windows build is just as stable as the linux, and I plan to keep it like that from now on. It's just too cumbersome to make big changes in linux and the at a later point make it build in windows.

I haven't heard anything from the audio and the model guys I got in contact with, so I don't think anything will come from that front. On the positive side, I just discovered a new game collaboration site, primarily focused on content creators. I've added myself as a member in order to get in contact with some people.

Oh, regarding the title of this entry. I'm planning have a specific focus each week starting with "week of the stable windows"... stay tuned for the next entry title.

Sneak peaking flight 2..

Now that flight1 is nearly done and I'm only doing the last debugging, I couldn't control myself and went on with a flight2 feature.

Currently you have to restart both the client and the server each time you want to change/reload a scene. This can be very cumbersome for the level designer. Therefore I'm implementing a small gui for entering the scene to load and at the same time a shortcut for reloading the current scene from server. This way you can edit the scene file and hit reload, and you quickly get to view your changes.

I order for this to work I had to introduce the first client gui code and refactor at bit on the client side as well. But now you actually get a nice gui where you can enter the scene to load, and a request is sent to the server. The only missing part is for the server to actually load the selected scene. This is not as simple as it might sound, because an existing scene may already be loaded and must be unloaded first. This is currently problematic because I cannot identify scene specific and engine specific objects that has been created from the scene script. When this issue is solved the rest should be a walk in the park.

But I really should get the last win32 bug fixed first. Luckily I'll meet up with some friends for some gaming in the weekend, and I hope the get the last bugs squashed there.

A little status

• The networking code changes seems to have fixed any windows issues
• Begun creating packages using NSIS. Seems easy to do so far.

Networking improvements..

While creating networking code tests I found some bugs and some code that was not expedient. Fx. the acknowledgement of reliable UDP packages has been moved into the net library where it belongs. I also got some ideers to improve the net layer, but that is not important right now since it does fulfill our requirements for now very well.

One of the bugs discovered actually required me to touch nearly all the game code. I had to create a Time type instead of using the Real type. This is because Real may be defined as float and not as double, and a float only gives about 8 decimals precision. That is not enough for specifying absolute time, thus time variables should be guaranteed to be doubles. I have committed the corrections to svn and am looking forward to update on windows to see if it solves the retransmit problem on that platform.

I've get feedback from both the modeller and the audio dudes I contacted regarding making some content. They are both interested in doing some work and I'm looking forward to receive some of their works.

Windows Love...

The client platform of my choice is released: Ogre3d 1.4 is out!

Inspired by some of my friends at the cafe yesterday I've begun making the engine build on windows again. The plan is to port it directly to the new ogre3d 1.4 version. I think I'll make two versions available: GameDevPack and GameSDK. The GameDevPack is for everyone wanting to help coding the engine and consists of all prerequisities for that ie. you only need VS2005 and this package and you have a solution ready to be build. The GameSDK consists of all libraries, binaries, scripts and content to write a game yourself, without getting your hands dirty in the engine ie. used to make a game using scripts and xml files.

I'm currently a bit stucked because of harddrive space problems. I always manage to make my windows partition too small :) But progress is definitely made here.

Graphics

I've been ill for about a week now and not fully up to speed yet. This also means that I haven't been able to do much investigation about the AI.

Yesterday Blender 2.43 was finally released, yay. That inspired me to try to convert an actor "Enemy Sack" created by our concept artist Daniel Laursen into a 3D version. The start of the low poly version is displayed below (click for full size). The high poly will probably make use of the new sculpt mode in blender 2.43 :)


Btw. wow = lvl 20 => cat form :D

Improved debugging

Got some debugging help implement that can also be used for scene creation. I've implemented displaying of bounding boxes, names, and axes for a given actor. All this can be enabled programtically or in the xml scene specification.

On another front i cleaner up the spawn functions to be sane. Before spawning an actor included calling back and forth between the shard and the actor. This has all been eliminated and as a side bonus made a much simpler api.

Blender v2.43rc1

Just downloaded the new blender v.2.43 rc , and this one comes with a bunch of really nice features. The most exciting one is bake to texture which will allow you to bake the normals or the rendered result into a uv-map. This means that you can fake a lot of nice texture effects in a game engine easily by first creating a very detailed model in blender and bake the texture. This texture is then simply used directly in the game engine. Of course, you will have to make a bumpmap etc. to get position dependent properties, but it is really a leap forward I think. There has been a bake script available in blender for previous releases, but the up coming build in bake functionality really rocks.



All this made me even more hooked on blender and I've been messing around with it a bit. I've been reading a lot of tutorials and downloaded many new texture images, but also learned a lot of new key shortcuts which is essential when using blender. This makes the learning curve quite steep, but also makes it a very powerful tool once you get acquainted with it. Kinda the emacs of 3D modellers :)

Because I'm obviously now in model creation mode I've decided to document the mode creation pipeline for the game. This should make it much easier for new comers to get involved without getting de-motivated by the steep learning curve and lack of documentation. At the same time I'll create a very tiny tool that can be used for viewing models created without starting the game server etc. Maybe it will simply be game client run with a special command line option.

Axis ready

Yesterday I tried out my new usb numpad (I have a laptop) for drawing an axis model in blender. It worked very well indeed. I'm loving blender and are getting more addicted the more I use it. I was modelling a simple xyz-axis, where x is red, y is green and z is blue. This is a standard gizmo in all modelling tools and I've really missed it while positioning actors in the game.

The next developing aids in the pipeline are:

• Bounding box drawing
• Cirkular area drawing (by projection).
  
• Rectangular area drawing (by projection)
• Drawing text next to an actor
  
• Picking of actors in the gui, and displaying the BB
• "Drawing" of cirkular/rectangular areas in order to create Area actors

This will also be initial steps towards the editor :)