How exactly does one go from making design document for an action/arcade-style game to making it happen on screen? Do you just start programming the game after you're done designing it and then just wing it until you've found something that works, or is there a more methodical way to do it? The reason I ask is because I've come to realize that designing an action game is very different from designing something like a text adventure game. With the latter, it's much easier to go from the design to the programming because there's nothing moving around. How do you go from words and static pictures in a design to making characters objects move around and interact with each other on screen?
From Paper to Screen
This isn't a game design question, this is essentially "How do you program?"
Choose a language or an engine, follow some tutorials.
Choose a language or an engine, follow some tutorials.
Author
I know you need to pick a language or engine. You misunderstood what I'm asking. I don't know how to state it any more clearly than I have.
I might recommend starting with some kind of proof of concept. Particularly for game elements that you haven't worked on before or if you think they're particularly innovative. It should help you figure out if what you have in mind is within your abilities, what sort of additional work you're going to need to do, and maybe give some indication if your idea is fun.
If you're starting completely from scratch and have no idea where to begin, I say try to get something on the screen and control its position with mouse or keyboard.
If you don't know how to begin going about doing that then there's more programming fundamentals you'll need to learn.
It sound to me like your asking a pipeline question, and I think this has mostly to do with your design ideas involved in your genre of choice. If you have assets then I would toy around with an existing engine. I've found a handful of useful basic tutorials for free from this website.
Like mentioned, learn from the masters who've achieved the elements you know exist, after that start building the pipeline towards your own designs. Then publish them, because the more we share and publish our successful approaches to this craft the easier it is for everyone new to the craft to build on "the basics".
Like learning to craft a checkers board. The process has been mastered by others, it is learning the reason for the process that matters, to help you build other gaming boards of your own.
Game dev isn't really a linear (waterfall) process, where you first design everything, and then you implement the design. In practice, that approach just doesn't work.
You need to iterate on your designs -- make an an initial design, implement it, play it, hypothesize how it could be refined or made more fun, change the design, and repeat.
This is something that's missed by a lot of "idea guys" who've been designing their magnum opus for 10 years in isolation... In the real world, the designer is extremely active throughout the entire development cycle, guiding and refining the implementation as it comes into being.
You need to iterate on your designs -- make an an initial design, implement it, play it, hypothesize how it could be refined or made more fun, change the design, and repeat.
This is something that's missed by a lot of "idea guys" who've been designing their magnum opus for 10 years in isolation... In the real world, the designer is extremely active throughout the entire development cycle, guiding and refining the implementation as it comes into being.
In a a text adventure game the possibilities are really limited, so you can think of everything that can happen beforehand. In action games things can get messy, because the player has more control and might do things you have not anticipated. I'm assuming your question is about tackling this problem. If so:
One method is to try and think of the possibilities you haven't though of yet. It's hard and time consuming, but that's part of both programming and game design. Try to come up with as many "what if"s as you can, can come up with solution for them.
Another popular method is to create a gameplay prototype. This prototype has the specific gameplay that you have in your action game, but none of the other parts of the game (story, art, levels, sound, particular assets, etc.). This allows you to play around with your gameplay and tweak it until it becomes fun.
I hope that answers your question. There might be other methods which I am unaware of.
This isn't a game design question, this is essentially "How do you program?"
Agreed. Moving to a more appropriate forum.
I know im new, but im in this stage myself. To begin, i suggest teambox.com, its amazing for file and task management.
You need your GDD(General/Game Design Document) which you have. next is your feature list.
1.Feature List:
I think next your gonna need to make like a list of features and their children dependencies. Once you get the ball rolling generally, others can hop in and help you out(start your team!)
For example:
- FeatureA
- FeatureB - Depends on FeatureA
- FeatureB-1
- FeatureB-2
- FeatureB-2-1
- FeatureB-2-2
- FeatureC
- FeatureD
How this helps:
- having a more concentrated view of what's gonna make up the game.
- Establishing any needed prerequisites.
- Determining development order, for example, if featureB depends on featureA then we cant finish B until A is finished.
- Determine development times - The more you break things down, the easier it is to determine how long things will take
Doing this feature list helps out with the high-level and low-level designs
2.High-Level Design:
Once we have a feature list, we can start documenting the standard flow of the game overall and for specific features or scenarios. What i mean by this is, we can make flow charts depicting what major actions/events should happen for a normal user. You would do this in general, and also for the major features. When we get to this stage, ill elaborate more.
How this helps - The documentation process is trying to get everyone on the same page, so everyone has the an idea of whats gonna be done as close as possible to what you originally imagined.
- The flow charts now help everyone get on the same page of how things are going to go in terms of order and time.
Doing the high-level design helps out with the low-level, so that way there is a general written understanding of how things should go, IN GENERAL.
3.Low Level Design:
This is actually getting more into how the code or file structure might look. Its not specifically planning out the code, but trying to now refine on the general understanding presented by the high-level design, and make it more fine tuned on your vision.
This is going to be drawing out some UML diagrams. Deciding what API's, frameworks, libraries were gonna use etc.
How this helps - This is kinda like High-level design. Except now we are starting to inch our way towards how development will be. For Example: What
4.Development Environment setup
This is where you start setting up your development environments to match for everyone helping with the game. You want them to be identical so you can easily edit and add to each others code, files, art, etc...
For file & code share - You can do it open source perhaps on something like sourceforge or github. Or you can use dropbox or google drive i think ( although i havent tried that out )
then, you need some UML Diagrams.
Activity Diagram: http://en.wikipedia.org/wiki/Activity_diagram
Sequence Diagram: http://en.wikipedia.org/wiki/Sequence_diagram
Use Case Diagram: http://en.wikipedia.org/wiki/Use_Case_Diagram
NOTE: These dont have to be too complex and with super clearity. They can if you want, and that would help, but the point is to help get your idea down fully in documentation.
- Activity Diagrams:
- You want to draw out an activity diagram for the general usage of a user. It should outline the flow and possibilities the average user will face from their registration on wards. This means all the different pages they can goto and things they can do, in general.
- You want an activity diagram for money currency. This should outline the flow of how a user can get currency, and how they can spend it from when they start the action that gets them the currency, to when and how they can use.
- You want an activity diagram for your car system and getting new items. It should outline how you can get new items, from when the player logs on, going over all the possibilities and ways they can, to when they get the item and its shown how each possibility can end.
- Use Case Diagrams:
- You want a use case diagram for user-to-user interaction. This should show basic interactions two users can have between one another, and how they all relate.
- You want a use case diagram for user-to-shop interaction. This should show basic interactions between a user and shop, and how they relate.
- Sequence Diagrams:
- You want a sequence diagram for anything that requires more than one click. The process from login -> picking your car -> logout, of a user buying a car in the shop, then another diagram for editing that car(if there are catagories, you want one for each catagory. Example would be painting = 1, parts upgrades =1, type of car your buying =1, for 3 total).
Then, after all that, your ready to code(because youve put the ENTIRE game in writing, all you need to do is code the diagrams youve made, and the game will come together)
HOPE IT HELPS!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
