Unfocused Dude

Writing about things that i give a damn about

Posts Tagged ‘Game Design

An older piece touching on level design

leave a comment »

I wrote this more than a year back but never had the chance to post it somewhere. Here it is in unedited form – i still stand by these lines…

So, the guys at programming offered you all the items you need to start creating your level(s), like the enemies, weapons, bosses, features, and most important at this stage, the editor. The artists provided you with tons of textures, character animations, doodads and cutscene-specific assets, etc. The Lead Level Designer (and/or the Lead Game Designer) gives you the green light and provides you with a rough draft on the general ideas you need to keep mind of so that your completed level fits into the story and the general difficulty curve of the game (included, but not limited to unlocks, story elements, dialogue, new enemies, npcs, weapons, new features, limitations etc.)

This is basically level design – you take a lot of separate elements from code, art, sound, design, and put them together in a level (hopefully) creating an unique playing experience and look.

That’s the technical part anyway, but how do you succeed at Level Design? How do you know what’s right and what’s wrong in doing it?

I’d like to make a reference to what Andrew Loomis calls “Intelligent perception”, a term I’ve first read about in one of his “drawing lessons” book. Intelligent perception tells us from the start if a drawing, or game for that matter, is good or bad, where does it lack, where could it be improved. The funny thing is that this perception thingie rarely helps you put into words what you “feel” about a drawing, game, movie, or book. You just know it. When a character has a foreshortened hand that you feel is wrong, it usually the case. If a 3d model has strange texture and makes the entire model look awkward, there’s a problem. If you’re looking at a game, you can tell either you like it or not, but you can’t really put your finger on the flaws or the good points except for the most obvious ones; you just know.

Due to the fact that there is no “unified game theory” to give us all the good and bad things about game and level design, we have nothing but some general basic rules which we can use to start building a level (we’re talking about single player levels, action/platformer/rpg games for the moment).

1. A level needs to be balanced – not too easy, not to hard, just about right. You can achieve that by testing and refining, then testing and refining some more (by you, but additional opinions are always welcome, because people tend to be subjective about their creation and not recognize even basic flaws in the level). And even when you’re sure, give it another test run and see if there’s anything standing out as bad and smooth it out.

2. A level needs a game play flow – a good rule of thumb is that you need to have the player relax between tense action moments and let him just browse around or explore. A level where there’s a continuous fight from start to finish with little or no chance to rest and do something else except fighting the enemies is very stressful for the player. Use a pattern like this: action/exploring/action/cutscenes/action/dialogue/action…. Etc. Keep different action moments separated by “other” things the player might do and has to do. Travel between fights, do a puzzle, see a cutscene, look for treasure, make his jaw drop when looking at the environment as he’s moving towards the next fight, etc. (it all depends to the features and mechanics of that particular game).

3. A game level is a living world – you need to make use of ALL your assets to make the game world believable. This ranges to making effective use of doodads (ex: put signs at crossroads, birds flying here and there, animals moving about, leaves rustling in the wind, floatsam on the water) to using NPC and/or enemies as part of the world, not just the ones that give you quests/try to kill you. For example: two NPCs are talking; an enemy that charges you but then a NPC helps you by toppling a boulder over him; coming from a corridor into a room where an enemy walks in your field of vision but not noticing you, etc. Having the feeling that this IS a believable world, where enemies/NPCs behave in various ways and react to you, and there are a lot of things happening like weather, environment animations and such, ultimately creates a better (immersive) experience for the player.

4. Give the player some time to integrate new features (controls, abilities, enemies) before introducing another new one – it’s rarely a good idea to unlock several abilities or new enemies in a short span of time. It’s much better to give the player the time to integrate this new ability or enemy into his “system” before adding a new one and confusing him further. Why is that? We (humans) need time to learn how to properly use a new ability and dealing with a new sort of challenge, and we can do that by having to deal with these new features a few times, thus making sure we know how to use them before tackling a new challenge.

5. Play a lot of games and try to analyse their levels from a technical point of view, by asking yourself questions like: “why was that level/campaign so successful?”, “was it really necessary to use those annoying “push button” puzzles between fights?”, “how did they manage to create intense and involving encounters?”, “were the mini-boss and boss enemies correctly placed along the campaign/story?”, “were those optional quests any good in terms of value or time?” and things like that. Try to realize what worked and how did they manage. A good experience would be for example to take a Campaign from Warcraft 3 or Starcraft and play it from start to finish, keeping notes about it. The questions I gave you are a good starting point, but there are much more questions you need to answer to, and those are different for each designer.

6. Level design – the more you do it, the better you get at it. It really helps playing around with the editor and doing whatever crosses your mind. Start small, do a simple level to test the editor – make a single player mission where you need to defeat several enemies or destroy an enemy building or some such. Next, give your side the possibility to build structures and take the game to a new objective, like destroy the enemy base, or defend your own base from multiple avenues of attack. Each level you do will teach you something, both technical (editor related) and design-wise. Later, time attacks, special objectives, side quests, there are plenty of options down the road.

7. Read any article or book on general game design and level design. There are always useful tips in each and every article about design. But, try to integrate what you learn in your levels, and see how those advices and tips work for you and your game/level.

That sums it up for now. Even if it touches on general Game Design, and not all advice are related to RTS maps Level Design, I hope these things can help anyone trying his/her hand at Level Design. I don’t really like how the entire post came out in terms of words, sentences, general structure but perhaps later I’ll review and rewrite some of the parts I don’t like that much.

Written by unfocuseddude

25/04/2011 at 9:24 PM

Posted in General

Tagged with ,

On Game Design and scripting languages

leave a comment »

Recently, i’ve heard a rumour that some games that I have a chance to work in the near future on will be  using Squirrel and Lua. I was like…

I’ve been working for years with tools and scripting _methods_ very specific to the game that was being done and frankly it SUCKS to switch gears between projects, more or less to forget about the tools you were using and start learning a new way of scripting your missions or whatever.

What’s up with that, mr. Programmer and mr. Producer, but especially mr. Marketing Representative, since you get to decide what do you think it’s best for the game, because you only take into account the deadline, the team budget, projected profits and all that jazz?

“Oh no, we can’t afford R&D on the design tools, we’ll just grab an old editor and graft it onto the new project”.

FAIL!

Since there’s very little chance I’ll be working with UED3/UDK and Kismet, let’s have a quick look at both scripting languages:

LUA:

– lightweight programming language

-easy to integrate in C programs

-objects

-used in some games, most famous being Dawn of War I & II, Warhammer Online, World of Warcraft, HAWX, Empire: Total War, Homeworld 2, etc.

Here’s an example of code:

function factorial(n)
  if n == 1 or n == 0 then
    return 1
  else
    return n * factorial(n - 1)
  end
end

Now a recursive function isn’t the best example of what you would use in a mission script, both as usability and performance, but there’re two important improvements over the scripting methods i’ve been used to working with: functions (that return values no less!) and conditional statements. This enables a much more complex script in which you gain code abstraction (using functions instead of copy/paste some code every time you have to use that piece of code in different places) and checking on complex game states. For example:

if getPlayerHP() > 0 and spawnedEnemies < 5 then spawnAdditionalEnemies()

or something like (if you want to kill all enemies in case you poison the entire level and enemies have to die:

for enemy in getLiveEnemies() do
    wait(random(300)+100)
    kill(enemy)
    playRandomSound(DIE, die_1, die_6)
end

Okay, programmers still have to let you have global variables that contain useful data like player’s health, number of enemies and useful functions like wait(milliseconds), random number generator and all that, but i like this a lot more than doing it with a lot of triggers activating and deactivating between them.

Did I mention coding-style scripting is much easier to debug ? Let’s say you write your level script in a .script file that’s basically a .cpp file including all the lua and the custom scripting functions that you need. You can check if scripts run or find bugs by simply using breakpoints in your IDE.

Squirrel:

– lightweight language

– used in game development – Final Fantasy Crystal Chronicles: My Life as a King and Code::Blocks (google it)

-objects, inheritance, etc.

– C-Style syntax

The last bit seems to me the major difference between Lua and Squirrel, although someone in the know will laugh at this- and with good reason; i’ve just glanced at the two and barely scratched the surface. But let’s look at the same factorial function for some syntax differences:

function factorial(x)
 {
   if (x == 0) {
     return 1;
   }
   else {
     return x * factorial(x-1);
   }
 }

So, no more do/end but curly brackets ({, }) to enclose code blocks, a semicolon at the end of statements,  using == instead of = when testing a logical condition. I guess this could be good for programmers because the more familiar syntax and thus easier/quicker to debug faulty scripts.

All in all, i’d work with either or both, since they’re very much alike. The MAIN problem is, as a fellow Game Designer put it a few days ago when talking about scripting languages, is:

You can have the greatest scripting language in the world – if the programmers don’t dump everything you need as custom functions and variables for the designer to manipulate the game world using the script, you still got nothing”.

You can check the wiki entries for both here: Lua and Squirrel.

Oh, one more thing – i might give Lua a try sooner or later in a small game demo i’m trying to build. Nothing fancy, more like a tech demo of Lua in action 🙂 Stay tuned!

-UD

Written by unfocuseddude

11/04/2010 at 2:11 PM

Here’s a Thought…

leave a comment »

If you could compare musicians and game developers then…

1. Programmers would be pop-stars: they’re very good at what they do, but have very little creative input in the end result and usually let other people decide for them 🙂 Still, they sell millions.

I’m having trouble deciding who’s who – the similarities are … uncanny!

2. Artists would be the rock-stars. They behave and act and work very out of the ordinary and have their quirks, but their creative input is much bigger than a programmer’s and they work their ass off too.

Not sure who the first guys are 😛 but all the other three are 2d artists, the first is Marko Djurdjevic (google him), and the other two are guys i’ve used to work with. The second one is actually a concept artist at Crytek. I KNOW SOME FAMOUS PEOPLE, YEAH!!!1 *cough*

3. Designers would be the blues and jazz singers, always trying to reinvent the music and fight with the record companies that want to beat the trodden path.

Again, I have no idea about the first guys, but then comes Rob Pardo, CliffyB, (second row) Richard Garriott, and in the last picture, a game designer i know and have worked with. Just ignore the dude with the Matrix outfit, okay? He’s a reporter or something :>

Why blues? Because you take the old standard 12-bar blues and add something that makes your song fresh and innovative (read: take an established game genre and do your clone, but strive to create new twists and fresh(er) gameplay so people will still apreciate it).

Why jazz? Well, this happens so seldom but it happens. Some designers grab a few dissociated ideas, mix them together and then a fresh new gameplay idea pops out, sometimes creating a new genre. This is somewhat analogous to the Jazz musicians that, although constrained by certain harmony and phrasing rules in their music, they’re much less constrained by pop and rock rules and are able to come up with something complex and beautiful at the same time.

Yeah, as in the music industry, very often the game designer gets too little credit.

How are things in your local game development work environment?

Written by unfocuseddude

06/04/2010 at 8:12 AM