#10 Planning ahead

So, we’re just about done here with our framework code. There’s not much happening in our “game” yet, and for some unknown reason, we had practically all the functionality a couple of tutorials back, we’ve just been rewriting and refactoring since then. So, now what? Can we finally start making this awesome game we’ve been wanting to for so long?

Unfortunately, much as you probably could, the answer for these tutorials is no.

We have a decent little framework ontop of Maratis to work with now, we really shouldn’t just dive in and code like crazy, even though we really want to. That’s a surefire way to end up with a huge pile of code that mostly works, but then when you want to add something new at a later date, you can’t because half of the data is somewhere that you’ve got no way of easily accessing.

So, how do we avoid this. Yet more planning and preparation unfortunately. I’ll try to be quick with this section, because I want to get onto making the game as much as any reader might. This isn’t the kind of step to be skipped lightly though, without at least a decent idea of where you’re aiming, in terms of code structure, you’re probably going to end up with a mess.

So, we have to first begin with thinking what we want to make. For this tutorial series, we’re making a semi-FPS game. I asked quickly on the Maratis forum, and FPS and driving games were the only 2 options given. There’s a lot of quite specific work involved with a driving game, but a lot of ideas and code can be reused from an FPS game to a lot of other genres.

Now, the issue with FPS games is that you have to have intelligent AI for them to be interesting, or a decent multiplayer setup, or at very least, a gripping story. I am offering none of these. AI will take far too long at this stage, Maratis hasn’t got any networking built in and I’m no writer. If this tutorial gets enough attention and feedback, I will consider writing supplementary tutorials afterwards on a couple of these topics. I’ve already tentatively suggested that “Stage 3” of this tutorial series will be vehicle based, to allow our player to get into a car. With all this in mind, we had best design the most flexible game possible, while sticking to specific targets.

As we won’t have any AI enemies, at least until a later point, it seems sensible to make something a little silly in order to give the bare bones of the game a little appeal, so I’ve decided that it will be a paintball game.

So, let’s think of the last few things I wrote. First of all, there’s the deal with the vehicles. Vehicles tend to control and behave differently to a person walking, so that means that we’ll have to handle the input and controls in a way that lets us switch what’s happening easily. We don’t want the player to be able to move with FPS controls while in a car for example. Secondly, I’ve said that it’s a paintball game. That means that we want projectiles that go splat. That means we want to be able to see what comes out of the gun, and we want decals where they hit. So we’ve already got some plans about how we want things to work and what features we should be aiming for.

Next thing we have to think about is how to we want to separate up functionality. It’s quite simple to make a behaviour for our “Player” and let it take the strain of everything that we want to do with it, the issue with that is that it soon becomes huge and unwieldy. So we probably want to try to keep things split up so we can keep file sizes small and localise functionality. As such we probably want to split the player up. If we say that the Player behaviour contains no functionality itself, just an interface for the editor. Then we can start breaking things up with what the player needs to do. This is going to be by no means an exhaustive list. The code itself will grow and be redesigned as we go along.

If we can decide what functions the player will have to do, that should help break up the code. First of all, there’s the movement. This could potentially be supplemented, so we’d best have a control state machine to handle switching between states. The movement states can be classes which listen to the input manager as we’ve already done, then handle the events in whatever way necessary. Currently Maratis examples do this by applying a physics force to the object. We can probably emulate that, or just directly move the object. There are benefits to both solutions. When we come to implement this, we’ll come to make a decision. As we’ve already delegated this to a separate class, the decision shouldn’t affect anything. Next we’ll need to have something taking care of our weapon stuff, “pulling the trigger” for example. Potentially we can split it up a little and have inventory management within a subclass of that, again, when we come to implement it, we can make these decisions. There are also some things which the player potentially needs, like health. As we don’t have anyone shooting back at us, it might be a bit of a redundant feature, but we’ll see.

So, what happens when we fire a bullet… or pellet, or whatever. Now, potentially we want to see things fire out of the barrel of the gun towards our mark. There’s an issue with this though, in order to have something which is actually visible, we might need to exaggerate the size of the projectile. If we have a rapid fire gun, a lot of these exaggerated projectiles would potentially produce an almost solid beam of projectiles infront of the player. The simple way to do this is to not actually have a visible projectile for every bullet fired, maybe every 5th bullet.

That should be enough to give us a good idea about what we want to do. There will, most likely be design decisions along the way, but they should fairly easily be dealt with on top of what we’ve just planned.

Leave a Reply

Your email address will not be published. Required fields are marked *

Diary of a Slacker