|home | et13 - game prototyping in Gamemaker||prev | next|
15 - MIDI demo continued -
Game Design Sequence
WORKING WITH 2D TOOLS IN UNITY
ET13 – Week 15
Creating an entire Shooting Game / and a new way of organizing assets
In the Assets folder in the project window:
SCORING AND USER INTERFACE
description and tutorial
Search the net (or teacher's folder) for .MID files
Audition MIDI files from media player. MIDI files are the vectors of a musical performance. The final performance of a MIDI file is determined by the local synthesizer (internal or external) in the case of Windows machines it is the MS SoftSynth.
Editing MIDI, however requires a sequencer/editor program that outputs the .MID file format.
To convert MIDI to audio, patch the output of the Media Player to be recorded to Sound Forge; or import the MIDI file into ACID and save as audio.
|WAV @ 22khz 16bit mono||2.5 megs|
MP3 @ 44khz 128bit stereo
|MIDI file||30-100 kb|
After the file is converted, it can then be brought into GameMaker as a WAV or MP3 to preserve the actual performance of your synthesizer but be aware of audio file size. Any audio file much over a MEG can crash GameMaker on load or playback. Save after every import!! MIDI files can be played in GameMaker as background music providing the most efficient format for music in games.
THE GAME DESIGN SEQUENCE
The Main Concept - The Goal/Topic
Every game must have a clearly defned goal. This may seem obvious but it is a very common mistake. Game design goals are the absolute difference between a good and bad game. Some times the importance of clear goals does not become evident untill later in the development cycle, and then it may be too late. The topic must resonate with the player and the game play; and remember, the number one job is to be the advocate for the player!
Research and Prep
Once a concept has been decided on and a goal defined, everything about this topic must be researched. The best game designers immerse themselves in their game's topic, it's world, and it's language.
This is where the play mechanic is applied. What makes your concept a game? Why would it be fun? Would it be fun using physical pieces? or does it have to be digital? Will it be replayable for hours? or a casual couple of minutes? This is where the concept, the goal and the main topic is made to be playable.
This applies to both physical and digital games. It also applies to both 2D and 3D gaming. How does the user interact with the game? Is the player an avatar (3rd person, remove)? first person? Do we use the cursor keys? a mouse? on-screen buttons? special game controller? joystick? And that's just the I of I/O. For the output, how does the game feed back to the user? Heads-up display? sound? vibration?
Game Play Mechanic or Structure
How do we maintain the fantasy of the game and still have a practical system? a working piece of software? The game play still needs to center on the main concept. Does the complexity of the the design exceed the limits of the available tools? Can the tools deliver the suspension of disbelief? Can the player find the optimum game experience that allows the attainment of flow? Remember, too many features can also just get in the way! How can you empower the user within practical restraints?
This is where the concept and game mechanic must be laid out as a logical flow chart to be created in software. All of the commands and instructions that are to be engineered must be possible with the authoring/programming tools. This is where all variables and routines need to be clearly defined and proven capable. All resources, such as memory, storage space, processor speed; need to be mapped out and tested to show if the game will actually run on the platform hardware. The program needs to be stable and bullet-proof to the user's every possible action. Code must force the desired action and still be as elegant and efficiant as possible.
If all of the above plans have proven themselves, then documentaion needs to be formalized. Commit all design features to paper. Define the I/O structure and the game play mechanic in terms of programming instruction. Reconcile the player's experience with the technical considerations.
This is the easiest part of the process, believe it or not! Though it is repetitive, it is generally very straightforward. It requires patience, acquired skill, and dedicated focus. It cannot be rushed or under done. In a sense, this process requires as much "flow" as the actual game play itself.
Needless to say, this activity is as important as all of the other design procedures put together. Playtesting should be started the moment any part of the game is playable. And testing will need to happen again and again, for every possible combination of the program. Sometimes this happens just to find (and kill) the bugs; sometimes this happens to determine the target audience of the game for marketing purposes. But again, the main job is for the benefit of the end player.
Review & Repeat (if neccessary!)
Once the game is playable; or released; the feedback will never stop. Everyone is a critic. As a designer, the decision rests on you as to whether the game is complete. But the public is the final judge. If they don't buy the game, you lose the money AND your message as a game developer is not heard. If you are satisfied that you have met all or most of your original goals, celabrate; and start planning your next project!!
(Special thanks to Chris Crawford)
Continuation of in-class demo project: adding scoring engine, level navigations, balancing game play.
Copyright © 2001-2014, David Javelosa unless otherwise stated.