The eminently sensible way to design a game is to pick one interesting or novel mechanic and really develop that, and then add all the supporting elements using well-known and understood game mechanics (racing, shooting, doors, what have you).
So many of our bugs and problems in the game these days come from design elements, like script, not code bugs.
In code, we have countless mechanisms to make sure the game is working right - we have a compiler, and we ensure the code has zero errors, and zero warnings; we make heavy use of self-consistency checks, like asserts and C++ classes that automatically ensure correctness with templates and compile-time checks; we do code reviews to look for bugs, we run regression tests, etc. Furthermore, we are generally well versed (here at OW anyway) in the issues of robustness, brittle control structures, etc. We know that making changes late in the process almost always leads to bugs, we know about disentanglement and encapsulation, etc. etc.
These days more and more of the game is design-driven, either through scripting languages or data-driven controls and markup. Presumably the code is written so that those things can't actually crash the game, but they certainly can cause bugs, and they are subject to all the same sorts of logic problems and flaws. Yet how many designers follow the careful practices we do? How many are even aware of the issues? Our designers usually check in content that generates tons of errors, not to even speak of warnings or other issues!
With the design tools you also suffer a lack of documentation, easy browsing, debugger, profiler, etc.
Seems to me this is a major problem in production practices, and it's only getting worse. Already we're seeing our worst logic bugs come out of design, and they're incredibly hard to track down because they have no coding style standard, no documentation, etc. etc.
Whoah, yes, lots of companies are irresponsible about tools, but that's not really the point. The point is that with power comes responsibility, and so far I've seen the desire for power, but not the desire for discipline.
It's not possible to create a toolset where the designers have full power to control the behavior of the game, and yet somehow cannot introduce logical errors or algorithmic bugs. Yes, we could make it easier to debug & find the problems once they're made, but that's only part of it. Any coder knows there's a big difference between clean, robust code and code that just barely works and is spaghetti. When we hire coders, we don't just hire people who know how to use the C syntax, we hire people who understand "defensive coding", robustness, protecting against bad clients, etc.
There's sort of a spectrum of design power. At one end, you don't expose any algorithmic control, designers can only place elements that are specified in code & maybe tweak some values. This basically puts all the bugs and behavior control in code, but design can still create "logical bugs". At the next level, you expose some sort of hard-coded events and triggers, things like that. Now, design can make algorithmic bugs, but they're pretty easy to diagnose. At the next level, you expose a scripting language which can't allocate memory or ever crash, but certainly can have algorithmic and logical bugs and can easily "break the game" in the sense that correct play is impossible. At the most extreme level, you expose the programming language, and the designers are the coders. [
This is a fundamental slider, you can make the tools better any point on the slider, but that doesn't change the fact that there's a slider.
I find that most designers want more and more power, but don't understand that as you go to the right (more low-level, more power), you also increase the chance that you make bugs, and you need more discipline, you need to be more careful, you need to be more like a programmer, which is not fun. At the far left of the slider, life is grand, designers can muck around all they want, and if the game runs, it basically runs fine. At the far right, you get scenarios where they have some delicate non-robust complicated scripting and trigger system that works only if you play it just right, etc..
Simple mistakes like scripts that just don't work because of typos we report. We have one major problem here in that the designers just ignore the errors if their levels still seems to play right. The other problem is that the real bugs I'm talking about aren't that simple. They're more like "this script volume toggles this door open/closed, but depending on how you played up to that point, the door may or may not be already open, so the state of the game is not determined and play through may be broken". It's not so much about the tools and as about the process, and just thinking about robustness.
We currently have designers writing scripts. We'd be better off if we had some junior programmers doing it for them. Scripts are only the largest part of the problem, though. I suppose these junior coderz could wrangle all the script triggers and such and keep an eye on all of the logic the designers are setting up. Basically what you're doing is having one creative guy and one careful guy work on each level. That's not a bad solution, but it is very expensive in terms of employee costs and management. Even a junior guy that you pay $30k or $40k costs the company almost $100k
I think part of the problem is that the ideas of solid coding are so outside the brain-space of designers, they don't even see the need for it. If you try to talk to most designers about this problem they say "uh, but our scripting language detects typos, so we don't need that right?". Granted, these are advanced concepts, most junior programmers totally screw it up, hell, look at the Quake code and you'll see a mess of non-robust coding style. It takes a long time for people to realize the importance of solid practices and methodology. How many programmers have read "Writing Solid Code" and "Large Scale Software..." etc. , much less designers !?
When will producers and game designers realize that "shipping quickly" is one of the features that will make a game successful, and do a better job of it? If Doom 3 and Half Life 2 (and Duke Nukem Forver) had come out when originally planned, all of them would have rocked the industry. Now, Doom 3 will still do ok, but its technology is actually old hat, and there will be many Doom 3 look-alikes coming out at the same time. I'm not saying they should have been released in the state they were in, I'm saying that the scheduling and planning from the beginning should have been more focused on quickly shipping rather than adding in a bunch of "wouldn't it be cool if...". Doom 3 could have shipped without physics or networking and blown people away, then you add them in for the Doom 3 : Unleashed or whatever and everyone's even happier, and you've sold two games instead of one.
It's basically bounty hunters in space, with a story mixed into episodic adventures. It occurs to me that this model is ideal for games, and the Cowboy Bebop universe would be an awesome license.
Basically you make an episodic game. The first purchase is $25 bucks or so, it's a little longer, introduces the characters and basic mechanics, you hunt a few bounties. Now the levels come out as episodic content. Each one is $5-10 and delivers another bounty mission or two. You also get new weapons, ship upgrades, get to go to new parts of the universe, even get new characters added to your crew, and you find out more about the over-arching story.
The interesting bit game-mechanic wise is to give you controls and aids that actually let you do the things that Spike does in the show, basically being a super-badass beyond belief, dodging lasers and such. I'm not quite sure how this would be done, but you do something like give them points which allow them to execute amazing moves by spending a point; then you reward with a bigger bounty for fewer points used at the end of the mission.
More cartoon-based games : Inuyasha has this character with a "Wind Tunnel". It's a hole in his palm that he got as a curse. He can use it to suck enemies in. The cool bit is that the Wind Tunnel is not only a weapon, but a curse - if you use it too much, it can get injured, and it can grow out of control on your body. The bigger it gets, the more powerful, but if it gets too big, it will suck you in.
This is kind of an old idea (see my post 9-29-01, #5) that you have a weapon that's sort of out of control, but it's still a very cool mechanic that's never been done (well).
Idea : drop the player right into the game. No intro movie, no tutorial level. Bam, you put it in, you're controlling your avatar. (Ok, maybe a tiny bit of intro to set the stage a tiny bit, but not much). The initial controls are really obvious, move left stick, camera right stick, jump on X, shoot on Square. Let the player run around a tiny bit, now give him some enemies. If he dies, instantly restart him and let him try again. This first level is very short, but already fun because your enemies and character are interesting. NOW you show a bit of an intro movie. It should still be a short one. Nobody wants to know a lot of backstory before they get into the game. The longer you play, the more connected you become to the lead character, and the more willing you are to learn backstory. When you first put a new game in the console, you want to *play now*, not sit around and watch movies.
Level structure. So many designers don't understand the role of levels in games. They want to do away with levels, to have seamless transitions, to let the player go anywhere in the game. This is bone- headed. Levels are great for the developer and the player. Each level should have a distinct theme, so that just at a glance you know what level you're in. This theme should be carried over in the music, the art, the enemies, everything. Levels should be compact play packets. You sit down at night and play for an hour or so, you beat the level; now save and quit for the day. A Level is like a Chapter in a book, it gives you a sense of resolution, a good stopping point. There's a reason books have chapters!! A well designed level has a setup "why am I here?", a progression of play, introduction of a new mechanic, ramping the new and old mechanics, and then a satisfying resolution "ah, I'm done". Closing off the level also lets the player know that he doesn't have to do anything more in that area.
Game design manifesto.
Game design rant.
Some basic points about game design :
1. It's not the content. You're not making a movie - if you want to make a movie, go make a movie. A movie has about 90 minutes of content, with powerful stories or very cool visuals, etc, and a huge host of people devoted entirely to making those 90 minutes pleasant for the viewer. In your game, you have much less money and talent devoted to content, plus you have all the challenges of the medium (technology, etc.) which make it harder to make content. If you're lucky, maybe you can make 30 minutes worth of engaging content (you might string it out painfully over several hours, but it's still only 30 minutes worth). Now, typical modern games should have at least 30 hours of gameplay, so those 30 minutes worth of content are not the meat of the game. Sure, that little bit of content might really set the mood of the game and get the player involved, but that's a level of polish, not what makes the game experience fun. The meat of the game is in the interactive mechanics.
2. If you don't have fun playing it, then probably no one will. As with most rules, there are some exceptions to this, but in general you should avoid making a game that "game players will like, even though I don't".
3. Listen to the people on the floor. In many game companies, the leads and decision makers don't actually play games any more, and they may not even play the game they're making very much. On the other hand, most of the peons on the floor are in the business because they love games, and they're playing the game they're making every day. These people have very valuable opinions that should be listened to, but more often than not are ignored.
4. What will the moment-to-moment experience actually be like. This is one of my key principles, and I don't see it used much; eg. don't tell me about the cool mechanics, tell me what I am actually doing with the game from moment to moment. Cool enemies to shoot don't make a great game if you are actually spending all your time trying to find them, or sitting around waiting to heal, etc.
5. A learned skill. A good game is often a little skill you can learn. What I mean by this is that the act of playing the game itself is a skill you develop as you play. The difficulty of the game should ramp up to match this developing skill. The result is that the last level of the game should be very very difficult to someone who hasn't just played through the rest of the game, but should be moderately challenging to someone who has just played through the whole game over the last few days, and is warm in the skill of the game.
6. Internal consistency - a logical physical micro-universe. This is very important; the game need not obey the real rules of the world, but it should have its own internal logic that's consistent. This lets the player figure out the patterns and use them, which makes them feel like they're getting good at the game. eg. guys with red hats always throw grenades, so if I see one, I won't get too close to him. Ideally, the pieces of your game can work together in this internal logic to compound. This is the "Miyamoto-style" ideal
7. Game as toy. Making a game like a toy is a good way to make a fun game. A "toy" game is something you can sit down with and just sort of poke at, try different things, and be amused by the results. Some entire games are toys (eg. the Sims), and many games have small toy aspects; eg. even being able to shoot props in shooters is a sort of toy aspect; it's pointless, you just fiddle with it and it gives you some amusing and occasionally unexpected response.
8. The principle of "not like life". Great games are usually like real life in some way, but better. Like a game might give you the thrill of driving a fast car without the worries of crashing and breaking your neck. The key point here is that too much realism spoils this; people play games to *escape* the real world; if they want to be in the real world, they're not playing games. So, things like character that have to go to the bathroom or eat to stay alive are generally bad ideas - games should not be frustrating. In the real world you have to carefully consider major decisions, you have to go through unpleasant times in order to ensure a pleasant future, etc. - these worries should be absent from games.
9. Don't patronize the player. Game players are smart. They know your tricks - they know when a branch in the play is a real branch and when it's just the exact same thing no matter which option they choose. Don't even bother trying to fool them, it's insulting.
10. The principle of player control. The player should be able to control their experience as much as possible. This can be implemented in various ways - make story elements interactive instead of non-interactive, so the player can ignore it if he wants, make the play more non-linear so the player can try different paths, make mini-games that the player can spend time with when he gets tired of the primary path, let the player choose his upgrades, whatever.
11. The "good game" principle. The best feeling when you play sports is the feeling of winning after a "good game", where you congratulate your opponent, shake hands are really admire how each other played. Maybe you had to dive for some balls and skinned your knee - you really played great, you won, and you deserved it; if you let up the pressure for a minute, he would have won. In real life, it's very hard to arrange this scenario - you have to find someone with very similar skill level. This is something good video games should do - you should feel like you have fought a skillful and clever opponent, and that through your prowess, you barely won (maybe after a few tries).
12. The principle of player feelings. One good way to design games is to pick specific ways to try to make the player feel at various times. This feeling should primarily be conveyed through the player's own actions. Rather than starting from puzzles, start from, "I want to make the player feel scared shitless here", or "I want to make the player feel like a bad mother-fucker mowing enemies down here", and then make that happen with in-game play. One of the basics is the "I'm a bad-ass" or "my character is a bad-ass"
13. Let me get straight to the fun. When someone pops a game in the box, they want to play it. They don't want the backstory, they don't want to create a character, etc. They want to play. All that other stuff becomes interesting only *after* you have become committed to the game enough to care, to be emotionally attached. The best model for games is the 007-style bit of action before the credits. Put the player in, show them what the game is like; NOW you get to see the opening movie, see some story, and make the stats for your RPG-like game. This also lets you know something about the game mechanics before you commit to a major choice like character stats.
14. Design the game to fit the schedule. If you have to make a license-game in 1 year - keep it simple! If you have time, then get more ambitious. Do not try to write a new engine and do an ambitious game at the same time.
15. Don't be ambitious in game design. Start with a genre and play style that works. This is such as huge advantage, it can't be made up for. When you have a classic starting point, you can borrow game design elements, you can see what worked and what didn't, you can improve on many other peoples' work. If you want to do some new elements (and you should), you should make sure they are actually helping and interesting.
16. Ask yourself "will this make it in the final game". Trying new things is all very well and good, but most developers waste a lot of time trying things that don't work.
17. No game should take more than 2 years to develop. If it does, you have severely screwed up. You've done things that aren't necessary, you've dawdled, you haven't licensed enough, you've explored paths that were dead ends that you should have anticipated, you should have samed some of the features for the sequel, etc..
18. "Next game". If it's not necessary, do not do it. Save it for the sequel (aka don't ever do it).
19. Rhythm. Almost all good games are about rhythm. Repetetive timing puzzles do it, shooting and reloading can do, waves of enemies do it; of course Rez does it, but all the classic shooters have rhythm - Space Invaders, Galaga, etc. Parapa and such beat-matching games have obvious rhythm, but any good platformer gets you into a rhythm and a flow when you're playing well (square-square, circle-square, circle, circle, square).
20. Use your freedom. It's a game, it's VR - why is that enemy human? Does it make the game better, or would it be better if he was a slug with tentacles? Why are you going into a warehouse - why not a factory (make of glass, floating in a river) that extracts mucus from sea slugs.
21. Synergy. The code and the design must be made for each other. If they aren't, you can *feel* it.
22. One good way to make a game is to pick a single very cool idea and make your game around it. Some examples are "your character is invulnerable but can do no damage directly, you can only get enemies to hurt themselves and each other", or "you can transform into two modes with very different attributes; the gameplay is based on trading between them". Whatever, take that *one* idea and then embellish and fill in the gaps.
23. Play to your strength. Make a list of what your company is good at, and make sure the game is taking advanatage of that. Similarly, stay away from your weaknesses. Even if you don't have clear strong and weak areas, it can help to focus by choosing the areas you're really going to "nail".
24. Anything can be fun. Don't think an idea is great because "if we add enough cool sounds and animations and voice tracks, it'll have a lot of humor and provide a lot of satisfaction". That's true of anything. In general, the result is good because of the execution, not because of the idea. Don't stick to ideas because you're imagining them with brilliant execution.
25. Leave time for adds. You need to add things as you go along, as people get excited about various aspects of the game. Plan on this from the beginning. Do not try to over-flesh-out the game initially - hit the basics, and and know that the fringe will be filled in with later adds.
26. Know what you're making. Be able to describe the game in one sentence, eg. "The game is an RPG that using first-person-shooter mechanics instead of classic RPG combat". Make sure that one sentence is accurate; if it's not, your game theme is too complex.
Programmer-driven game development is still the best way to make video games. What I mean is that when you decide to make a new game, the designers and programmers sit down and say "what kind of technology is at the sweet spot for current hardware", now "how do we make a game that takes advantage of that". Of course, if you want to make a sequel or a derivative game, you don't need to do that, but if you want to push the limits, you do. At the moment, I would tell designers something like this :
Stencil shadows are obviously at the sweet spot; they lead to good corridor shooters, and to excellent stealth play. Thief 3 and Doom 3 look to be games that take advantage of this. Another technology that's of age is massive LOD. The ideal vehicle for this is something like a flight sim, or some other game where you move over lots of terrain at multiple scales; the LOD technology is now well beyond what the average gamer or coder imagines, so this could really blow people away and open up new possibilities in game design (eg. playing micro and macro scale games at the same time). Toon shaded and NPR effects are also mature. Rigid and soft body physics and render-post-processing are other possibilities.
When games try to push the limits without this close cooperation of the programmers, you wind up treading water the whole time. You choose paths that don't work well on the hardware, eg. needing lots of memory on the PS2, etc. In fact, it seems the best games come from core mechanics that are created by the programmers. Designers are good at taking those things and running with them, doing things the programmers never imagined, but for games that are pushing the limits of the machines, programmers are better at defining the base play and mechanics, IMHO. Obviously Id and John Carmack are the clearest examples of this.
This is all true in terms of the art as well. Many game companies think the programmers should not be involved in the art, but that's horribly wrong. The programmers usually have an excellent knowledge of what makes 3d art look good and bad; we may not be the best at character design, color choice, etc. - and we wouldn't make those calls, but we know things like "those small polys will alias and fry", or "that alpha is going to cause glitches in fog and lighting", etc. And, the art is strongly technology driven. With a normal-mapped pipeline, you want to really take advantage of that; I can tell you how to do it, most artists can't. If you have soft body dynamics or cloth simulation, you want to make characters that take advantage of it, etc. If you have a generic motion system, you want to make characters that aren't bipeds, etc. Again, the best characters and art come from high- level direction from programmers.
Addendum : Chris Killpack has wisely reminded me that a lot of the classic "top" game designers were programmers. Programmers not only understand the technology better, they tend to be more logical, which is inherently needed for good game design. Funny that this is true and obvious, and yet there is still a rift enforced between code and design.
Genetic game idea : (I think Marc Hernandez actually had this idea, but I've been thinking about it a lot lately). The game is played on a 2d grid. The core idea is that you're playing a sort if "Core Wars" by genetically evolving your warriors, not with direct control. There are two human players. Each side starts with a "Spawner" from which new guys are continuously slowly being created, and a goal. Each guy that comes out of the spawner has a new little algorithm for controlling his AI. He then runs that AI with no player control, and you win if any of your guys can get to a goal. The AI is a simple looping code snippet with things like "move one square towards goal; if there's an obstacle, move one random square", etc. The way you play is by selecting which of your current running AI guys you want to use as your genome base. You use the mouse to select or deselect your current favorites for the gene pool. When a new guy is spawned, his code is formed from genetic splicing of the current selected genome, and a bit of random mutation. That's all there is to it! You can control the code that your guys run by dynamically picking the guys that you think are behaving the best. There are lots of wrinkles that could be added to make "levels" ; for example, you could make more complicated goals, like "capture the flag", or introduce new moves for specific levels, like a checkers-style jump or powerups to gather, etc. The key to making it all work would be to express the mini-AI language in a way that is sensical to splice but also has enough power to lead to interesting behaviors.
Misc. game ideas for Oddworld that won't be in the next game :
I like EverQuest. I won't go into a whole thing about the game here, but suffice to say that it is much maligned, and indeed it does have a lot of problems, and of course now it's quite old (though from what I can see, Dark Age of Camelot has all the same pros and cons, it's just newer). Anyway, I think the good things about EverQuest are very good, and we game developers could learn from them (there's a reason why quite a few people are still paying $10/month). Of course, the game actually stinks to play, and one of the real attractions of the game is the moment of looking forward to playing, the anticipation of how great it will be but never really is.
The really great thing about the game is the feeling of freedom. The game is completely undirected; you start the game, you can go anywhere, and there's no order of operations. Now, there is an implicit bit of ordering based on level and abilities. What that means is, you may be able to go to Permafrost at level 1, but it'll be mighty dangerous, you'll probably die, and you certainly won't be able to accomplish anything productive. This form of direction is very cool. Contrast to most single player games - Permafrost would be locked by a door that you couldn't go through until you finished some other part of the game. This open-ness really gives you the feeling that "all I have to do is get stronger and I'll be able to check out Permafrost". You can look at the maps that come with the game and on the internet and go "Hey, the Warrens, that looks cool, I want to check that out - but I'm not high enough level, I have to improve myself and then head over there". This is the key to the fun of the game, IMHO, and it's a very good thing.
I think a single player game could be built on these principles, and it could be very cool. One of the keys is a teaser that shows you the world map, that there are interesting things out there to see, and the ability to go and have a glimpse at them.
Today is a day for writing up game ideas.
1. Kafka. I've always wanted to do this; a game based on The Castle and The Trial, a game about the bizarre surreal struggle of living in beaurocracy, of people who are living by regulations that are just so ridiculous and bizarre that you can't believe they're serious. It should be confusing, confounding, bizarre, with a bit of light hearted humour, and dark gritty visuals.
2. Sim Pimp. This idea came up as a joke, but it's kind of fun. You're a pimp; you need to establish turf and seduce the whores. You need to rent rooms at the hotel, fight off other pimps, bribe or evade the cops, upgrade your den, etc.
3. Interesting kinds of horror. All game horror is the "jump out at you" horror. I want to explore new things, like vague unease. For example, something really wrong is happening, but no one acts like it's weird (eg. the baby in eraserhead). Similarly, everyone knows it's wrong but pretends that it's not. Another nice type of horror is the fear of working around heavy slamming pistons, like the machines that stamp out metal patterns. Another nice horror is the fear of being in a submarine or a space ship or something and hearing it cracking, or not being able to move while someone is wandering around outside trying to poke holes in the hull. A nice horror example is talking to HAL in 2001; you know he can kill you if he wants to, and he's kind of insane, but you just have to talk to him. This is a form of talking down the terrorist with his finger on a bomb strapped to his chest.
4. A sick cyborg game. Body parts are your power-ups. When you kill a demon, you can rip off your own hand and graft his on as a replacements. Think of "Tetsuo : Iron Man"; you find a shaft of steel and just cram it into your leg. You find magots and put them in your eyes, you cram a megaphone into the side of your skull to enhance your hearing, etc.
5. I wrote about this long ago : this demon takes up residence in your arm; think of Tetsuo or Princess Mononoke. It makes your arm strong (this is your power) but also evil. As you go through the game, it grows, taking over more and more of you, and becoming more powerful but also harder to control. The more you use it, the more it takes you over, so you must be sparing. It stabs women and tears open your victims, it's violent and cruel, but you must use it to accomplish your quest.
6. Split-personality game. I told Thatcher about this but I don't think I wrote it down. It's inspired by Fight Club and Memento and Lost Highway. You have a dark other side which powerful but out of control; it scares you, and at first you don't realize that it's even you (it manifests itself as another person). You must use this side of yourself to avenge something (your wife was killed, which put you into this state in the first place, or something like that but hopefully less trite), so you must let it loose once in a while, but if you let it loose too long it'll go crazy. You play like a two-player cooperative type game, controlling both of the personalities as separate people, but of course if one gets shot they both die, etc.
7. The original "Galaxy" game idea. I released the mesh-management Galaxy code as a demo, but it was originally a game I was working on. The idea of the game was to capture some of that space trading fun of like a Trade Wars game, but with a really nice space flying interface. I didn't want anything like realistic space physics, which are no fun, but instead I just wanted ships that were incredibly fast that just gave you an awesome rush to fly around. Part of that was that the flying speeds would just be incredibly fast; you'd rip around the whole galaxy, and have instant fine control over your speed. You'd also have a hyper- speed jump which would cause you to rocket forward at ludicrous speeds briefly (but don't use it when you could run into something!). You'd also have seamless space to planet transitions. At your awesome speeds you could orbit the earth in a minute, racing around and seeing the sunrise or sunset over and over (seeing sunrise from various atmosphere levels would be an awesome effect). You could whip around the sun (there would be some semi-realistic gravity effects) and sling-shot. As you got into orbit, the controls would gradually morph into semi-2d flight sim controls with a local up defined by gravity, while in deep space you would have full 3d motion. Because of your blazing speeds it would be hard for you to interact with stationary things on planets, so you would do it by strafing and dropping collection droids which would float down to the surface and gather ore, etc. and then fire their booty back into orbit which you would fly through to pick up. So, the play would be like "whoosh" over a refinery, you see it and do a big loop to get back, and "blam blam blam blam" you fire a salvo of droids, then "whoosh whoosh" you loop around waiting for them to finish collecting and then you fly back through and "blung blung blung" you collect them in orbit. The whole reason for this insane speed is that you're a Pirate, and the federation/empire/whatever are always hunting you down; they've got orbitting patrol stations, etc.
One of the magics of games is to tap into the pure fun of our child-hoods. When you were a child, you didn't think about the consequences of your actions - and that is a blast. It's so liberating to just run around in the grass and not think of grass stains, to eat ice cream and not think of the calories, to jump in the ocean and not consider the cold. This is one way that games can be fun - by just letting you do things, experiment, and not punish you. Obviously, a lot of games aren't like this, and occassionaly it's intentional (such as the micro-manager RTS games which appeal only to the anal) but usually it's just a mistake; for example, and platformer should not have long-term punishments for experiments you try early on.
Game idea :
Like "fight club" or "devil inside" or "memento". You have a wicked alter ego, a split personality. You run around together all the time; you're actually one person, but you're represented as two. He shoots people, he's crazy, you're a normal guy. Something happened to you that made him that you can't remember; you've got a bloody bump on your head and a broken shin to prove that something happened; your wife was killed, but by whom? The police have stopped investigating, they think the killer is dead, but you know he didn't do it. So, you need to use your alter ego to help you find the killer, because he can do the crazy crap like busting into a biker bar with guns blazing that you don't have the balls for. So, you're terrified of him, but you must stick with him and occassionally become him (and occasionally stop him when he becomes too murderous and mad). You can choose to play either guy at any time.
Charles Bloom / cb at my domain
Back to the Index
The free web counter says you are visitor number