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.
Saturday, 29 November 2008
Concept Art
Sections relevant for concept art
World backstory
Artefacts from the world
Characters
Appearance
Items belonging to the particular character
Level design
Related to world backstory; artefacts
Features of the level
Concept (taken from the design document)
Guide the protagonist through the dangerous, political world of Victorian London. The tension between technology and the Church is becoming more volatile than the steam engines driving the Industrial Revolution. Pursued by both sides, pacifist Henry Darker is getting out. Traverse platforms, solve puzzles and escape. Combining slow-paced problem-solving with scenes requiring quick-thinking and a highly-interactive environment, the player guides the protagonist through cobbled streets, stations and dingy sewers to safety.
Example 1 for the character 'The Watchmaker'
Conceptualised here is the eyepiece ('spectacle attachment with manual zoom') that this character wears. As well as an artistic drawing of the piece, a technical diagram of the zoom mechanism has been drawn; in-keeping with the character's technical nature.
Example 2 - Henry Darker
This piece shows the appearance of the protagonist, Henry Darker, and shows some of the contemporary fashion within the game.
World backstory
Artefacts from the world
Characters
Appearance
Items belonging to the particular character
Level design
Related to world backstory; artefacts
Features of the level
Concept (taken from the design document)
Guide the protagonist through the dangerous, political world of Victorian London. The tension between technology and the Church is becoming more volatile than the steam engines driving the Industrial Revolution. Pursued by both sides, pacifist Henry Darker is getting out. Traverse platforms, solve puzzles and escape. Combining slow-paced problem-solving with scenes requiring quick-thinking and a highly-interactive environment, the player guides the protagonist through cobbled streets, stations and dingy sewers to safety.
Example 1 for the character 'The Watchmaker'
Conceptualised here is the eyepiece ('spectacle attachment with manual zoom') that this character wears. As well as an artistic drawing of the piece, a technical diagram of the zoom mechanism has been drawn; in-keeping with the character's technical nature.
Example 2 - Henry Darker
This piece shows the appearance of the protagonist, Henry Darker, and shows some of the contemporary fashion within the game.
Sunday, 9 November 2008
Studio 6 | Exploring Playability
Summary
In 'Level Design for Games', Chapter 1, Phil Co describes the process of designing and implementing a game. This process is split up into two categories: preproduction and production. The former involves hiring a team, brainstorming and planning out the game whilst the latter consists largely of implementation, but also revising and building on the original plans and reimplementing in an iterative fashion. Phil Co largely focuses on the team members involved, specifically highlighting the structure and hierarchy of the team, but also gives solid examples of the content that needs to be created.
During the preproduction stage, Phil Co advocates that both a 'high concept' -- a creative description of the concept -- and a more detailed design document are created. For the design document, he suggests using diagrams to model the menu, world and level design.
He also writes about the concept of the 'asset pipeline' which describes "the rules and standards by which all content is created and brought into the game", i.e. the method of importing assets into the game engine.
Although he defines many team leaders and sub-team leaders, Phil Co advocates that each team should work closely with each other and communication is vital.
Similarities
Phil Co's idea of the "high concept" maps directly onto Bethke's initial definition of the game concept; they both set the mood and aim to give an overview of the gameplay style. Both recommend that a detailed list of assets is created for inclusion in the design document. Both also recommend that the shell menus are described in detail.
Differences
Phil Co's text focuses a lot more on the team members involved, whereas Bethke barely mentions it. Instead, Bethke goes into a great deal more detail about the design document and lays his text out into comprehensive sections, also talking a lot more about story. Bethke also focuses more on user-interaction with the game.
Whereas Bethke focuses primarily on the design document, Phil Co provides a wider view of the process of creating a game.
In 'Level Design for Games', Chapter 1, Phil Co describes the process of designing and implementing a game. This process is split up into two categories: preproduction and production. The former involves hiring a team, brainstorming and planning out the game whilst the latter consists largely of implementation, but also revising and building on the original plans and reimplementing in an iterative fashion. Phil Co largely focuses on the team members involved, specifically highlighting the structure and hierarchy of the team, but also gives solid examples of the content that needs to be created.
During the preproduction stage, Phil Co advocates that both a 'high concept' -- a creative description of the concept -- and a more detailed design document are created. For the design document, he suggests using diagrams to model the menu, world and level design.
He also writes about the concept of the 'asset pipeline' which describes "the rules and standards by which all content is created and brought into the game", i.e. the method of importing assets into the game engine.
Although he defines many team leaders and sub-team leaders, Phil Co advocates that each team should work closely with each other and communication is vital.
Similarities
Phil Co's idea of the "high concept" maps directly onto Bethke's initial definition of the game concept; they both set the mood and aim to give an overview of the gameplay style. Both recommend that a detailed list of assets is created for inclusion in the design document. Both also recommend that the shell menus are described in detail.
Differences
Phil Co's text focuses a lot more on the team members involved, whereas Bethke barely mentions it. Instead, Bethke goes into a great deal more detail about the design document and lays his text out into comprehensive sections, also talking a lot more about story. Bethke also focuses more on user-interaction with the game.
Whereas Bethke focuses primarily on the design document, Phil Co provides a wider view of the process of creating a game.
Tuesday, 21 October 2008
Studio 3 | Use Cases
Threadspace: Hyperbol
Below, the actor is always the player, aside from 'Game Object Interaction', where the actor is the spaceship.
This shows how the player interacts with the game, i.e. the input.
Here the actor is the spaceship, which interacts with other in-game objects.
Also showing how the player interacts with the game, this time the visual output.
This time the audio output, but also input. The game enables VoIP, hence the player can speak and listen to vocals.
Below, the actor is always the player, aside from 'Game Object Interaction', where the actor is the spaceship.
This shows how the player interacts with the game, i.e. the input.
Here the actor is the spaceship, which interacts with other in-game objects.
Also showing how the player interacts with the game, this time the visual output.
This time the audio output, but also input. The game enables VoIP, hence the player can speak and listen to vocals.
Subscribe to:
Posts (Atom)
