Defining “Game”
Nov 8th
Recently, a friend of mine was deciding a topic to write on for a university essay. One choice that he had was a discussion about a “serious game”.
For those of you who are unsure what the term “serious game” means, or what one is, its generally accepted to be a game thats educational, raising or making a moral or ethical point, or a reflection on events past or present. Perhaps one of the most well-known “serious games” is Super Columbine Massacre RPG, which gained alot of publicity (good and bad) a few years ago for its depiction of the events of the massacre.
The discussion with said friend seemed to centre around one key point: How to define a serious game. After all, without defining it, then you can’t really analyse how a given game fits into that category and what sets it apart from a non-serious game.
On an even lower level, perhaps he should have also been asking: What is a game, and how can we define it? Terms like “Serious Game” and “Art Game” get bandied around alot, and the general public seem to have a gross misconception about what these games are and indeed what they can represent.
This has been a point of discussion for academics for many years now. I remember having the discussion many times at university. But does it really matter if we can or cannot define what a game is? Because games are more of an art than a science, its probably not as important for game designers and developers to have a strict definition of vocabulary as engineering or other science-based disicplines.
Defining the term “Game” probably won’t help you make better games, or make better decisions as a designer or developer. But I do think its an interesting exercise to get people thinking about the elements that actually make a game and how games are differentiated from toys and other enjoyable activities that people engage in.
Lets go back to that wonderful book “The Art of Game Design” by Jesse Schell. The definition of “game” is something that Schell addresses nice and early in his book – Page 26, in fact. Schell defines a bunch of categories, goes over old definitions of “play” and “toys” and “games” to eventually come up with his own meaning:
A game is a problem-solving activity, approached with a playful attitude.
I’m sure most people reading this will instantly be able to think of a game that doesn’t fit under this category. Clearly the term “playful” doesn’t cover serious games such as Super Columbine Massacre RPG. But even in non-serious games, my friend thought of one example himself – two people playing Grand Theft Auto and just doing crazy tricks in cars and on motorbikes.
Its true that this isn’t a problem solving activity, but can it really be called a game? Or is this simply “play” or “fun” using a game as a medium? Does that even matter?
I don’t have answers to these questions, and I’m sure that the debate will continue to rage amongst academics for years to come. However, it can be useful to keep these things in mind the next time you’re explaining Super Columbine Massacre RPG to someone.
RE: Why University Is The Best Place To Start A Games Company
Oct 7th
I recently read a blog post by Daniel Sefton on Gamasutra (originally from #altdevblogaday) about why university is the best place to start a games company.
As a current (almost finished) university student who has been involved in a startup with a group of friends from my course, I can absolutely attest to the general idea that is being pushed by Sefton. However I think that the advice and steps he’s described in the post don’t get at some of the real issues and benefits of why this is a good thing to do.
Lets face it: very few people want to be a cog in the machine of a company. Very few people attend university and get a degree with the intention of getting stuck in a dead-end job. The industry still needs innovation and trailblazers and theres plenty of room to do so. There are, and have been, some interesting machinations in the industry of recent times, not least being the rise of the mobile platforms as well as general accessibility to industry-standard technology to distribute games on a multitude of platforms. Crowdfunding is taking off, and several big companies (namely Sony and Bungie) run programs to help fund indie developers. Never before has there been a time as good as now for indies to have their chance at both success and fame. And as a university student, you can be in prime position to start taking up these opportunities.
Despite the fact that very few people attend universities to get stuck in boring jobs, I’ve found that not many people work hard enough to make their goals a reality. The analogy that Sefton makes is absolutely correct: “University is like a cheesecake. The degree you get is the biscuit at the bottom, and you have to fill in the cream and toppings yourself. With no cream or toppings, it’s a dry experience with a cog-in-the-works outcome.”
University will give you the bare-basics of what you need to know to get through the course. But to truly succeed and make something of yourself, you have to do much more. And those team experiences, development pitfalls, release management, quality assurance and everything in between are very rarely things that a university subject will teach you.
While it may be true that a university is like “one big ass games company”, the fact is that not many people are driven enough to achieve anything during their time there. Its no coincidence that the dozen-or-so of us that formed Pub Games were amongst the highest achieving students at university as well as the ones who had engaged in our chosen disciplines outside of university. These sort of social groups tend to naturally form – the high achieving and motivated students tend to gravitate towards each other after a little while. Aim high and be motivated early on and you’ll find that things can and usually will fall into place further into your course. If you find that your friends don’t have the talent or motivation, then perhaps its time to find new friends.
Not every university will have dev kits, or software licensing, or people from all disciplines. But a vast majority will have lecturers and mentors that care about being there and care about teaching their students. If they can’t help you directly, they’ll generally point you in the direction of someone that can. One lecturer in particular at my university has been invaluable to us over the past few years. I believe they are very good at identifying the driven students and will almost always go out of their way to offer advice and assisstance wherever they can. This is an amazing resource that you should use wisely, as good lecturers and professors can help you become not only a better developer, but a better person.
Perhaps the most important element Sefton missed in his post is the issue of failure. No one likes to talk about it, but its a very real thing to deal with in our industry. Being a university student is the best time to try and fail. A lot of people still live at home with parents, or they have someone else supporting them. Not a massive amount of money has to go into forming a company initially (as Sefton pointed out, you don’t even need to incorporate until you get serious), so if things go pear-shaped, not much has been lost. And the most important thing is that you’ve given it a crack and you have the experience. Even failure can teach you plenty of lessons that can only be helpful down the track.
Theres no doubt that sacrifices have to be made in order to be successful, and its especially hard during your late teens and early 20s. I couldn’t even begin to list the sacrifices I’ve made during the past 6 years developing NightFall, Age of Chivalry and now my involvement with Pub Games. But the experience I’ve gained so far has been invaluable and once we have our first game on the market, its going to be a great feeling of achievement. There’s nothing like seeing your own design come to life right in front of your eyes, having people play it, smile and compliment you on a job well done. With a lot of hard work and a bit of luck, your hard work has paid off and its an incredible feeling. And most importantly, its been done with a group of friends you love being around and working with.
The Art of Game Design
Jul 26th
I’ve never really discussed much about books on this blog. I love the fact that there are some fantastic books around about games, design, art and programming, and I myself own many – even some out of left field, such as “The Elements of Style”. Textbooks for most subjects tend to be fairly pricey, and generally universities don’t even recommend the best, or the most up-to-date titles for their subjects. At Swinburne, many subjects didn’t even had a recommended text. I’ve generally tried to work outside the box of most subjects, and do my own research and find relevant books that can help me better understand or learn the subject content.
Books often get negative views from some people. And this is understandable – there are alot of horrible books around. Many of the good technical books are aimed fairly low-level (GPU Gems, for instance), and thus are much less relevant for any designers, or programmers who use existing engines or frameworks. But there are a few gems that I can’t recommend highly enough to anyone, and I’d like to discuss one such gem in this post.
I recently purchased “The Art of Game Design: A Book of Lenses” by Jesse Schell. Surprisingly, this book was first published back in 2008, and I didn’t hear about it until this year. The most surprising thing is that The Art of Game Design is, in my opinion, the closest thing the industry has to a seminal book on design. And yet I never heard this book discussed at university, or in any design communities. Many books have tried to be “the reference” and failed, and while I can’t pass judgement after reading just 80 of over 450 pages, these 80 pages have been better than most lectures or articles I’ve read on game design.
As a designer, there are alot of processes you engage in subconciously, and alot of knowledge that is acquired simply through designing and making games. What The Art of Game Design manages to do is put these processes, thoughts, techniques and knowledge on paper. At the heart of the book are 100 “Lenses”, which are views that designers can look at their game through to ensure they are really achieving what they really want. The very first Lens in the book – “The Lens of Essential Experience” - is a great example of something that good designers do subconciously. The lens states
“To use this lens, you stop thinking about your game and start thinking about the experience of the player. Ask yourself these questions:-What experience do I want the player to have?-What is essential to that experience?-How can my game capture that essence?”
This lens stems from Schell’s assertion that the goal of a designer is to create experiences. The goal of a game designer is to create experiences using games as the medium. This is one fundamental thing that seems to come to designers so naturally, and yet often fails to get put into words. The use of Lenses helps you look at a game very objectively and ensure that you stay focused on exactly what you’re trying to create. In all of the discussions and lectures I’ve had (or given) on games, in all the design documents I’ve written or read, I don’t think this is an aspect thats ever been discussed. Many documents or discussions will mention the mechanisms used to convey the experience, but alot of these come purely out of common sense or suggestions from people outside of the game. Most designs don’t capture the essence of the experience – the essential elements that help define the experience. This is where designers can draw on real life experiences and let their creative juices flow, in order to create mechanisms that can capture the essense of the experience.
For instance, not many of us have been chased by a dinosaur. However, most of us have had scary experiences, and we can draw on these scary experiences and how we felt during them to create some meaningful mechanisms to help the player feel scared.
This might seem obvious to people who have played alot of games. But doing it as a designer is being over the other side of the fence, and you can’t continually draw reference from other games in order to create your experience, especially if the goal of one of your designs is to break some new ground. To natural designers, they probably do this subconciously, but how many have sat back and thought about why or how they do it? The cynic in me says “You don’t need to reflect on how or why you do something in order to do it well”, but I strongly believe that this can not only help someone become a better designer, but it can help us teach the next generation of designers how to improve their games.
Over the coming weeks as I read more of The Art of Game Design, I’ll no doubt be writing more posts about the book and my thoughts on various parts. Until then, I strongly recommend that you purchase this book.
The Problem of Infrastructure
Apr 3rd
With about 6 years of modding and game development experience under my belt, I’ve been involved with my fair share of teams over the past 6 years, either on a regular basis or for once-off help.
One thing that has constantly struck me – especially in recent times – is how little care most teams take in their configuration management and bug tracking. I’ve seen everything from teams using FTP to organise their assets, all the way up to one team who had SubVerison, Mantis and Forums all integrated into a unified login. With configuration management systems and webspace so freely and cheaply available these days, why do teams have such poor infrastructure?
One of the top image results for "pulling out hair"
Myself and a friend from Pub Games recently gave a short lecture to a group of students undertaking their final year project at university, and one thing that we couldn’t stress enough is the importance of a teams infrastructure to their success. There are a multitude of tools available – Skype and Google Docs are personal favorites of mine, along with Redmine for issue tracking, and SubVersion for version tracking.
Skype and Google Docs are absolute gems for communication and documentation. Being able to voice chat with a small group of people all working on the same document greatly reduces the amount of time and effort put into documentation (which we all know is an unforutnate side effect of being a developer). Most teams use Skype fairly efficiently but documentation is usually poorly maintained and kept in a place that few team members can easily access.
There are many issue tracking systems available. Mantis is the perennial favorite for most teams, as its simple to use and only requires PHP and a MySQL database. Redmine is my preferred tool, but it requires Ruby on Rails to run, which might limit its audience somewhat. Whichever software you use for issue tracking, its useful to try and use it for tasks as well as bug reporting, and ensure that your whole team use them regularly. Its great to be able to easily classify bug reports, and delegate tasks so department leads don’t have to be around for task delegation all the time. Alot of this sort of software also includes milestone planners, Gantt charts, and support good integration of most CVS’s (SubVersion, Git, etc), so you can tie alot of your systems in together.
Use an issue tracking system, and this won't be you.
And then comes the CVS itself. While alot of programmers will advocate the use of decentralized CVS, I’ve found that many non-technically minded team members will struggle to come to terms with SubVersion, let alone the more complex Git. Alot of programmers might dislike SubVersion, but given that games involve alot of less technically minded people, the trade-off to make sure that all your team members are staying up to date and uploading their work is definitely worth it.
Its also worth learning branching and tagging for when you run your testing sessions. Tagging your test builds and giving testers that revision as a reference number for making bug reports is really useful for tracking down crashes and regressions.
This is only a really short explanation of some of the tools that are available, and I strongly believe that the lack of use of these tools is simply due to a lack of knowledge and a lack of time on the part of teams. CVS’s are worth using even for individual projects, as you get a version history of your own work. Even moreso, they become invaluable for even the simplest of group projects, to avoid the common ‘Lets just email everything to everyone’ syndrome that often plagues university subjects.
So do your research. What I’ve mentionedhere is just scratching the surface of the sort of tools you can use to manage your project. There are plenty of free SubVersion providers around, or alternatively you can check out hosts like Dreamhost.com who provide fairly affordable hosting for Web, SVN and include techs like Ruby on Rails. These resources make it cheap and easy for anyone to set up infrastructure to support the project you are working on. So take the time to learn these tools. It will be worth it in the long run.
This post is the start of me using unfunny images to convey a point.
UDK Roundtable Discussions posted
Sep 23rd
I was recently involved in a UDK community initiative called The UDK Developers Roundtable. The Roundtable were a couple of live Q&A sessions which were then published into a chat. The first group involved UDK Enthusiasts, and the second were the ‘Pros’ – people who had worked for games studios, placed well in Make Something Unreal, or just generally had good experience. I was a part of the latter.
The conversations are an interesting read for anyone involved with modding or game development, with a number of experienced people providing some very interesting points of views on various topics. You can check out both of the discussions at http://www.ensemblog.com/
A flexible approach to design documents
Sep 19th
I used to be a huge advocate for extensive, detailed design documents. I even made a comment in my NightFall Post-Mortem document about design docs:
If a developer has to ask you things about the mod other than your opinion of work, you haven’t done your job as a designer. A design doc should outline EVERYTHING a person needs to know when joining the team.
This sentiment tends to be echoed around alot of forums that I used to frequent, although perhaps not quite to that extent. At the time, I believed it was a sound theory – you’re not always around for people to ask you design questions, and hey, things should be written down so they’re formalized in some way.
However, with a few more projects under my belt, this is probably one of a few ‘Lessons Learned’ that I’d like to revisit. Traditionalists, universities and many others will mandate that you plan every single little detail for your game or mod, even down to firing rates for weapons, health for enemies and many other small things. This is a great lesson to teach to game design beginners, as it forces them to think about every aspect of the gameplay. All these values need to be set at some point in time, and its best that its been thought about before you come to setting the value in your code. But is documentation of every single one of these values really necessary?
Its no secret that design documents become outdated fairly quickly – or at least once you get past the first stages of developent, and especially when you get into testing and balance. All those small values you came up with for health and firing rates will generally be wrong once you start testing the balance of your game. Features get prototyped and tested, and end up being not as fun as you thought. Smaller features that weren’t specced out in your design will end up playing a larger part in your game than was anticipated. Design is dynamic and flexible, yet we enforce the use of design documents that are neither dynamic or flexible. Design documents just become another piece of documentation for someone to update whenever a feature changes. Or, even worse, it doesnt get updated and reflects the product incorrectly.
In my final year university project this year, we were provided with very little documentation or gameplay concepts from our client. This led us down a path of having to flesh things out as we were doing them simply so we could keep up with the course work and not ask too much of our client at once. I’m not trying to advocate making a game without a design document – this was something that was unavoidable for us. We did have an overall product vision, and a client who knew what they wanted. But the specifics of these ideas weren’t written anywhere, and a requirements spec was a document that was required for the subject. The upshot of these problems is that we approached the design of the product in a much more dynamic way. We took an agile approach to our development – listed the main features, a dependency chart, and defined milestones. It was fairly traditional agile methodology.
At the start of each of the milestones, we wrote the design documentation for the planned features. Not in one large document, but as individual design ‘spikes’, if you will. Every major feature had its own document with the plans relevant to that milestone, reference links, required art, UML diagrams if required, etc. At the end of each milestone, these spikes were filed away in our wiki, and new ones for the next major features were written. If a feature was being expanded upon, the previous spike document was simply linked to as a reference. Not only does this minimize the amount of modification required to one full design doc as the product evolves, but iterative documents referencing previous ones maintains a nice log on what changes througout development.
At the end of our third milestone for the year, this approach has worked extremely well for our team. We’ve written enough design material to formulate a full requirements specification to meet the subject requirements, been flexible for a challenging design and ended up with a product of the same quality if we had a full document to start with.
Of course, there are limitations to this approach. As I said before, it isn’t a mandate to scrap a vision document. Keeping a few-page document with the core features of your game up-to-date is important to keep yourself on target for where you want to go. Each company, team or individual will have their own thoughts on exactly how much should be documented, and having worked entirely in an informal environment, design elements that are seemingly small, or the sole responsibility of one individual tend to just get done and not documented.
One example of this is ‘the numbers game’ – or game balance. This is an area of development I’ve never been heavily involved in. In Age of Chivalry, it was the responsibility of one designer, who played the game the most and had the most contact with community. It was an approach that worked fairly well, but his changes were rarely documented and nothing that anyone else could comment on. The game was no worse off for it, it still played great and ended up being pretty well balanced after a few patches. But the process and reasoning behind the numbers that he came up with, the other developers had no knowledge of.
Whether this is something that is significant enough to document, and whether the ‘design spike’ approach would work for it, remains to be seen. But this process is something that has worked for our project team, and is an approach I’ll be trying out with future projects.
DIYGamer pimps Means of Escape
Sep 6th
After the announcement of Means of Escape a few weeks ago, we were surprised to see the game pimped on DIYGamer. A massive thanks to these guys, it gave us a warm fuzzy feeling to see that the game is out there and getting positive comments.
Check out there short article here.
Means of Escape trailer released!
Aug 30th
Pub Games today released the first trailer for their work-in-progress title, Means of Escape. You can view it on YouTube. Make sure to check out the Pub Games website when you’re done!
Pub Games & New Video Tutorials
Aug 22nd
Pub Games, a Melbourne-based indie studio, has finally announced its first project, Means of Escape. You can check out our website here.
I’ve also finished several more video tutorials in my UDK AnimTree video tutorial series, including a tutorial on custom nodes, and how to play upper-body animations. You can check out the tutorials here.
More UDK Video Tutorials completed
Jul 31st
Two new AnimTree video tutorials are now up. You can grab them here and here. Tutorial 1 has also been re-done after some feedback.
Keep an eye on this thread on the UDK forums for updates. I’ll make a proper page here soon for the tutorials. You can also view them on the UDK Wiki.
