Let’s Get Physical

Physics is something we witness the effects of every day so it should be really straightforward to program, right? No. It turns out that even with Game Maker Studio’s in-built physics engine, computers still don’t really know what physics is. On top of that, adding physics components to a game is so far outside my comfort zone I would probably find it easier to hit myself by firing a cannonball round the planet from the top of a very tall building. Physics programming appears to require a combination of maths, general knowledge and luck.

Well anyway, I appear to have rockets working now. For now. They arc gracefully/correctly, hit the thing they’re supposed to 75 per cent of the time, and actually destroy the thing they hit (if they’re supposed to) most of the time.

The little yellow dots in the image below are place-holder images for the thruster trail which slowly drop and fade as they emit from the rocket, hence the reason why none of the rockets in this picture look like they emanate from the turret (you’ll just have to take my word for it.) Also, this image shows three different rockets in sequence just in case you were feeling discombobulated.

There was supposed to be an earth-shattering kaboom.

There was supposed to be an earth-shattering kaboom.

In order to fire rockets at your enemy, the minimum you’ll need to have is a power unit (left of image) to keep the other structures on line; a weapons command room (underground at bottom); a rocket store (above weapons command) stocked with at least one rocket; and a turret. It may sound like a lot of hoops to jump through simply to obliterate your foe with projectiles, but this is just the first few items in a tree of options which should make game play more interesting.

For example, you only need one weapons command room in your base but because it controls all weapons, if it goes down for any reason it will temporarily knock out your ability to retaliate and force you to alter your priorities to react to the situation and find a way of regaining the upper hand. I really like the idea of a branching dependency structure. It’s been done really well before in games like Command and Conquer; I’m wanting to bring that mechanic to a more personal, micro-managed level. Because micro-management can be fun!

The next thing I want to work on is assigning and keeping track of every placed unit’s properties so they can have hit points and give other bonuses depending on if they have power or are manned. Although I haven’t yet started this it seems, on paper at least, to be less difficult than programming physics.

In my next post I’m going to talk more about some of the features I’d like to implement (this is more a note to myself but thought you’d like to know that too.)

Fin

Do What You Want

I’m a strong believer that there’s no wrong way to play a game; each method is just a series of choices made by a player.

You can point players in the general direction of what you want from them, clearly defining rules at the start of the experience so players know if they try to do something you haven’t planned for they’re going to walk into an invisible wall or make nearby characters bob up and down like ghost ducks. Or both.

In most games, certain choices will be outside the scope of anything the designer ever expected or planned for, so making those choices will cause the game to glitch. The designer’s aim is to either plan for every eventuality, or to design a core system robust enough that it can take whatever is thrown at it. Or in the case of Half Life 2, a Barney robust enough that he can take whatever furniture you throw at him (with the gravity gun).

It costs more to build underground but it could pay for itself.

It costs more to build underground but it could pay for itself.

With my work-in-progress Debaser I want to give players the tools and say “here you go, do what you like”, then players can think of ways to use these tools to outsmart the other player. For example, you can build underground. It’s a little more expensive (because excavation costs money, right?) but there are at least two advantages: one, there’s natural cover from the ground (although it can still be hit by projectiles), and two, you can tunnel to the other base and annoy them with explosives.

When one player chooses to build in a certain way this will influence the other player’s choices, which should lead to dynamic exchanges. I want people to play my game and say, “oh you think that’s clever, huh? Well what about… THIS?” [insert unexpected change of tactics and evil laughter].

I think the fun of my game will come from the variety of tools at a player’s disposal to help them decide the way they want to play.

Fin

Introduce Yourself

Hi!

Yes I have an IKEA stool on my head.

This was the first photo of me I had to hand.

My name is Finlay Costello. I make stuff. At the moment I’m trying to make a computer game.

My version of being a programmer consists of having a thousand browser tabs open with snippets of code in them that worked for other people in other slightly similar circumstances who all appear to have more of a clue than I do about how to achieve what I’m trying to create.

If you like reading about someone attempting to program whilst simultaneously having a full time job, a full time family, a photography business on the side, and a habit of fixing computers for everyone they know when their Windows registry breaks (happens a lot), and you remember the start of this sentence, then this is the blog for you!

I’m going to attempt to use this place as a development log when interesting stuff happens in my game-making journey. I reserve the right to also blog about my favourite games and try to understand what is so awesome about them (as it seems to me anyway – feel free to disagree, right?) Sometimes I may go completely off on a tangent. If you’re very lucky I might read you some of my poetry first.

So sit back, relax, then sit up straight and pay attention. I’m not sure about this either so let’s see how it goes, eh? :)

Fin