Archive for September, 2009

More 3D ship renders

Tuesday, September 29th, 2009

Its all quite exciting..

Top down view

Top down view

Cant wait to see this when its finished

Cant wait to see this when its finished

3D ship Render

Sunday, September 27th, 2009

The start of the Far Trader mkII ship

The start of the Far Trader mkII ship

A Friend of mine who has a talent for 3D work is doing a model of one of the ships in Far Trader. I can’t wait to see the finished thing.

Game Maker Radar system

Saturday, September 26th, 2009

I noticed someone had arrived at this site by searching for  ’Game Maker radar code’.  The radar system I am using in this game might not be what everyone wants, but here it is anyway.

 The premise goes something like this:

1. The player object in Far Trader creates a background image that is attached to the player object itself which gives an illusion of a rad projection.
2. Each AI ship instance spawns a radar contact object in its Create Event with the x and y value of the player. This will make a radar contact sprite for each and every spaceship object in the room appear at the players location.

Example of radar system

Example of radar system

The code looks like:

Each AI ship instance has in its Create Event

scannerRange=2000; // distance in pixels that objects can be detected
radarContact=instance_create(obj_player.x,obj_player.y,obj_ship_contact);

Then in the AI ship instances’s End Step Event add:

dist = point_distance(x,y,obj_player.x,obj_player.y);
if(dist > scannerRange) {
// hide the sprite
radarContact.image_alpha = 0.0;
} else {
// set sprite alpha as a % of dist from scannerRange
alpha = 100 - ((dist / scannerRange) * 100) ;
radarContact.image_alpha=alpha / 100 ;
}
if(dist < scannerRange) {
if(dist < 390) {
radarBlip=dist;
} else {
radarBlip=390;
}
pDirection=point_direction(x,y,obj_player.x,obj_player.y);
radarContact.x = obj_player.x - lengthdir_x(radarBlip , pDirection);
radarContact.y = obj_player.y - lengthdir_y(radarBlip , pDirection);
}

The above code will pull the radar contact instance away from the player object back to its creator instance, up to a maximum of 390 pixels. The 390 pixel limit is to match the background image attached to the player object, it can be any distance you desire, as long as its visible on the screen! All radar contacts that are greater than scannerRange pixels away have there alpha set to 0.0, which means they are not visible. Once the contact is in scannerRange, the code will set its alpha value to a % of the distance, to give an impression of range, the further away the contact, the more transparent the contact object.

The above is just an example of how I implemented the radar, code. In my game I actually have the code in a script, so that its easy to apply do a number of different object types. I hope someone finds it of use.

Far Trader – Docking and HUD

Friday, September 25th, 2009

This week has been all about getting docking working. As trading will be the focus of the game, a system for docking at places to trade is pretty much essential. Along side the docking process comes the HUD. For now, the HUD shows some basic information such as ship hull damage, fuel level, throttle indicator, speed, grid reference etc. I have also created a radar system that centres around the player object. This radar gives a nice accurate system for showing where you are in relation to other objects in the room (hat tip to 3030 Deathwar for that idea).

Additionally, I have created a test system for changing the players ship. Object inheritance and changing is possible in Game Maker, but not something that I have found easy (until I finally started to read the GM Manual!), so now you can switch between 2 different ships that have different stats on the fly.

Docking has been a complicated affair as im still learning GML, but It has forced me to restructure a lot of the code in the process, producing a more organised application structure.

Wont say any more at the moment, but heres some screen grabs:

the HUD display with docking ring active

the HUD display with docking ring active

More ship sprites

More ship sprites

Game Maker Object Inheritance

Sunday, September 20th, 2009

Game Make is a very easy to use application which gives you the ability to create decent games (or applications) in a matter of minutes, but to create awesome games, you going to have to learn GML and other programatic structures like object orientation parent classes and inheritance.

The idea of parents and inheritance is pretty simple. Lets set an example using a car as our ‘object’. Our car will be a Trebant. In Game Maker, you would create an Object in the usual way and call it for example ‘obj_trebant‘. You would then set code and actions for obj_trebant.

Now, lets say your creating a game with a number of different cars, so you go ahead and create a bunch of objects to represent different cars, applying Events and Actions to each. This could turn into a long process depending on how many car objects are in your game. You could just duplicate the first car object and change Actions for each new object you create, that will save you a bit of time. But what happens if for example you need to change a variable or action for each car object further down the line. You have to edit each object in turn, manually changing Actions and Variables.

There has to be a better way, and there is. Using parent classes and inheritance…

In order to use parent classes and inheritance to good effect, your going to have to work out what each of your cars have in common. Using our car example above lets say that all cars have headlights. You might have a piece of GML or some other Action in your obj_trebant object that defines headlights. As we want all cars to have headlights, it would make sense to create a parent object and add the headlight code into that, lets create a new object and call it ‘obj_car‘. Now, we have two objects: obj_car and obj_trebant. In your trebant object set its parent object to obj_car. Jolly good, you have now created an object with a parent.

If you test your code, you will probebly find that any code in your parent class isnt being executed, why is this? This is down to object inheritance. If you have a Create and Step event in obj_trebant, it will by default override the Create and Step events in obj_car. To combat this you need to ensure that you add the ‘call event’ action from the control menu to each Event that you want to inherit code or Actions from. If you add Action > Event Call to your Create Event of obj_trebant it will execute the code in the Create Event of obj_car, then execute the code in obj_trebant.

principles like this can be very handy in games where you create a number of objects (cars for example) that you want both the player and AI to use. Think Grand THeft Auto, where the player can get in any car, the cars are also AI controlled. So by using parents and inheritance, you dont have to create player fixed object. Your player can simply be an object that can inherit its visible object from something else obj_trebant for example. This is an easy action in Game Maker with the GML function:

object_set_parent('object to change','object to change to');

Lets say we create our player object: ‘obj_player‘. By default, lets say hes a Subaru (create an object called obj_subaru) with a parent of obj_car. If we wanted to change the type of car the player is, add a code event with the following code:

object_set_parent(obj_player,obj_subaru);

I hope the above goes a little way towards explaining how parent classes work in Game Maker and helps you to create more interesting and efficient games.