Xiotex Studios

Early on in my career I had a fascination with operating systems and I had always wanted to write one. This appetite was somewhat satisfied with the early forays into coding on low spec machines because once your demo/game code was running they essentially took over the complete machine and became the OS. In fact, one of my most favourite comments was where I turn off the the task switching capabilities of the AmigaOS and install the demo as the OS. Okay, it’s not like writing a real OS but we could fool ourselves into thinking it was. Later on I was to have the opportunity to write a bare-bones OS for some consultancy work that never went anywhere but the fascination has remained with me to this day. This time it appears as an obsession in game startup and shutdown procedures and a compulsion to get as simple a system as I can.

This is what the main code for Warship looks like at the moment. The game doesn’t do much yet but the startup and shutdown code is not going to get more complicated than this. In fact, the main loop is in this code too:

#include "CEngine.h"
#include "CState.h"
#include "CCameraNode.h"
#include "CHoloNode.h"
#include "CActor.h"
#include "CWorld.h"

int main(int argc, char *argv[])
{
	if(CEngine::Initialise(1024.0f,768.0f,false) == FAIL)
	{
		return 0;
	}

	// Add a camera
	CCameraNode* pCameraNode = new CCameraNode();
	CEngine::SetCamera(pCameraNode);

	// Create all of our nodes
	CHoloNode* pHoloNode = new CHoloNode();

	// Initialise the sub-systems
	CState::Initialise(STATE_GAME);
	CHoloNode::Initialise(64.0f,32);

	// Create an actor and add it to the list
	CActor* pActor = new CActor();
	pActor->Initialise(CVector2(0.0f,0.0f),CVector2(1.0f,0.0f),10.0f,1.0f,1.0f,1.0f,20.0f);
	CWorld::AddActor(pActor);

	while(CState::GetState() != STATE_EXIT_GAME)
	{
		CWorld::Update(CEngine::GetTimeDelta());
		CEngine::Render();
	}

	// Shutdown the sub-systems
	CHoloNode::Shutdown();
	CState::Shutdown();
	CWorld::Shutdown();
	CEngine::Shutdown();

	return 0;
}

All the values are magic numbers for the moment because this code is work in-progress but for the most part it adheres to my obsession with simple systems.

One of the designers at a previous company once paid me a compliment and told me that I was the only developer he had worked with that got the game up and running as soon as possible using debug drawing functions and this enabled him to see if the game would be fun really early on. I was surprised by this because it seems logical to me to get the game running even if you just use cubes to represent everything and then fill in the details later. That way you can refine the gameplay and actually see something running as soon as possible while the artists work on the art assets. It also meant that the artists did not have the burden of creating a quick and ready prop stand-in but rather get to work on the final straight away. The fact that I have no patience also has a lot to do with it. I want to see the game and I want to see it now!

So today I have been following my usual tradition and getting the game up and running using debug draw functions. So every AI agent (and the player’s avatar) is represented by a circle on top of a plane at the moment. This enabled me to see that the camera model I was using wasn’t quite up to scratch and I need to alter it slightly. If I have to fight the game to do what I want then there is something obviously wrong.

Not long now before I have a playable game. Anybody want to do some early testing?

The audio in Warship is going to go a long way to completing the feel of being on a Warship. I want the player to hear a constant stream of communications chatter from the various departments as if they were being emitted from a wall mounted speaker system bought through the usual military spend - i.e. very grungy and low-tech and probably salvaged from an even older warship. Each person speaking will also be speaking through an equally grungy microphone thats probably been knocked off its table many times and generally the cheapest and crappiest piece of equipment possible. So in all we are not talking lots of money being spent on the most high-tech audio systems to promote communication throughout the ship.

To get this I record the source audio which you can find an example of here: The original

I then pass this recording through specialist audio modeling software and get: The ‘grunged’ version

I am still playing with the software to get just the right level of grunge but that is really the easy part. The hard part? Getting all the dialogue recorded. Thankfully I can also alter the audio to make it sound like various people to a certain degree so for now the players may have to put up with my bad acting but I may recruit various friends and family to lay down some vocals for me. They don’t know this yet.

Just confirmed today - got funding for Warship. More than I need to complete it too which provides a nice buffer for ‘just in case’ scenarios that always seem to crop up. On top of this I have the flash game commission which provides even more funds for the game. Life couldn’t be any better at the moment. My priority at the moment is of course getting Darwinia+ out for Introversion as I am determined to get the game out before their predicted release date, but at least the future of Warship is more secure and I have something to occupy those times that I am not working on D+.

The tutorial has been bugging me. I hate tutorials in games and I really love how 2DBoy solved the problem so I have been trying to come up with a tutorial system that fits into the context of the game without seeming like a tutorial. It’s not easy and I just bet there will be calls for a more conventional tutorial.

Now that the VM (virtual machine - the bit that runs the scripts) is up and running with new instructions being added daily it was time to tackle the other parts of the game. The camera system has been bugging me for a while and it’s one aspect of 3D work I hate so I had to take the plunge and finally update it. The result is a camera system I am happier with. It’s a basic orbit camera that follows the Warship and zooms out to see the entire battle grid based on the points of interest. The camera as always is important to the look and feel of the game and too many a game have failed due to an ineffective camera system that just gets in the way. It’s doubly important in Warship because the player does not have control over it.

Another achievement today is just as important - coming up with the logo of the game. I have a number of inspirational sources for the game and a clear vision on how I want things to look. And most importantly the logo should capture the essence of the game and after a number of iterations it finally does.

The official logo of the game

Today marks a milestone in the development of Warship. I managed to successfully contact the server, download the main script and execute it locally. Most of the work so far has been putting in place all the code to allow that to happen so up till now it was theory. My main concern was coming up with a cross platform (Mac and PC) way of doing it and that turned out to be simpler than expected. With the hard stuff out of the way the rest of the tasks involve building up the VM instruction list.

The game is essentially a simulation so once the script executes and puts all the elements in place it just runs through the simulation till it ends - whatever the end condition is.

The iPhone conversion project is going well and has reached a natural pause while I clear up some design and requirements questions with the Californian company. This has given me some breathing space to do a bit more work on Warship. Today I tackled script file loading - or more specifically remote loading.

What I want is Warship to be a heavily mod friendly game. However, I don’t want a complicated system where a player has to ‘install’ mods so to make it as simple as possible none of the script files will be stored locally. When the player first installs Warship all they will get is the thin client that can run the scripts but the scripts themselves come from a central server each time the game is played. This means that the player will always have the latest scripts and it allows a simple way for the player to browse and play user generated skirmishes. This does of course mean that the player needs to have an internet connection every time they want to play Warship but to be honest most of us do and its a small price to pay for ease of use. I am not looking to patch the client this way yet - but I can display a message telling them that their client version is out of date. Remote patching of executable’s is far too complicated at the moment (due to the many security models) but it may be something I look into in the future.

have the game plugged into the net also offers up lots of other interesting ideas. For one, I can store all the player state on the central server and allow other players to view stats and even build up a small community. One thing I would like to play with is the idea of one-shot skirmish missions. By one-shot I mean that once a player has completed it the mission is removed from the server and another player cannot have a go at it. It has always bugged me in MMO’s where you complete a mission and all you have to do is sit around for a while and reality would reset itself for the next person to play the same mission. If there is a mission in Warship then there is only one mission. This does of course mean that the game now becomes content heavy but that is okay because missions are simple to create.

Always the way, just when I am getting to the juicy bits of code something happens. I got a commission to port an iPhone game to Flash for a California based company so I am working on that for the next couple of days. Normal service will be resumed as soon as possible.

Plus, it’s actually a fun iPhone game and I am enjoying porting it.