Creating a complete game design is overwhelming

Started by
7 comments, last by ImpossibleDream 12 years, 4 months ago
I have studied game design ( not in school ) by reading articles and guides on the internet and even read some game designs for other games.

It's just amazingly overwhelming imo.
I can only imagine what the game design for skyrim must have looked like.. :o
.. And even worse... how much work it must have taken to create it the design.
I've also done movie screenplays before and I seriously think that creating a movie screenplay is way easier than creating a game design.

Some game designs are ofcourse easier to do than others.
It just feels like programmers have it so much easier than us designers.. if you count away the part of having to learn how to program first.
I've played around with game makers and it's so much more fun to design a game as you're building it part by part but it feels pointless at the same time.

Even if you make a decent - OKish game with a gamemaker with minimal programming..
And then make some "OK" profits on selling it..
You're still going to want to make your next game better than the last and to do that you need to go through the nightmare of making a proper game design or being a professional programmer.
So it don't make sense to me to waste your time by not doing the first game properly without a gamemaker.


I just wonder what the other game designers here thinks?
Anyone here who has made a complete game design for a more "sandboxy, non-linear" rpg like Fallout 3, elder scrolls series, dragon age etc?
Did you find it as overwhelming as I'm finding it? Any tips?
Has it been made yet or is it in development?
How long did it take to make the design?

If you haven't made game designs of at least the complexity of the above mentioned type of games..
What kind of game design did you make and how easy/hard did you find it?
Advertisement
You're confused. What you're talking about isn't game design per say. Programmers do not have it easier, no. Nor do artists. Or sound designers. Or anyone else. If you want to design, you do not spend your time learning programming alone -- you learn art, scripting, level design, math, literature, history, et al. Clear?
"I will personally burn everything I've made to the fucking ground if I think I can catch them in the flames."
~ Gabe
"I don't mean to rush you but you are keeping two civilizations waiting!"
~ Cavil, BSG.
"If it's really important to you that other people follow your True Brace Style, it just indicates you're inexperienced. Go find something productive to do."
[size=2]~ Bregma

"Well, you're not alone.


There's a club for people like that. It's called Everybody and we meet at the bar[size=2].

"

[size=2]~

[size=1]Antheus
Well, I'll agree that making a large game's design is overwhelming and a larger project than writing a screenplay. But I wouldn't say game designing is harder than programming or being an artist or being a musician. For me personally game design is the easiest of those four things.

One of the largest game designs I worked on was for a single-player j-style RPG (except arcade-style combat instead of turn-based). 27,500 words and less than half done adding all the details of puzzle designs and NPC dialogue. That's available online if you want to look at it: Xenallure Design Doc

With that same amount of words I could have had a complete design for a smaller game that had little story and no puzzles, just missions or levels of the main game play. But typically I've worked in group projects where fortunately it's not my job to complete the design by filling in all the stats of all the monsters, or the level design details. If I was trying to be both the designer and the programmer I wouldn't plan every detail out ahead of time before developing, because I would want to playtest things as I went along.

I want to help design a "sandpark" MMO. Optional interactive story with quests and deeply characterized NPCs, plus sandbox elements like player-craftable housing and lots of other crafting. If you are starting a design of this type, please PM me. I also love pet-breeding games.

Game design for a large project is like any other large scale engineering task: you take big complicated chunks and break them down into smaller less complicated chunks. Try things out and discard or modify things that don't work. Iteratively build and grow simpler things into more complex things.
Design is definitely a big task, but programming also involves design elements-- it's fine to describe how you want some certain feature to work, but the programmer has to figure out how to actually make it work and that can also be a very complicated task. Games are complex pieces of software, and the more of one you are responsible for overseeing the more complicated and difficult your role becomes. On really big projects design is spread among several people and teams, which makes things more manageable. Doing something like Fallout 3 on your own I would imagine is overwhelming be default.

The only reason that you're able to do the design part and still make a game with a gamemaking program is because programmers did an enormous amount of work upfront, and once the product is in your hands all of the programming for your project is done. The fact that you don't see that work happening doesn't make it easy. I feel pretty confident that no matter how difficult it is to make your designs, the coding required to make them happen would be far from trivial. I suppose it's possible that your design approach would be thorough enough to encompass code design as well, but in that case you would just be combining the two tasks into one.


For my own part, I've been doing both design and programming on small projects. I've found both to be quite challenging, but then again I'm not particularly good at either and issues in the one can confound the other. Focusing on small aspects at a time is what has helped to keep me moving forward, and once I've got a system working I can plug the whole module into a bigger picture. I have found that I'm generally working with the same degree of complexity at any given level of design or programming, and the key is to recognize which level I'm currently looking at and abstract away anything from elsewhere.

-------R.I.P.-------

Selective Quote

~Too Late - Too Soon~

I'm working on my own RPG, in fact we've nearly finished our initial prototype that will demonstrate some of the core systems of the game. I certainly understand the feeling of being overwhelmed, as there is so much to keep track of. To keep on top of it the two things that I have found most important are:

1) Use other people. Having friends to bounce ideas off or do a bit of documentation for you will make things much easier. It's much less overwhelming to edit what somebody else has written than it is to create something from scratch, and if you get stuck some outside input is always helpful.

2) Break things down into as many sections as possible. If you just have a page entitled "RPG DESIGN DOCUMENT", then you wont get very far as you will have no idea where to start. But if you break it down into the various different areas you need to design; Narrative, Exploration, Combat, Trade, UI (for example). And then break those categories down even further, it's much easier to tackle things as they come. Take the 'Abilities' section of my doc, for example, that's probably 5 pages on its own with about ten sub-categories, and that doesn't even contain the ability list for the game (which I have a separate spreadsheet for). But working through each of those sub categories isn't too daunting.

- How will abilities be equipped?
- What will abilities cost to use?
- How do I balance weaker and stronger ones?
- Do they 'level up' with use? How does that work? etc.

At the end of the day, even the largest and most complex of projects can start very simply and be broken down. Take Fallout 3 as an example. "I have an idea for a game. It'll be a first person open world RPG set in a nuclear wasteland." From there, you start breaking the idea down into its core mechanics. And then go through each of them in turn to flesh them out. If you struggle to do that though, practice with smaller projects first. They're complicated enough to design as it is. Finally, if you're just starting out, learn some scripting and how to use level editors. UDK is good and free for both of those. Learn some Java as that will give you an excellent grasp of scripting principles, which I promise you will find useful when it comes time to implement this great mechanic you designed, but can't find anyone willing to code it all for you.
If you consider the act of building a house, you might see some major parallels to making a game. First comes the idea, then putting that idea onto paper, then gathering the necessary resources and employees, then building a foundation, framework, laying piping, etc. In general, games tend to be a massive undertaking regardless of their simplicity. Often it's difficult to know about all the meetings, issues, bugs, and unforseen consequences at the start of a project.

All the advice, and it is all awesome advice, points to starting small and growing with time. Prototype different aspects of the initial idea to see if they make sense and tweak them before they make it into the final product, on paper and in code. Art can start rough, with simple textures and no animations. Writing can start as a rough structure of the core storyline. Programming can start as the base framework and a series of prototypes. Design can start as a rough document outlining the idea in bulleted format. The tough part isn't this initial setup, but rather following through on and expansion of those ideas. It's a battle between the big and little picture, and limiting yourself from the get-go will help make the transition between steps much easier.
How about try to design tic tac toe. Then when you finish designing tic tac toe, go ahead and design a game of chess. Try it, and before you say it's too easy or too complex, you need to finish the design first. Recreate these simple games first. After you finish recreating these more simple designs, add a few twist to it, and build from there. As you add more twist, your creativity creates more twist and turns. Finally, to know if your work is done, learn to remove the twist that you test out with players and they don't like it. This is the simple process. You have to go through the process at a simple level and work from the ground level. We may call this GROUND ZERO.

Take a look at this: https://plus.google.com/u/0/105363132599081141035/posts/2c8nSivyukS
It will improve your perspective.
I use QueryPerformanceFrequency(), and the result averages to 8 nanoseconds or about 13 cpu cycles (1.66GHz CPU). Is that reasonable?
I though that the assembly equivalent to accessing unaligned data would be something similar to this order:

  • move
  • mask
  • shift
  • move
  • mask
  • shift
  • or

So it seems reasonable to say that it takes 14 cycles for unaligned data since we'll have to do the series of instructions once to access and once to assign?
You're crazy! Designing the game is the best part. With a good design, the game practically programs it's self. The programming is all hunting down bugs and logic flaws.

Try using a Wiki to design your game. Very flexible and organized, you can easily see what parts need fleshing out and edit as needed. I'm surprised there isn't a site that hosts game design wikis.

This topic is closed to new replies.

Advertisement