Be Social

+

Lessons I’ve learned about Game Design in September

September 28, 2012


Part of the reason I’ve been silent for the last month is that I’ve been working on a little project. It’s no secret that I’ve been looking for something to do with myself in my spare time and, with money tight these days, it better be something I can do that doesn’t require massive investment. Something like… game design. Keep your laughter. I’ve learned a thing or two since I started out on this journey.

I’ve looked into writing novels and such, which I’ve always wanted to do and have had some practice doing; editing, since I have some talent in that area; translation, and more specifically marketing adaptation, which is a greater challenge than most kinds of translation; helping businesses starting out with marketing and social media planning; finally: game design.

Back in 1985 I started playing Dungeons & Dragons. Almost from the start, I found the existing rules wanting, but the brilliant thing about role-playing game franchises is that just as you’re getting tired of them, they come up with updates, or a new system, and then you decide you’ll give that a try rather than write your own. After all, the books are cheap ($14 for my Player’s Handbook in 1987) and you want to spend your spare time playing, not working on your RPG.

I got on the bandwagon with Advanced Dungeons & Dragons, then 2nd Edition D&D, Not 3rd edition, 3rd edition, 3.5 edition , 4th edition (The Player’s handbook is no longer $14). I spent a fortune on these books over the years, and I never found a system that I could honestly say I liked 100%. I looked left and right too. GURPS, Vampires, Ars Magica, Dangerous Journeys and a dozen others were great in their own way, but I never found the perfect system. There’s no such thing, of course, even if Dangerous Journeys came pretty close to what I would consider perfect. (Though it was so despised by some of my players that the whole thing gave me pause)

I even designed my own gaming system, borrowing elements that worked from other RPGs into a “Frankenstein’s Monster” type of RPG that gamers might term “horribly, horribly familiar somehow”. I didn’t get a chance to test it, and recently lost most of the gaming files I’d written myself in a freak disk drive accident.

I told you that story to tell you this story:

When I was 17, I had an idea for a game. A hybrid between an RPG game and a table-top strategy game, but assisted by a software component that would tie multiple locations together into a persistent universe. A multi-layered game where the RPG influences the strategy component, and the strategy component provides the backdrop for the RPG and dramatically shifts the environment with every play. I was coding a lot then, and I wanted to write the RPG component, then the strategy component, and then tie it all together with an application to manage games across multiple locations, multiple players, tracking wins, losses, and adding a graphical representation of the universe that could be consulted like a graphical database. Like my Frankenstein’s Monster, it took some successful elements of game design and combined them with recent technologies into something “Next Level”.

When I estimated how long it would take me to code this application, I got sticker shock. 13 man-years. Wow! 13 years! While I briefly considered doing it anyway, I knew deep down that I couldn’t get it all done, and eventually gave up on the whole enterprise.

This month I decided to take that idea off the back-burner and look at it again. I mean there’s a lot of open source stuff out there that I might use. Components and whole environments that I might leverage and tie together. It should take me a lot less time to do it today than it would have taken me to do it 20 years ago, right?

So I updated my concept with social media, adding two more layers to the RPG and Strategy component: Social interaction and Trading between players, and a final layer – Real world geographic proximity. Again, like with the Frankenstei’s Monster, adding the latest technology and building it into a social environment and into the game mechanics to go up to the “Next Level”.

It’s still a work in progress, but I thought I had a pretty good idea how it might work. Time to estimate how long it would take to put it together, not counting the RPG and Strategy and design components; just the coding part… 13 years. Damn! 13 man-years again. There’s no getting around the coding. Development is very time-consuming.

What’ll happen to my project? Maybe I’ll just do the RPG part, and play with my friends, then publish it. At least it’ll give me something to do in my spare time.

So what have I learned this month through the process of figuring all this out?

1. Ideas are a dime a dozen.

Everybody and their brother has an idea. What matters is the skill, will and financial capacity to execute. With 20 years of gaming experience, I’m pretty sure my “Scion Wars” would be a hit, but to make a game, you have to be a game studio, or else set your sights quite a bit lower.

I checked out game development boards and platforms, open-source tools and server systems, and one constant thing you’ll find everywhere is teenagers with ideas to peddle and looking for an experienced team of programmers that will work for free. It’s pretty awesome, isn’t it? Half-baked ideas are absolutely everywhere.

2. Platforms are limiting.

Once you’re on a platform, even a fancy one like Unity, you’re stuck with it. If it turns out later that it comes up short in something you wanted to do… well that’s just too bad. They might fix it later. Or they might not. It’s not like you’re going to rewrite your whole application on another platform, so they’ll only really accommodate you so far.

The choice of platform, IDE, Language, OS, architecture, protocols… these impact far more than your development time. They limit what you can and can’t do, ultimately meaning that this feature or that feature simply can’t be implemented because of choices that were made, sometimes arbitrarily, at the inception of the project. Every developer has a horror story of a project stalled, killed or abandoned because it hit a brick wall of feasibility.

3. Coding is hard work

Much as I don’t like coding anymore, I do have to admit that it’s hard work. And it’s work that often goes unrecognized by employers, managers, even players who often assume a game will just materialize out of thin air through some mysterious process of condensation somewhere in a lab at Electronic Arts.

Coding is more than an art. It’s a tough job. Physically it’s tough on the eyes, tiring on the brain, and if you’re driven by slave drivers, possibly death by exhaustion and certainly the threat of divorce… If you somehow had a real girlfriend in the first place, that is.

4. Game design is easy

If you have the prerequisites, designing the game is relatively easy. Sure, you need to have a solid grounding in a few different areas. You have to understand people in general; have at least a rudimentary grounding in psychology. You have to understand the gamer subculture, if you plan on appealing to them. You have to have a solid understanding of probability and statistics if you have any kind of random factors affecting outcomes so that your game is balanced and you don’t end up with statistical anomalies ruling your games.

If you compare the design part in terms of sheer volume compared to the development of the software, there’s almost nothing to the design part, like 10 to 1 sort of thing. It would take me about a year to spec out my game idea. 13 years to actually get it done. That’s not a fun thing to discover.

5. Developers need to eat too

The number of requests for free development on the forums is absolutely crazy. I think the open-source culture has discoloured people’s perceptions about the value of programming. Why do people think that someone skilled will work for free on someone else’s “idea”? It’s nonsensical and wrong. I wish people would stop asking.

A funny side note here. When I started my career in IT, most of my colleagues were fat. We ascribed that state to the relative inactivity of sitting at a computer for most of the day. Today’s developers, those I’ve met or seen anyway, are a lot thinner, even though they too spend most of their waking hours at a keyboard. I’m convinced this is because they are starving. Pay your developers according to the value they create.

6. If you’re not a game developer, stick to what you do best.

While I’m perfectly capable of designing a game, without the ability to execute, that capacity is wasted. Since my strength happens to be marketing, perhaps I should look for game developers, companies, or businesses that need that kind of service and just do that instead. I think I might be even better at marketing a game than designing, or coding it. Maybe then they’d be interested in leveraging my game design capability as well.

Lessons learned.

Tagged with:

7 Comments
    Paul Sep 28, 2012

    Number 3 is understated somewhat. Coding is actually easy. It’s the architecture and design that’s hard. But only if you want sensible, testable, configurable, expandable, and scalable software, in addition to having it work the way you want.

    Let me tell you: designing this kind of thing, like I was doing today… better than chocolate.

    Reply
      Alex Nuta Sep 28, 2012

      Wait, I’m confused. #3 is : Coding is hard work. So if it’s understated, should it be that Coding is very hard work? Because then you say it’s easy. I’d put a lot of stock in what you have to say as an experienced developer, since you’ve done a lot of programming yourself, but I don’t see where it’s easy either physically or mentally.

      Unless you’re comparing it to, like, digging or something.

      Something being better than chocolate isn’t hard. I don’t like chocolate. I think I’d rather write a program… 😛

      Reply
        Paul Sep 28, 2012

        You are right — my statement was unclear.

        What I meant to say was that the coding part of software development is the writing part, which is the easier part. But what to write? That’s the design part, and that’s the part that’s hard, as compared to the writing, but then again, it’s only hard if you want to do it right.

        Perhaps the confusion stems from my separation of coding and designing? They are linked, certainly, but they involve different mindsets. I had a 3-hour design meeting today, of which any talk of actual coding occupied about 5 minutes. The design involves abstractions of objects, their interactions and how design will affect how they can be configured, tested and reconfigured if we change our minds later. Both activities require being “in the zone”, but they are different zones.

        Sometimes I can relax by coding, but designing is rarely relaxing for me…

        Reply
    Alex Nuta Sep 28, 2012

    It’s funny, but I’ve always loved writing specifications and project documentation. While I have a relatively low interest in actual programming, I find the prospect of tackling a complex development project from an organisational and a logistics standpoint quite invigorating.

    Reply
    Paul Sep 28, 2012

    Like the war strategists say, no plan can survive contact with the enemy. For software, no design or specification can survive the coding phase. That’s why Agile development was invented… The design and specifications need to adapt to things that come up. In other words, you’re going to be a programmer – you’ll have to let your hair grow long, grow a beard… oh, right.

    Reply
    John Tremblay Sep 28, 2012

    Obviously, you have known that to get the 13 yrs down to something manageable, you would need a team of coders. That takes money… so they don’t starve 😉 That takes investment and capital. Who’s willing to invest in someone with no apparent track record? Few and far between, if at all, right?
    You owe me a penny for my thoughts:
    1. Kickstarter.
    2. Develop a silly app for android, like Angry Birds, et. al. and see where that goes. You never know, if it catches on, and with your marketing skills it will be given half a chance… some money and some needed track record might attract investors.
    3. Kickstarter.
    4. Taking a lesson from Joss Whedon, give the bosses with the money what they want, surprise them with your innovation , and then you are in the driver’s seat. (see: Avengers).

    Reply
      Alex Nuta Oct 02, 2012

      You’re right, John. A project like that would need a team of coders, and not just any coders, but experienced, professional level developers.
      I don’t have the money to support anything like that, and the fact that I’ve never done anything like this is not likely to seduce any investors.

      Kickstarter is a good idea for small projects, but in order to successfully raise enough money for a large project, you would need to make a lot of information available, info that simply doesn’t exist today. Keep in mind I only started thinking about this in September.

      Frankly I’m not even sure I will persevere with this, after advancing a bit further in the concept and mechanics. It may well turn out to be a much smaller project such as an RPG scenario, setting or something like that, but it would take a completely different form because, to be successful, the online project would require several important subsystems and marketing processes. Without those, the whole thing falls down.

      The whole point of Scion Wars is the meta-game, not the primary games. The real-world game interaction is what makes this different and interesting. You’re not playing a character. You’re playing yourself and interacting with other players in the game environment and in the real world.

      In the next few weeks I’ll spec out what it is that I would need and I might put some of the resulting documentation on the blog for you to see. It never hurts to have some peer review.

      Reply

Leave a Comment

Please keep in mind that comments are moderated and rel="nofollow" is in use. So, please do not use a spammy keyword or a domain as your name, or it will be deleted. Let us have a personal and meaningful conversation instead.