Current game concept
Toggle, the game I have been developing, is a 2D puzzle game where the player controls a ball which is moving at a constant but bounces off solid objects such as walls and closed gates. The player must use 'toggles', which are embedded in the floor and toggle their own coloured gates' states. A gate can be either open or closed and there are 3 different colours, yet combinations of those colours for the gates which are affected by more than one coloured toggle.
The objective of the game is to reach the black hole which the ball falls through to the next level. This is achieved by toggling the gates in the right combination and navigating the ball through the level. The challenge in the game is two-fold: both controlling the ball and solving the puzzle whilst under the pressure of controlling the ball.
Challenges
A lot of the challenge in the implementation of the game has been about achieving the ball movement. The game simply stores the angle of velocity, which the player can affect with the left and right arrow keys. From this, it calculates where the ball should move to next using trigonometry.
Another big challenge in the game was that originally, because of inherent restrictions in the game engine, the ball movement was unmanageably jerky. The games engine, MegaZeux, uses a limited character set, where each character, or tile, is 8x14 pixels in size. Game objects are limited by the game engine to move one character at a time, so moving one pixel at a time proved a great challenge for implementation. This was achieved by storing pixel coordinates of the ball rather than board coordinates and then the ball was blitted to the character set each time it was moved.
For level design, I have coded the game objects to be as easy to interact with as possible. For example, if you would like to place a gate on the level, a 'gate' object has to be selected and then the colour can be selected from a palette. The game will automatically place a gate at the relevant place during the gameplay.
Alternate game concept
The player must control a ball around using only the mouse to tilt the three-dimensional maze. The ball will be affected by gravity, but the direction of gravity will change when certain pads are hit by the ball. The game would test the player skill of control over the ball and several puzzles where pads would need to be hit in a certain order. Hitting an erroneous pad could have disastrous consequences and send the player far back in the level.
This would again test my math skills -- trigonometry would play a big part of calculating how the ball would move -- along with more general problem solving skills which are inherent in any coding.
Wednesday, 11 March 2009
Tuesday, 24 February 2009
Game Sketching
As Agustin, M. et al (2007) put it, "the essence of a sketch is an abstract representation that gives an overview of a piece of work without dwelling on the details of the implementation." Game sketching is a method of exploring and evaluating concepts of games whilst spending minimal resources on implementation. This differs from prototyping, which aims to produce a limited implementation of a game before evaluation.
The value of game sketching
Since so little resources are spent on implementing sketches, there is an increased tendency to spark conversation and discussion about the sketch. This increased discussion around the concept can save time and money later when the prototype or even final implementation would have to be changed to include new ideas.
Game sketching as part of the game development lifecycle
Agustin, M. et al (2007) recommend that game sketching takes very early in the development process, soon after the games concept is realised. Game sketching should take place before the games design document is written, but after the games concept and business parameters. It can take place alongside the development of art concepts.
Limitations
Game sketching should not be seen as a part of the production cycle, but rather as part of pre-production. It is about ideation and inspiring communication rather than producing useful content for the final implementation; no content created for the game sketch should be used in the end-product. This is the limitation of game sketching, and if it is ignored then the creativity and usefulness of the process is compromised. Agustin, M. et al (2007) give an example of this where one group of students, using the game sketching software, try to create something of too high a fidelity but become frustrated by the limitations and their end-product is nothing like the game sketch.
References
Agustin, M.; Chuang, G.; Delgado, A.; Ortega, A.; Seaver, J.; Buchanan, J. W.: Game Sketching. Perth, Western Australia, 2007.
The value of game sketching
Since so little resources are spent on implementing sketches, there is an increased tendency to spark conversation and discussion about the sketch. This increased discussion around the concept can save time and money later when the prototype or even final implementation would have to be changed to include new ideas.
Game sketching as part of the game development lifecycle
Agustin, M. et al (2007) recommend that game sketching takes very early in the development process, soon after the games concept is realised. Game sketching should take place before the games design document is written, but after the games concept and business parameters. It can take place alongside the development of art concepts.
Limitations
Game sketching should not be seen as a part of the production cycle, but rather as part of pre-production. It is about ideation and inspiring communication rather than producing useful content for the final implementation; no content created for the game sketch should be used in the end-product. This is the limitation of game sketching, and if it is ignored then the creativity and usefulness of the process is compromised. Agustin, M. et al (2007) give an example of this where one group of students, using the game sketching software, try to create something of too high a fidelity but become frustrated by the limitations and their end-product is nothing like the game sketch.
References
Agustin, M.; Chuang, G.; Delgado, A.; Ortega, A.; Seaver, J.; Buchanan, J. W.: Game Sketching. Perth, Western Australia, 2007.
Sunday, 8 February 2009
What are game assets?
Various definitions
Bethke, in his book 'Game Development and Production', chapter 8, lists the following as game assets: 2D sprites, 3D models, missions, levels, areas, voice, key framing and motion capture, sound effects, music and special effects.
Wikipedia lists the following definition: 'Game assets are the "things" that go into a game. Some examples of assets are artwork (including textures and 3D models), sound effects and music, text, dialogue and anything else that is presented to the user.'
Premnath, J. M., writing for the Deccan Herald states that "the concept artist sketches the concepts for the levels in the game, characters, vehicles and other visual element [sic] such as props... [which] once finalised... materialise into game assets, which can be plugged into the game engine." In summary, he writes that "game assets are everything that contributes to the visual appearance of the game."
Ben Carter, in his book 'The Game Asset Pipeline', (p. 2) describes game assets as "artwork, sounds, video, maps, and other data."
Summary
Aside from Premnath, who restricts his definition to include solely the visual elements, game assets are described as being any piece of data which:
a) is in a format that can be used by the game engine,
b) will be presented to the user.
This constitutes everything which could be included in the final game aside from code, scripts and documentation.
Bethke, in his book 'Game Development and Production', chapter 8, lists the following as game assets: 2D sprites, 3D models, missions, levels, areas, voice, key framing and motion capture, sound effects, music and special effects.
Wikipedia lists the following definition: 'Game assets are the "things" that go into a game. Some examples of assets are artwork (including textures and 3D models), sound effects and music, text, dialogue and anything else that is presented to the user.'
Premnath, J. M., writing for the Deccan Herald states that "the concept artist sketches the concepts for the levels in the game, characters, vehicles and other visual element [sic] such as props... [which] once finalised... materialise into game assets, which can be plugged into the game engine." In summary, he writes that "game assets are everything that contributes to the visual appearance of the game."
Ben Carter, in his book 'The Game Asset Pipeline', (p. 2) describes game assets as "artwork, sounds, video, maps, and other data."
Summary
Aside from Premnath, who restricts his definition to include solely the visual elements, game assets are described as being any piece of data which:
a) is in a format that can be used by the game engine,
b) will be presented to the user.
This constitutes everything which could be included in the final game aside from code, scripts and documentation.
Tuesday, 3 February 2009
Business rules for developing games
The benefits of using the game project triangle
The game project triangle allows that you choose two out of the three goals of 'on budget', 'on time' and 'high-quality/feature rich'. The benefit of recognising this is that you only miss one goal, rather than two or three if you had failed to comply.
Questions
1) What are you trying to accomplish with this game?
Create a game whilst solving problems inherent to a restrictive games engine.
2) When must you complete the game project?
13th March, a week before the deadline.
3) How much money do you have to produce it?
None.
4) Who do you have to get the job done?
Myself.
Achieving an ultra-low-budget game
Bethke recommends two paths to take when seeking to produce an 'ultra-low-budget' game: a small game or a mod. The game should:
a) include a lower number of highly-polished features rather than a higher number of less-polished features
b) be "simple but playable"
c) "require a minimum of engineering to get functional."
Primary, secondary and tertiary features as a method of supporting development
During development it is important to categorise your game's planned features by priority -- primary being the core features. Depending on time available, these features should shift between priorities; for example, if you have more time then a secondary feature may become a primary feature. The rationale behind this is that, firstly, having too many 'must-do items' puts unnecessary pressure on the development team and, secondly, features have an inherent priority anyway, but only through recognising this will you be able to realise which features you really need.
The game project triangle allows that you choose two out of the three goals of 'on budget', 'on time' and 'high-quality/feature rich'. The benefit of recognising this is that you only miss one goal, rather than two or three if you had failed to comply.
Questions
1) What are you trying to accomplish with this game?
Create a game whilst solving problems inherent to a restrictive games engine.
2) When must you complete the game project?
13th March, a week before the deadline.
3) How much money do you have to produce it?
None.
4) Who do you have to get the job done?
Myself.
Achieving an ultra-low-budget game
Bethke recommends two paths to take when seeking to produce an 'ultra-low-budget' game: a small game or a mod. The game should:
a) include a lower number of highly-polished features rather than a higher number of less-polished features
b) be "simple but playable"
c) "require a minimum of engineering to get functional."
Primary, secondary and tertiary features as a method of supporting development
During development it is important to categorise your game's planned features by priority -- primary being the core features. Depending on time available, these features should shift between priorities; for example, if you have more time then a secondary feature may become a primary feature. The rationale behind this is that, firstly, having too many 'must-do items' puts unnecessary pressure on the development team and, secondly, features have an inherent priority anyway, but only through recognising this will you be able to realise which features you really need.
Subscribe to:
Posts (Atom)
