Storytelling in games is a huge subject, dividing opinion across the industry. Were one to listen to certain industry figures, one might quickly surmise that the industry had better decide one way or another about story-driven games and gameplay-driven stories, and games that are just games and might have stories and oh isn’t it all terribly confusing and what ought we to do? Looking at it from a functional perspective, I think that there are two reasons, with respect to stories, why people play games. One is obviously to experience the game’s story, whether it be completely linear or branching like in the excellent game Way of the Samurai.
The other reason, and this is something I’ve wrongly scoffed at before (and even very recently), is experiencing the game. People have said to me that Tetris tells a story. It has a beginning, a middle and an end. It sounds ridiculous in the context of a plot, but where the idea holds water is in retelling this story to other people. I can’t be sure how many players of Dwarf Fortress were introduced to the game after reading SomethingAwful’s forum goons “Let’s Play” session in the fortress of Boatmurdered. I bet it’s a huge proportion. Many games become popular through word of mouth and the best way to get someone interested in something is to tell them a story about it. If a game can create accounts that are interesting to tell and interesting to hear, as well as interesting to experience first-hand, that is a powerful thing for the players and their friends.
When I first heard about Chris Crawford’s Storytron, I scoffed at that, too. I downloaded it and couldn’t make head nor tail of it and that was that. I recently downloaded it again, and tried to read the web site, and didn’t get much further than before. But this time I actually understood what he is trying to do. He’s trying to make it possible for people to create a set of data that will produce interesting stories. Imagine a game like Way of the Samurai, with its branching plots and intricate character layers, but it’s not a fixed tree any longer; each time you play the characters interact in a different (yet still predicatable) way. It would make for some excellent whodunnit style games, at least. The systems in place in Dwarf Fortress are the same, really – you have a large set of data and a simulation, and running that simulation with player interaction, even if it’s a fairly simple simulation, can produce intricate stories for retelling.
Some of the greatest game stories I’ve ever heard came from people who had been playing MMO games: Player versus Player conflicts on a massive scale in Dark Age of Camelot; epic raids in World of Warcraft; spontaneous gatherings to mark a real-world death in City of Heroes; pilots going rogue and spying on other corporations in Eve Online. Surely the draw of these games is driven by this, whether the players know it or not.
I was reading the Tarn Adams interview on Gamasutra, which is absolutely terrific and I encourage everyone to read it, and then I came home and read about people being fed up with modern gaming. I started thinking about why older people stop playing games, why they get bored, and began asking myself the usual questions: Are the games badly made? Are the settings boring? Are the game designs too derivative? Then I started thinking about game types, like shooters, world-building, puzzle games…
Then I stopped, because it didn’t make any sense to tackle it from that angle. Instead I started to think about why it is that people play games in the first place, and I came up with a bunch of reasons. It’s worth noting that I haven’t studied play in any way, so I’m really just throwing out lay ideas.
This happened because of the consolidation I mentioned earlier. The furniture is hacked to always load the chair model. The Actor always draws the 3D model if it exists. When I put the code in the same class, the player started drawing a chair instead of the player sprite.
While I’m busy not writing the camera frustum calculation code, I’m looking at making actors in the game (zombies, furniture, the player etc) more manageable.
There are two goals. There first is serialisation and dormancy: I want to be able to reduce anything in the game that isn’t scenery to as small a data set as I can so that I can save it to disk or keep it in memory without it taking up unecessarily large amounts of space. That is to say, when an entity leaves the playable area, or when the game is saved, I want to lose all the fluff that is used to make the entity seem real on the screen, but keep enough that later on, I can rebuild a reasonable likeness of the entity as it was on-screen from this small set of data.
The second goal is to remove the object-oriented inheritance tree I made for the earlier prototype. Currently, the game knows about a base type called Actors, and the Zombies, the Player and the Furniture all derive new classes based on Actor and implement new code on top of it. What I want to do is have a pool of Actors that know how to be any of these things, so that I won’t have to keep a different pool of each type of entity. What this means is centralising all the code from the three existing classes into Actor, and removing type-specific stuff into places where it makes more sense. This would also more easily let me create more than one Player entity, for example (it’s worth noting at this point that I haven’t consciously built the game in any kind of network-friendly fashion, so I doubt this game will have network multiplayer in the foreseeable future).
For example, at the moment the Zombie class doesn’t do much except set up a new AI program to control the zombie, and set up the graphical data to display itself. There’s some other stuff in there to do with taking damage and seeing the player, but there’s no reason why these couldn’t be in the main Actor class, even if it were under some entity-type condition. On top of this, moving the AI code into the base class would let me set up AI programs for anything, not just zombies.
Overall, I see lots of benefits to removing my badly-designed object hierarchy and making the whole thing more modular.
So this is the first public development log for Deadrock. I’ve been posting screenshots for some time to the forum, but I’ve decided to move most of my output to the blog.
Deadrock started as a 2D rendered isometric view much like the old X-Com games. I was calculating all the depth myself and drawing everything by hand. It was all rather tedious and confusing, so for this reason amongst others, I switched to 3D.
It was fairly easy to do in the end, and I managed to reproduce my old 2D view pretty quickly. One upshot of this is that I can draw anything I like in 3D now, so I decided to make all the furniture in the game 3D. The furniture is created in Blender, and then exported to Wavefront .OBJ, loaded in to the game and drawn as a display list (or in OpenGL immediate mode).
This is 60 chairs each of 6 quads rendered at different angles and at a far greater scale than they ought to be, on top of what the world currently looks like. Most of the draw time is drawing the world, as it’s not properly culled to the camera frustum. It currently takes 2 milliseconds to draw these chairs on my machine. Should be OK to use as it is then.
In a rather exciting bit of news for aspiring and hobbyist developers, Microsoft has announced that it will be rolling out its “YouTube for games” service, which it has named “XBox LIVE Community Games”. You can go and download some of the games that have been in development for XNA right now to your 360.
This is great news especially for students, as Microsoft simultaneously announced that it will provide students attending participating Universities with free versions of Visual Studio 2008, XNA Game Studio, and Creator’s Club membership. They, and I, hope that this will foster a new wave of hobbyist game developers and allow innovative and interesting new games to hit the mainstream. Developers can even make money from their creations on this service, although the methods for doing so are still being ironed out.
All sounds pretty good, right? Well, there are two sides to every coin. Several people have independently told me that during GDC Microsoft also made official their rumoured plan of dropping the royalty rate for self-funded independents on XBox Live Arcade to half what it was before – since it was between 60% and 70% before, this means it’s closer to 30% now. I’ve heard that people on the XBLA team think this is a bad idea, and to me it just points to XBLA becoming more of a digital download route for publisher shovelware.
You can read my feelings on XBLA’s output here. It’s nice to see that, at least in part, my complaints in that post have been addressed by the introduction of this new service, but what of professional indies now? How will Ninjabee or PomPom survive with their royalty rate cut in half? Should they move their output to XBL Community Games? If they do, they lose the ability to take advantage of Achievements, Leaderboards and other features of XBox Live Arcade that make the service so popular. Should they stay on XBLA? Maybe they can’t afford to now, what with self-funding the entire project in the first place.
It feels like Microsoft is pandering to the publishers while trying to get as much new content as they can for free (this is unfair; developing XNA must have taken a lot of effort, but on the other hand anyone who isn’t a sudent has to pay $100 a year to use the service). There is no room in this new system for professional indies.
Kieron Gillen has come out in praise of Andrew Doull’s article about the distinction between what he calls “indies” and what he calls “amateurs”. The article itself is rather long, but if you read the emboldened sentences it will give you an idea of quite how misguided Andrew apparently is. Here’s what Kieron had to say:
Probably my favourite piece about games this week was Andrew Doull’s Amateur column about the difference between Indie and Amateur. Judging by the comments thread, not many people seem to Get It. You need to accept Andrew’s terminology and then just roll with it. If you do, it manages to nail a fundamental difference in the approach of developers to the work and throw a lot of great one liners too. I especially liked “Indies release when they’re ready for a private beta; Amateurs release when the game compiles”, “Every odd numbered Introversion title (Hacker, Defcon) is indie; every even numbered one (Darwinia, Subversion) amateur” and Peter Molyneux being analysed as the patron saint of amateurs.
I don’t think the people (myself included) in the comments of the gamesetwatch article don’t get it; it’s a pretty basic point to make in the first place and from a developer’s perspective comes pretty much as common sense. As a professional games developer the distinction between releasing a game when it’s ready and releasing the game because even though it’s crap your mates are sure to like it isn’t even one that needs to be made.
I’d have no problem with an article that discusses professional vs. unprofessional software development practices, just as I’d have no problem with someone examining intent; the problem with the article is that it bundles developer’s intent along with their level of professionalism and wraps them all up in two words. Not only do these two words already have meanings, but generalising developers into two groups like this is both inaccurate and pointless.
Professional and unprofessional. Intent to make money and no such intention. These are two axes, not one.