I’m disappointed to see developers publicizing that their upcoming AAA titles are exclusive to one particular console over another as though it were a perk for gamers.
Would PS3 owners really care if God of War III were available on the 360? Would the Xbox 360 crowd care if Gears of War 2 could also be played on PS3? Certainly, it would be odd to see a Sony title, such as GoW, available to Xbox players but, frankly, Sony would make more money by selling their game to other console owners.
I suppose it’s obvious enough that this is simply a matter of publishers baiting hooks with AAA titles to lure gamers over to one console over another but I’m not convinced it’s smart marketing at all.
Grand Theft Auto used to be Playstation console exclusive but have now opened it up to include Xbox 360. Bad decision?
A bit of irony via Mirror’s Edge ‘Debut Trailer’ HD
Hint: The irony has to do with the title and the conspicous absence of something within the trailer.
Wired online features Ted Castronova’s 5 tips for making games that don’t suck. Unfortunately, it seems Ted still has a lot to learn.
Don’t Be Overly Ambitious “We thought it wouldn’t be too hard to design a realistic War of the Roses-era economy, complete with swords, armaments, horses, food, and clothing. You want to create a suit of armor? First you have to smelt brass to make the bolts and gather fibers to make string … We soon learned why most designers don’t do that level of realism.”
[Immutably Me: You can be ambitious within the limitations of your situation (budget, team size, experience, etc.)]
Go Low Tech “If you can’t find a professional game studio to partner with, start small. There are lots of simple development platforms to experiment with. Look at Tribal Wars — it’s an HTML-driven online game with hundreds of thousands of users. It can be played in a browser window.”
[Immutably Me: Web Games are not inherently low-tech, neither is Nintendo DS. Low-tech would perhaps be a card game.]
Think About Your Audience “We put Arden in front of Shakespeare experts and they loved it. We put it in front of play testers and they yawned. We’d get feedback like, ‘I talked to that Falstaff guy for a while and got a quest to go repair something. I logged out and never came back.’ Too much reading, not enough fighting. Arden II will be more of a hack-and-slash Dungeons and Dragons type of game.”
[Immutably Me: It’s foolish to assume that because players didn’t wish to engage in boring quests that they will be happier with killing instead. Look at the Myst series, The Longest Journey, etc. Players love exploration and discovery. It just takes skill to pull it off.]
Get a Full-Time Staff “I love my students, but they just don’t have the schedule to do this. I have a very able lead designer and an excellent lead artist, but they had to pause for midterms. You need a core group of 60-hour-a-week people.”
[Immutably Me: Wrong. Wrong. Wrong. Great game experiences can be created with two people or 200. How much over time you force them into does not make a better game. Look to Fez as an example.]
Concede Screwups “You face a moment where you can admit something isn’t working or you can lie about it. It’s like in Shakespeare’s plays: The tragic heroes keep making new mistakes that compound their original mistakes. The comic heroes muddle around and find themselves in ridiculous circumstances, but in the end they accept their own humanity, and the audience respects them for it.”
[Immutably Me: Post-mortem evaluations of a game can certainly be helpful to avoiding future errors but in my experience many people don’t learn and repeat the same mistakes again and again. I would say avoid foolish errors by surrounding yourelf with appropriate professionals and learn to trust them to do their job well.]
I think game design should be like tickling.
I love tickling. I love it because it brings back a memory from my childhood when my uncle would tickle me.
My uncle was both personally and professionally dramatic in all that he did. Tickling was certainly no exception. When he would get it in his mind to tickle-torture me [I’ll get to the torture in a moment] he’d start with an expression—-nothing too extreme or over the top but there was no mistaking that his attention was on me. He could go from watching TV or chatting with someone to watching me from the corner of his eye with such intensity and focus. Then he’d arch a brow and slowly turn to face me, like a vampire hungry for blood. By this point I could already feel all my muscles turning to jelly. Escape was made impossible by the simplicity of anticipating what he was going to do to me.
As if that wasn’t enough, he’d slowly raise one hand in my direction, which would be tensed into a claw, and say in a cold and evil voice, “I’m going to tickle you and there’s nothing you can do to stop me…” The corners of his mouth would be upturned into a sinister grin; eyebrows knitted together.
By this point, I would be squirming, fruitlessly trying to regain control of my body, with a contradiction of laughter and dread keeping me immobilized and that was when he would slowly rise, claw still outstretched and…
slowly…
and deliberately…
…stalk towards me.
This usually served as motivation for me to try an escape that ended up looking like a scene out of a survival horror movie where the heroine is crawling and wimpering towards an desired egress that she never quite makes. That is precisely when he would lunge, like a lion on its helpless prey, and tickle me until I thought I would pee myself, all the while he’d be laughing like a madman.
As I remember this, I realize that game design is like this. I want players to anticipate the game the way I anticipated being tickled to death. I want them to be pleased knowing what is about to happen and curious about what they don’t know will happen, so that in the end the build-up and the pay-off merge into an experience that players will remember for years to come.
J.J. Abrams has a different spin on this and explains it much better than I have. Check the presentation he made at TED below.
I spent the better part of last week agonizing over flowcharts to describe aspects of my designs. I say “agonizing” because the single most difficult challenge of communicating a design with a flowchart is understanding how the intended recipient of said chart will react to it.
In my case, it is (ideally) for programmers and artists, which means it needs to speak plainly, be reasonably easy to follow, and communicate equally to a left-brainer and a right-brainer. Frankly, I’m not even sure this is possible without tearing a hole in the space/time continuum but I digress.
In a previous effort, I submitted a flowchart for a different kind of gameplay and received a stiff response from a programmer saying, ‘drop all the colours and dotted lines, keep the chart simple and don’t embellish’.
Thoroughly chagrined, I edited the chart and removed all of the artsy colours and variations that I’d thought would so cleverly differentiate the various states, phases and actions to one box type, connected by one line type and no colours.
‘Better…much better.’
Then an artist approached me and exclaimed, ‘I can’t tell the difference between a camera shot, phase change and a state; why not have colour variations and different shapes to set them apart?’
I showed her the original chart and with a smile, she said, ‘Yeah! Just like that!’
Just like that…
So, when I received my design review back with a tiny notation that asked for me to “make a chart” I knew I’d need to have more specifics. So my question was to the point: “who is this chart for?”
The answer was, of course, programmers and artists.
Right. Good.
This time I was going to handle things differently. Details were clearly going to be needed here and I’d avoid unnecessary colours if possible. So I got to work… for hours… then days… then days and nights and toiled. Several times I got so muddled in the ‘if this occurs then move to that state’ type thinking that I started seeing flowcharts in my mind of what would happen if I had another glass of water without going to empty my bladder.
When the going really got tough I called on a designer buddy and a programmer friend to oversee what I was up to so that they could give me the sharp kick in the nuts that I would need whenever I was on the wrong track. And they so graciously did kick me in the nuts repeatedly to help me get the work done.
Thanks guys.
In the end, I was very pleased with the work that I’d done and felt like the overtime poured into my flowcharts was well worth the learning experience.
Until Friday at 5 o’clock when my work was reviewed and I was informed that they were entirely too detailed and that I’d need to re-do them all in a much simpler way.
Now I know there’s a lesson in all this. Oh yes, there’s a lesson. Somewhere…and perhaps I’ll flowchart it when I figure it out.
