Objectives

The next thing to think about is what sort of things will the player be allowed or expected to do. The player will interact with AI controlled instances in a number of ways depending on the mission type.

Initially, I'll focus on shooting things, and being shot at by AI instances. I'm guessing these will fall into four categories:

• Ground based static position e.g turret
• Air based static position e.g barrage balloon
• Ground based dynamic positon e.g trucks and troops
• Air based dynamic positions e.g aircraft

Homing missiles

I've now moved onto homing missiles. Once activated they simply 'home' in onto the mouse pointer. This was created for test purposes, but it might be the case that it stays in the game. I like the idea of a laser guided missile, allowing the player to guide the missile with the mouse pointer. Might be fun, if a little difficult to control.

I set the direction of the missile using the following code. It's crude but it works.

if instance_exists(mouse_pointer)
{
dir = point_direction(x,y,(instance_nearest(x,y,mouse_pointer)).x, (instance_nearest(x,y,mouse_pointer).y)-20)
}

Explosions FX Video

A video showing a very basic flight model, explosions FX and parallax scrolling. I intend to go OTT with the particle effect. Lots of debris everywhere.

Flight model

Got a basic flight model up and running. As the game will be heli-something based, I've opted for the classic LEFT, RIGHT and UP for thrust controls. Gravity will obviously control the downwards motion.

I want to get a tipping/leaning motion in on the player vehicle, where the nose dips downwards for left and right movements. This will hopefully make the vehicle feel more weighty.

At this point I've decided I'm going to cut corners with the player vehicle sprite, mirroring the sprites for the left and right movements.

Parallax scrolling

I want the camera to track the player as they move about the level. GM supports views whereby the user can specify which object to follow (in this case the player vehicle). However just panning the screen around with the player vehicle in the centre of the screen would look dull.

To add a bit of depth to the levels, I also want the levels to be constructed from 3 distinct layers. A foreground, the middleground where the action actually takes place, and a background. The foreground and background images are simply there as graphical eye candy to add a bit of parallax scrolling. This is fairly straightforward to do in GM.

The level is constructed as a room in the usual way. Once you've enabled views, you can specify which portion of the room you want to see on screen. If you have specified the player vehicle in the Object Following field, in simple terms you can get this portion (or view) to slide about the room under the players control.

I have two objects called Background_Scroller and Foreground_Scroller and these must be placed in the room.

Background_Scroller

Depth: 10000

Draw call:

draw_background_tiled(bgnd_image_mountains, view_xview*0.6, view_yview)

Foreground_Scroller

Depth: -10000

Draw call:

draw_background_tiled(foregnd_image_01, -view_xview*0.6, view_yview)

NOTES:

The two draw calls detailed above simply draw the backgrounds, but at different 'scaled' offsets in x. As the player moves the view around, so the value of view_xview changes and hence the speeds of the scrolling of each changes. Hence the parallax.

bgnd_image_mountains and foregnd_image_01 are images defined as backgrounds.

Objects have depths which are simply values used to control the order in which things are drawn (think of this as Z-depth). Remember X is across the screen, Y is up and down the screen, and Z is in and out of the screen. Things that have a +Z are into the screen, whilst things that have a -Z are out of the screen.

My Background Mountains want to be drawn first (far away into the screen) and hence have a large positive value of ZDepth.

My Foreground wants to be drawn last (nearest to the camera and furthest out of the screen) and hence has a large negative value of ZDepth.

Truck sketch

I did a quick sketch earlier of a truck. Even though the game is viewed side-on, there is no reason why we can't skew the view slightly to add interest. I'm a fan of this 3/4 view, where we can easily add depth to the sprites to make them feel more solid.

Impact FX

After getting the basic animation for the explosion sprite nailed, it was clear that the explosion didn't feel very powerful, lacking any form of impact.

This was easily sorted by adding a simple white 'ring' sprite added at the origin of the explosion. This sprite could then be scaled up and decreased in alpha over a very short period mimicking a fake shockwave from the explosion.

Explosions test bed

I've spent a few moments creating a little test bed for trying out fx/explosions/shrapnel. In the test bed, at the click of a button, I can drop bombs which fall to the ground, triggering a frame-by-frame animation for an explosion.

I wanted to avoid using alpha'd particle systems for the explosion and opted for a hand drawn animation style. It's more time consuming to create like this, but the results will be in keeping with the art style of the finished game.

Once I'm happy with a basic ground explosion, I'll create a placeholder object and blow the crap out of it.

Stuff that blows up

It's fun blowing up stuff. It's fun watching stuff burn. Initially I'll be working on getting some of the more 'fun' rewarding elements done first. Lots of particle effects. Lots of debris.

The game

The game will be a 2D side scrolling something-em-up. It will have shooty bits, collecty bits and hopefully other bits to try to add variety to the gameplay. Other than that, I have no firm game design.

My approach for this game design will be to try it and see. As I don't have a publisher breathing down my neck 'steering' the game design, I can pretty much please myself. Why struggle for days to get a complicated feature working, when you can replace that feature with something far simpler and far more achievable. Don't set your sights too high.

The developer

I am not a programmer. I am however a big fan of all things 2D and retro.

Gamemaker (GM) allows someone like me, with little prior programming knowledge, to create 2D and move it about on-screen. GM uses a simple drag and drop interface to get you started, and also supports GML its own programming language (if you are feeling brave).

I use GM for its flexibility and ease of use. It allows the user to quickly playtest ideas and concepts to see if they play half as well as they think they should. It quickly allows you to discover if an idea is worth developing.

I will be developing this game in my spare time. I have a day job. I imagine updates to the game and this blog will happen in bursts. Sometimes frequent, sometimes not so.

The blog

This blog will track the development of an indie game from the initial concept ideas through to completion. Hopefully over time this will have many uses. It will document the development process of an indie game created in Gamemaker (GM). Hopefully allowing other GM users to see my approach will perhaps allow them to avoid making the same potential mistakes that I am bound to make over the course of this project.

This 'developers diary' approach will also allow me to look back on this project and its progression in detail.

I might of course reach a real stumbling block at some point in the future, and ditch the whole project for something new. If this does happen, at least it will be documented up to that point.