The purpose, of the series of articles which we start with this number of DEV, is to produce and distribute a full video game to test this environment’s capabilities. This article was dedicated to establish a quick analysis to define all the features needed for the game.
Introduction
In the last number it was presented a brief review of Game Maker 6 aiming to try to explain, as concisely as possible, the arguments necessary to help us to create a video game with this ide.
We started from the concept of the room, that is comparable to a game level, describing it as an area within which the objects come to life. Objects represent the main pillar of game creation in Game Maker as they are animated entities. They are also able to respond appropriately to events, that appens during the game, by carrying out a predetermined set of actions. It was possible to understand how the Drag and Drop interface simplify and accelerate all development activities. It offers, for example, the ability to set the logic of the objects with few simple clicks and icons drags. The final argument was represented by a brief introduction to the GML language which has a very similar structure to C.
In the series of articles that follow we will deepen the study of this development environment in making a complete and easily distributable videogame. We will get a single executable file (.EXE) that can run without installing external DLLs or other files before using it.
A short analysis
This article, as already announced the introduction, although is not very technical and very discursive will help us understand: what we will realize, what are the characters in the game and what are the events that can happen.
As a video game take place only from an idea getting a concrete application is only possible by developing and describing it well. Unfortunately, our limited available space forces us to settle for a very simple game, in its structure. So we choose to resume the concept of another classic game that has made history of the arcades in the ’70s and ’80s: the famous ‘Asteroids’.
Before experiencing disappointment by this choice we try to unleash our imagination considering the possibilities offered by the environment. Think about sprites and backgrounds created with 3D graphics, smooth animations, sounds projected into a three dimensional environment. Well! In Figure 1 you can see a possible interpretation of this idea.
The next step is to organize the work by making a sketch of the general structure of the project and defining the various components. This is a critical phase and because the success of the game depends mainly from it, here is the reason why every development team devotes much time to plan and organize their work.
The game
We begin with focusing on what are the essential aspects of our project. It’s good to remember that ‘Asteroids’ was a vector graphics video game set in space where an exile ship was grappling with dozens of stray asteroids. The ship has one firearm to hit them and causing them destruction. When the asteroids explode they are divided into smaller parts and so again until, reaching the minimum size, they disappear altogether.
Every so often appears out another spaceship that shoots wildly in an attempt to shoot down the first. The player has the ability to move the spacecraft through a reactor at the rear of it. In addition, in dramatic situations, you may appeal to the instant jump to hyperspace that translates the player in a safer place.
Given that cloning a game that already exists is not the best result that we aspire to, so let’s make some changes to the original idea trying to get it more exciting.
We could make our spaceship collect bonuses that enhance the original weapon, equip the ship with nuclear warheads with a huge destruction capacity or even provide some resilience to the asteroids so that they are not destroyed at first shot.
A professional touch will be the presence of a main menu – where the player can make his choices – and a board that keeps the high scores and names of players.
Project Organization
We have already identified many features of our game which can be divided into two sections:
- The main menu
- The game
Figure 2 presents a comprehensive diagram of the functionality of each section by identifying the entities that interact with the game suddividendone responsibilities and tasks. These are essentially two players and the mechanism that regulates the sequence of events that we call system
I had wrongly indicated the ‘system‘ as an actor due to my primordial knowledge of Use Case diagrams
The player has the possibility to select an item from the main menu: start a new game, change game settings, view information about it or quit. The system, however, has the duty to regulate the timing of the various display screens in the main menu.
During the game the player can maneuver the spacecraft to fire, jump into hyperspace and catch bonuses. The system will organize levels by setting the necessary parameters, create instances of enemies and manage various events, such as:
- Game start
- Normal game
- End level
- Player Death
- End game[(/pre)][(/blockquote)]
All these situations are called states and can be well summarized by the graph in Figure 3.
As you can see when we are in the main menu the system only allows us to select a menu item or wait and to see the other screens to be cycled at regular times.
In the first phase of the game state transits to “Start Game“. After this event occurred and all the initialization operations have been completed you pass the state called “Game“. In this situation all the tasks needed to run the game, which we discussed above, are carried out.
During the game can happen that the player is destroyed so the system will check the availability of lives, and if not, it will end the game passing into the designed state. Otherwise, if player has other spacecraft continues playing regularly.
Each time that an asteroid is destroyed the system checks if there are others around the screen. If it appears that they have all been destroyed it will bring the player to the next level, but if him/her has not been through the last in which case the system will still end the game, after viewing a short congratulations sequence.
We will analyze now in detail the objects that take part to the game, we expect 4 different objects:
- The player’s ship
- Asteroids
- The enemy ship
- Bonuses
The game
The player is represented, as already said, by a spacecraft that it can rotate on itself, through lateral thrusters, be pushed forward through the back reactor, jump into hyperspace, shoot the asteroids and blast a few missiles. In addition we add the energy levels for: vitality, engines and hyperspace jumps.
The spacecraft is sensitive to collisions with asteroids and to the enemy ship’s fire. These events cause the loss of energy in proportion to the asteroid’s size or the enemy fire power. When the vital energy reaches zero the spaceship explodes and a life is deducted from those available. The power of the engines and the availability of the hyperspace jumps is conditioned by each energy level.
As facilitator we make sure that the energy increases slightly with well-defined time intervals.
Asteroids
Each asteroid has a motion determined by the direction, speed (of movement) and rotation speed. For these we define different energy levels that allow us to change their resistance to the player’s fire. When an asteroid depletes its energy it explodes and fragments to a number of pieces smaller than the original. This happens until the fragments reach a minimum size after which they disappear completely.
In later levels the smaller asteroids have a magnetic effect and are attracted to the player’s ship, making the game harder to play.
The enemy ship
The enemy ship is member of a civilization with superior technology and can perform an unlimited number of jumps in hyperspace, it don’t moves but fires in different directions depending on the position of the player. We decide that because it is difficult to strike it does not have fire resistance of the player, so it is immediately destroyed when struck.
Bonuses
To spice up the game we will ensure that the player can regenerate its energy levels, increase the firepower or increase score in order to gain additional lives. The nuclear warheads are fixed in number during the game and can not be added to the other. Score and energy bonuses comes out from inside of some asteroids, while the arms may be won by destroying an enemy ship.
The final boss
In the last level the player will face the biggest asteroid. This will be very difficult to break down as it will be very shock resistant and each will deliver a large amount of dangerous fragments.
Advances to the next item
We have reached a complete overview of our project and in the next article we will start the real development work sing sprites, sounds, backgrounds. We’ll see how to prepare the environment, how arrange the frames of our animation through the ‘Sprite Editor’ and how to use the ‘Image Editor’ for any graphic refinement.
Bibliography
- John P.Flynt, “Software Engineering for Game Developers”, Thomson, Year 2005, Codice ISBN 1-59200-155-6
- Luca Vetti Tagliati, “UML e ingegneria del software: dalla teoria alla pratica”, Hops, Year 2003, ISBN 88-8378-069-8
- Mark Overmars, “Designing Games with Game Maker”, www.gamemaker.nl
Original article
Downloads