Tuesday Blues

18 11 2016

Well, not really blues, maybe a light aqua sort of shade…

“Amir” I hear you say, “you crazy beautiful bushy bearded programmer, I don’t think you’ve ever talked about managing the workload with Buck!” And you’re right, I haven’t written much about the project management side of things. So perhaps now is the time to draw the outlines of the hows, whys and wheres of managing a project the size of Buck.

Let me preface this post. Every team is different and so in my opinion every methodology must therefore be customized for those particulars. In essence; there is no magic “one size fits all” management process that would boost a team’s productive output. And I remember spending a lot of time when I had less experience looking for one. With that said, let’s start.

[quick note at this point; I know the title says “Tuesday” and today is Friday, but I started writing this post on Tuesday]

Before getting into our process and because our team is different from yours. Let’s meet the team.

Buck has three people working on it. A programmer [me!], the artist and the designer (who does animations, sounds, music and the business side of things on top of it all… we love you Gal). As you can see we’re a small team. A very small team. We work separately except one day a week when we meet and put in a full office-like workday. We wanted three basic things from our process. Simple, transparent and fast. We’ve tried several approaches which failed (and I might write about those later because knowing what failed is also important but I’m running out of time again).

So, what do we do?
Enter Trello.

Trello is a simple and free (yay for awesome free tools) online tool which allows its users to create vertical lists across a horizontal axis. Each list contains cards which can be moved between the lists or archived into an internal [hidden] list. As I said, simple. At the moment we’re using a single board for Buck and have broken it into two sections; one for the code/development and one for the art/design. I’m not familiar with the art/design section (I’m the programmer after all) so I’ll concentrate on my section.

Let’s take a small detour to the cards. We have two types. Feature cards and Bug cards. And, just as they sound, each does exactly what you’d expect. A feature card describes some game or editor feature that someone wants (me or the designer) and will usually take the form of a request; ie. “I want to do [X] because of [Y]”. Bug cards are broken into two. The title of each card will describe what the bug is while the description in each card will (ideally) describe the steps required to reproduce the bug (called in parlance, repo).

Onward to lists; five lists. Backlog, Sprint, Doing, Review and Issues.

The backlog list is the catch all of all features we want in the game at some point or another. It isn’t organized in any particular way and we add to it constantly… too constantly… it always seems to grow 😀 (though not all of cards will see the light of day and will remain forever unimplemented – until the next project).

The issues list isn’t anything special; any issue we or one of our testers discover ends up there. And like the backlog it has a tendency to grow somewhat. Unlike the backlog we do sort the bugs. Into minor, major and game-breaking. Guess which ones we take care of first?

Then we have the Sprint list. This list contains all the cards we’ve decided to implement in the current sprint session. A sprint session is a static (ie. not changeable) length of time we’ve set to get from point A to point B. Point B meaning BuildI can’t actually stress this enough but;
Sprint times are immutable. Do not make them longer or shorter while sprinting. Stick to your sprint time during the sprint and Do. Not. Change.

You can change sprint times. In fact iterating over the process is as important as anything else in the process. So, what did I mean? First, we do not end the sprint prematurely. And secondly WE DO NOT PUSH THE SPRINT END UNTIL WE HAVE A WORKING BUILD. Whenever we arrive at the end of a sprint and can’t make a build. Tough. We don’t make a build. We end the sprint. Failing to implement features means we’ve taken on too much and/or we’ve misjudged the workload on any particular card. This is our opportunity to learn. Otherwise the process will fail over and over again because we’ll never become better at estimations. Trust me; I’m speaking from experience here. Don’t do this.

So what can you do?
Like all good software developers: Iterate. Do a few sprints (unless some colossal failure happens). Review; do you want more features in a build? less features in a build? Add a week, take off a week. Rinse/Repeat. Small increments will yield stable results.

Our current sprints last about a week (fast iteration, only one programmer) and usually amount to one new feature implementation and bug fixes. They were somewhat longer when the project started because we needed more time to implement systems and set up the framework before we could implement game features. Experience and pain; get it and learn from it 🙂

Once the sprint list is set work can begin. I pull the card I’ll be working on from the sprint list to the doing list and when I think I’m done, I push it to the review list. After each build Gal will test and review each card in the review list while I’m working on the next sprint. Review cards that passed are archived; cards that failed are updated with information and put back into the backlog for the next available sprint. And that’s about it.

Nothing I said here is set in stone. Our team is small and very flexible. The planets do align sometimes to throw us a curve ball and we have to step outside the sprint. As a small team I suspect it’s easier for us and at times too easy. Keeping focus is also hard work. Anyway, I hope whoever reads these things of mine enjoys and until next time…

“I speak of madness, my heart and soul, I weep for people who ain’t got control”





Vexing Lyrically Some More

10 02 2015

I’m not really big on philosophy. Sure, I’ve had my run of it when I was younger. Attempting to define the universe and feeling quite grand about it. It’s not that I think philosophy is not important; on the contrary, I feel that these attempts are a strong force in driving us forward. But these days I also tend to adhere more to the Mel Brooks Perspective 😛

With that out of the way; let’s disseminate some more on my idea of games. And digital games in specific. In which I attempt to derive my understanding of a what game is by mostly trying to figure out what lots of things which are not games are.

I’ve already introduced a category for scientific experiments; which are clearly not games (especially the blow-up-in-you-face-and-two-city-blocks kind of experiments). Science attempts to answer questions by simulation of conditions. Games also provide an underlying simulation in order to provide interaction – interaction being a most important part of games. But this alone is not enough.

Let’s go on another tangent (because, why not?)

Flying an airplane, be it a fighter jet or a commercial one, is no joke. And definitely not a game for the pilots who are responsible for many many lives. And yet. And yet flight simulators exist. Are all flight simulators games? That’s an interesting question. Do we treat all flight simulators as games?

The first and probably biggest difference to notice between flight simulation games and real life is the absence of actual responsibility/personal danger. These games provide a safe environment to participate in an experience which is usually not available to their players; another element, escapism of a sort (or fantasy).

So to iterate; as their name imply, simulators have at their core the concept of simulation. But as we’ve seen before, simulation is not enough to make a game. What other elements are provided by simulators. Abstraction. Fantasy. Safe.

There are, of course, further elements which can make simulators better at being games. And as the simulation level increases I suspect that the “game-ness” of the product decreases. I wonder if realism is somehow a force working in opposition to gamism.

Well, more on that later. Real life is in the way again.

I was walking through the counters of a national concern, and a cash machine was spitting by my shoulder





Game Design Document

24 09 2012

The eponymous GDD, a frequently large behemoth slowly staggering towards both developers and designers with the clear intent of swallowing many, oh so many, hours of reading. Only to change as a flighty pixie the next day.

  • Do games really really need a great big design document?
  • What should a design document contain?
  • Who should write it, who should edit it and who the hell should read it?

These are all very good questions and ones that I completely intend not to answer with this blog post 😛
What I do intend to do is perhaps try and coherently go through my own thoughts and reach some conclusion that would help me achieve the goal of making a game. And I want to make a game, actually make that plural, I want to make games (made a few already, but nothing that was specifically mine). Where do I begin? an idea…

Ideas however live in my head, quite happily mind you, but in order to make a reality from my dreams and visions I must first somehow capture them and, wait for it… yeah, here it comes… building for it… and WHAM! Communicate them to other people so that they can help me; rather than think I’m a raving loon.

Communication is hard, really really really hard! And is also the heart-stone of collaboration, without it no games would be made and the world would be a sad place indeed. Anyway, where was I? ah yeah, communication… how do I go about capturing my beautiful and elusive sprite-like idea, why with words, down hard on paper (well, e-paper anyway). And here is the crux of the game design document’s key role in a team. It must communicate the game design to people other than the idea guy. I don’t have time nor the inclination to write a 100 page review of every nuance in my current project simply because I don’t actually have it yet. So what is a poor developer do?

I thought hard on this subject, very hard (because it’s a hard subject) and I read books, not too many because they’re hard to come by and did I mention the whole poor developer angle here…? Then I met my friend a few days ago (who is also my artist on the current project) and we started talking (which I guess is as close as two guys are going to get to communicating 😛 ). At some point in the conversation we suddenly realized that we are talking about the same project but for some reason we’re both talking about completely different things. So I figured let’s stop and stock-take.

What we needed was a clear guideline to our thoughts. The best way to do this, I thought, was by drafting a few questions and then writing our answers to them. It didn’t take too long, it wasn’t too accurate and it’s most definitely did not produce the detailed design document I was used to from before; instead it was fun and it worked. Let’s call it the Game Overview Document just because I like the acronym better 😀

The questions themselves are fairly generic and will most surely be modified, changed, enhanced and removed as the need arises, but for now they are as follow:

  • What is it called?
  • What is it?
  • What is it about?
  • Who will play it?
  • Where can they play it?
  • How are we making it?
  • Why are we making it?
  • Why should anyone play it?

The answers to these questions, by the way, should never ever ever be, “because it’s fun”, “because it’ll be awesome” or any other variation of the theme.

The result of this simple approach led to very succinct guidelines that would allow us to write the story, design the map and create the content. It also lets us remember why we are making this game and what it is with but a single glance; something those insane GDDs never let me do before. The other result of this approach is that I’ve split the main document file into several different files meaning I got a few more files lying around in the /docs/ folder but it’s easier (for me) to navigate through to the things I need; like concept art, maps, tech, etc.

Next, I’ll answer these questions and see how clearly I can communicate my thoughts about this current project (which at the moment is called The Fallen).

“we’ll find happiness together in the summer skies of love”