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.
Tuesday 24 February 2009
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)
