Advertisement

A thesis on Game Design

Started by May 11, 2005 04:14 AM
7 comments, last by Dobbs 19 years, 9 months ago
I'm sorry, I've been away for some (long) time, and now I came here searching help, but I need some support from some expert in game design. I'm going to graduate in Informatic at University of Milan, here in Italy, and I'm going to propose a thesis on game design. These are the arguments I think a thesis on game design would speak about: INTRODUCTION - Some history from the very beginning of the videogames programming until today Part 1: Game concept - Game type | - Single player, Multiplayer and Massive multiplayer | - First and third person view | - Videogames and dedicated periferics - Storyline and Gameplay | - How important is storyline | - How important is gameplay | - Conclusions - Character design | - Player made Vs Premade | - Action freedom | - Incompatibilities - Player feedback: the importance of player opinions | - Beta testing | - Ssuperpalyers Part 2: Design document - What is a design document - General design: sell a game before making it | - Market laws | - Presentation - UML in game design - Staff menagement | - A group of artists or a group of automs? | - Plasm ideas, not minds Part 3 - Videogames today | - What do tou find on market ? | - What may you offer to the market ? - An example of design document CONCLUSIONS fine sorry if I made some english grammar error, but don't worry, I will write my thesis in italian, so there will be no itlian grammar errors. If anyone has an objection or a proposal, it will be welcome.
I think you skipped many of the possible genres, like TBS, RTS and different simulations, like sports, or the "tycoons", Civilization, flight... I am in fact not saying that they have been forgotten entirely, only that, even if they fit in your "single player, multiplayer, and massive" scheme, they still don't belong to your first person view or third person view. More like a God view...

If you are aiming at game design, then I think it would be good, as a starter to give your audience an insight of what actual games can be, with as many different exemples as possible...

Then, you are aiming at the peripherics, which will include, I believe Joysticks and paddles. Then you should link that with the genres of games which require the use of such items, such as Kill'em All, platforms or flight sims, or maybe consoles (game design does not limitate to PC does it? It can extend to consoles, and then to non-video games designing...)

Plus I notice that you are planning on talking about what a game is made of, with its different components, but you are not planning to talk about Game designing, merely about game designS...

Your parts about "storyline and gameplay", "Character design" and "player feedback" do not reflect, in my opinion, on the multiplicity of possible game genres, but are more focused on RPGs. If so, then say it in your premises, and focus on RPG design. If you are aiming for GAME design, then I would like to know how you will argue about the storyline for Electronic Arts' UEFA Champions' League 2005 or Gran turismo 4. They are simulations, and therefore lack this core component of Storyline, to concentrate on gameplay solely.


I think you should take your thesis as a path.
Propose as a first part your background about gaming, by presenting the different sectors in which games ocur, what kind of games have been in existence, then focus on video games, then focus further on games since, say, 2000. You then explore the PC and consoles evolution since that date, and explain what has been modified in regard to previously, and how it evolved in that time.

THEN you can provide an insight at the most successful genres of the last five years, namely FPS and MMORPG. Think about including a part on The Sims, which is a genre by itself, with its own copycats.

Then explain in your second part what designing is all about.
Your start with the ideas and/or the genres to which they apply, and draw a parallel with the market and the commands.
You then describe ALL the steps needed to design a game, like the brainstorming, the meetings with the different teams within a developer's studio (artists, writers, programmers, designers, producers) and then draw the line to testing, which will be your second part's last part. Alpha testing and Beta testing explanations, use, applications, modes, outcomes, etc... But even then, Beta testing is more in the stage of produciton than of game design.

Then you get to third part, and exemple of DESIGNING, and in the LAST part of your DESIGNING, you provide a Game design Document. But I think it would be better if you could provide the transcriptions of the memos that have been
sent back and forth between the diferent teams. Your main concern, in Game design, is about, well, game design. the produciton part should NOT appear anywhere as a standalone unit. If it does appear, then it should be as an explanation of what happens after the design has ended.

And if you are planning on having a thesis about game design, then make sure you know what game designing is about. I'm pretty sure you'll find more about writing, and brainstorming than about beta testing. If you are already beta testing, then designing is long over...

But a syou see fit...

I did my American Litterature Thesis on "American Comic Books evolution of narrativity; The X-Men: an exemple". And I know I got too average marks for my taste because I was too factual and not analytic enough. try to give more analysis than what you are currently thinking about..


[Edited by - Fournicolas on May 11, 2005 4:19:01 AM]
Yours faithfully, Nicolas FOURNIALS
Advertisement
thanks, I will seriously consider all of your words

about the title "Storyline and Gameplay" the original title was "Storyline versus Gameplay" with some example of topsellers games based only on the storyline or only on gameplay; your exhample of Electronic Arts' UEFA Champions' League 2005 is an exhample of "only gameplay", Soul reaver: Defiance has a poor gameplay, with that mobile camera that move when you jump making you fall down too frequelntly, but the storyline makes the difference.

The section "First and third person view" intended to inlcude all types of third person view, including isometric ang godlike view, the title doesn't explain my intenctions.

I have some time, so I can rewrite the "path" of my thesis in the way you have suggested, the fact is I'm writing it in italian, and I'll post here a traslation, the more lecteral possible, but sometimes I fail to explain some concept in english, more when I find hard to explain them in few italian words too.
Quote:
Original post by The Zeion
- Character design
| - Player made Vs Premade


What about the NPC characters? These can be pregenerated, or proceedurally generated.

Quote:

| - First and third person view

...

The section "First and third person view" intended to inlcude all types of third person view, including isometric ang godlike view, the title doesn't explain my intenctions.


How do puzzle/arcade games fit into this? There may not neccesarily be a character at all (i.e. pong, tetris, breakout), and this invalidates the descriptions used at the moment, as the view they use isn't really first or third person.

- Jason Astle-Adams

Quote:
Original post by Kazgoroth
How do puzzle/arcade games fit into this? There may not neccesarily be a character at all (i.e. pong, tetris, breakout), and this invalidates the descriptions used at the moment, as the view they use isn't really first or third person.


uhm... you are right, I may change the title of this section into "Poit of view" or something similar, to be more open to various aspect.

Obviously the section about character design is for games with characters, but a puzzle game doesn't necessary needs a storyline and a list of characters.

About npcs, I think storyline npcs are necessary premade; there are rpgs where you can build up the main character and a little party, but I think if you make a storyline based game you'll necessary need a lot of premade npcs. Baldur's gate, for example, let you make up a party only for multiplayer games, not for the story oriented single player campaign.
Quote:
Original post by The Zeion
About npcs, I think storyline npcs are necessary premade; there are rpgs where you can build up the main character and a little party, but I think if you make a storyline based game you'll necessary need a lot of premade npcs. Baldur's gate, for example, let you make up a party only for multiplayer games, not for the story oriented single player campaign.


A lot of games randomly (or proceeduraly) generate NPCs (both those that the player interacts with, as well as opponents). These are neither premade or created by the character, they're basically a premade 'template' being filled out with detail by the computer.

- Jason Astle-Adams

Advertisement
I'll give you two advices which helped me a lot when writing my thesis:

First, prior to writing anything, think hard "Is this general enough?" If not, try to enlarge your scope, and to find words and CONCEPTS that fit your global scheme.

Then, after writing anything say aloud "So what?" If you can't find any reason for having written what you wrote or can't use it to explain something THAT HAS BEEN EXPLICITELY STATED PREVIOUSLY, then it's probably not worth adding, it's fluff.

And since you are going for an analysis of game design, as I told you, try to see what remains of it when it boils down. What a game design is made of. What YOU have to do to design a game. Each step should be thoroughly searched, documented and explained. Think about it as reverse engineering on Bug report. You find a bug, try to make it happen again, write everything down, then report it as having happened. Game designing is in fact coming up with an image in your mind, describing it to someone else, then trying to make it happen, and ultimately discovering the bugs... But by the time you have reached step 3 "trying to make it happen", you have already left the game designing process and have entered the game produciton proces...

Keep it in mind, don't go too far!!
Yours faithfully, Nicolas FOURNIALS
I've (re)read gamasutra's articles about game design, and, in particular, Huntsman's "Primer for the Design Proces". Following some of yours advices I've come up with this reorganized idea:

INTRODUCTION
- Some history from the very beginning of the videogames programming until today (I like this par, a very WIDE view of the evolution of the design process)
Part 1: design
- What to do
| - Market requests (market analisis on what I can sell)
| - What there is and how it be done (my bad english may betray me, I mean, ehat products I can find and what is the quality level of he various aspect of these productions, so I may have an Idea of the quality my project have to reach)
| - What market needs and how I have to make it (simply how I have to read the results of market analisys)
| - Instruments I have at my disposal (what can I use to do the job)
- The Design Document
| - What a Design Document may comprehend (what kind of things I have to write in a design document, an introduciton to the argument)
| - Existent generes (rpg, fps, rta, arcade, directional scrolling etcetera)
| - Storyline (how much is storyline important)
| - Character design (player made vs premade, and all the implicities)
| - UML to describe (how to use uml to describe game sequences)
| - Graphic (I think this will need no explanation)
| - Sound (idem as aove)
part 2: production
- End of design, begin of production
| - Interaction with the group (how to deal with programmer, graphics, etc. to make them do what they have to do)
| - Waterfall model (waterfall design model, and other iterative design models)
| - Beta testing (how inmportant is the beta testing and how it has to be done)
| - Superpalyers (thoso players that suggests how a game, or a sequel, has to be done)
APPENDIX
- Today's situation
- What tomorrow may bring
- An example of a design document (based on Chris Taylor's design document template)

RINGRAZIAMENTI

fine

The title of the thesis may be "Videogames Production", and not "Game Design" but I think this would be a more complete work
"UML in game design" seems overly specific - I suspect it's not that common, definitely not universal.

You mention staff management, but not asset management? That's becoming a huge part of commercial game design/production.

Your topic as a whole seems unfocused, too broad. What is your central thesis? What you've posted here just looks like a description of the game design/production process.

This topic is closed to new replies.

Advertisement