Green Door Games

So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!

In our last post (Step 4: In which we transform big software problems into smaller, more manageable ones) we used System Analysis (one of our Analysis Superpowers) to turn our use case diagram and feature list into a set of well encapsulated packages (or systems). Now all we need to do is decide which system we should start on first!

This seems like it should be an easy decision, but don’t be mislead! Where you start your low level design makes a big difference. A lot of engineers (myself included) like to start by working on parts of a solution they already understand; solving problems you already “get” is fast, feels good, and has the fringe benefit of making you look like a total-rock-star. The problem here is starting with what you know well will cause your design to change as you learn about those things you don’t know so well. This can land you in an endless cycle of re-design/re-implementation that could not only tarnish your rock-star image, but might leave your team (even if it’s a team of one) doing twice the work. I know, right? Yikes, indeed. To make sure we avoid anything like that let’s cover our 3rd Analysis Superpower:

Analysis Superpower 003: Building a tower of things you should be worried about!

At least it doesn't seem like a good idea...

So, when you see buildings go up in real life – you generally don’t see the construction crew start at the top of the tower and work their way down, I mean, it’s just not done (at least I don’t think it is). In fact, if your building doesn’t have a foundation, or you realize you need to add one later you’re more/less screwed. Which makes foundations one thing you definitely want to think about when you’re building something. Software works the same way – except figuring out just what that foundation should be is occasionally harder than you would think.

One great way to figure out what a foundation should be is to evaluate each system and determine how much risk it poses to the rest of the application. We do this using a little Risk Analysis – which is the process of determining what your foundation is, and which systems build upon it. Good risk analysis can help define interfaces between systems that are much less likely to break over time, and interfaces that don’t break means well encapsulated code that doesn’t need to be re-factored every time a behavior changes.

Have you ever worked on a project with some jerk that breaks all your code because they realized their interface wasn’t going to do the job they wanted it to do? Did they do it multiple times during the process? There are few things I find to be a bigger waste of time than refactoring a ton of code because someone didn’t even try to think it through the first time around.

How not to do risk analysis:

For a project this small figuring this out is kind of a freebie; but it’s still an important part of OOAD. When I’m making a game my knee jerk reaction is to avoid the game engine component. Game engines are huge and require a lot of research and thought, which can seem a little overwhelming. I’ve written some before, and moreover we’re using Unity3d – so let’s see what happens if I just leave that until last and follow my “gut feelings” for what I should work on first:

The problem here is that if my impulsive decisions didn’t work out (and they wouldn’t, because I’m writing it this way on purpose) I’ll have to constantly change my design and rework code as parts about our software that weren’t well understood are exposed – which is a huge waste of everyones time (even if you’re just working by yourself). If you build off of a foundation of the riskiest, least understood systems this kind of refactoring should be kept to a minimum. Now, let’s take a look at a better way to select a foundation…

A better way to do risk analysis:

As you can see I’ve got my systems listed on the left side of the diagram, and my “Tower of things I should be worried about” on the right. Building a tower is a great way to double check your thinking, and it gets you thinking about the lower level relationships of the solution. In order to determine what goes where; each system is given points based on three separate categories, the more points a system has the closer to the foundation it should be. Here’s how the points break down:

• Understanding: Each system is given 1 to 3 poitns based on how well you understand the problem it’s going to solve. 1 point for a well understood system, 3 points for a complete unknown, and 2 points for somewhere in-between.
• Affected by: Each system gets one point for each arrow you can draw pointing away from it (this defines interaction with other systems, events, method calls, etc.).
• Affects others: Each system gets one point for each arrow pointing toward it (this indicates that changes in the interface to this system have the potential to negatively impact other systems).

So, when we total the points I gave each system (they’ll be a little different for everyone) we end up with the Game Engine system at the bottom. The one system I wanted to skip until the end looks like it could’ve caused me more headaches than any of the others. So even though this kind of step seems trivial, it’s always worthwhile to double check your thinking! The very worst thing that could happen is that you find out you were right all along (for me, this is rarely the case). I’ve added what we did today to our Woebot Chapter 1: Design Document, please feel free to review it.

So, that’s it for this post. Next time in Step 6: In which we write use cases that are more fun than a root canal we’ll cover our fourth (and most powerful) Analysis Superpower. Thanks for reading, and please leave and questions or comments you might have down below.

So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!

In our last post (Step 3: in which we discover that our feature list sucks) we employed the first of our Analysis Superpowers by checking our feature list against our use case diagram to see if we had anything missing (which we definitely did).  Now that we’ve got that problem solved, it’s time to learn a new Analysis Superpower!

Analysis Superpower 002: Magically transforming big software problems into smaller, more manageable ones!

So, now we have this big list of features and use cases; and we have some idea how they all relate to each other. At this point you might be wondering what to work on first. It’s important when making this decision that you choose parts that are well encapsulated, so your team (even if it’s just you) can work as independently as possible. You also always want to focus on the riskiest, least understood items before focusing on the ones you know well. There are essentially two steps involved in making this happen, the first of which is called System Analysis (we’ll cover the second one in the next article).

The totally kick ass world of System Analysis:

System Analysis is where you take your use cases and features and group them into logical categories or systems. For instance, the use case/features listed below were paired together during our last step:

(UC008): Application handles player and game status information.

(Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.

(Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.

From comparing and contrasting the relationships above we could categorize all three of these items under one system. A system name should describe the responsibility of that system as briefly and succinctly as possible, so we’ll call this one “Status Update System”. So, by putting that use case and it’s features under one name we’ve created a small, well encapsulated section of the project that can be worked on fairly independently. It also has the benefit of describing a few different behaviors with only a few words. This is going to come in very handy later when we talk about our third Analysis Superpower, but in the meantime let’s go through the rest of our features and use cases and see if we can fit them into categories too.

How not to do System Analysis:

In the diagram below I’ve laid out our use cases/features, and grouped them into multiple arrow boxes pointing to a system they might belong to. Obviously, since this is the “How not to” section, I’ve done something wrong.

If you create a system for each set of use cases and features you’re likely to end up with a lot of systems. The problem with breaking things up this way is that it doesn’t make the solution any easier to manage. Not only are there too many chunks, but they share a lot of common behavior, which doesn’t really make sense. Let’s look at a different way to lay these out…

A better way to do System Analysis:

What we need to do is combine some of the common elements from our previous diagram to create as few systems as possible, each carrying out a single major responsibility.

So, now everything is organized into logical chunks. More importantly we’ve identified parts of our software that can be encapsulated from other parts. In other words all any system needs to know about another system is what it does, and not how it gets done. For instance, the Game Engine system shouldn’t care whether character input comes from a mouse, joystick, keyboard, or some kind of monster AI – it should all work the same way. Likewise, the weapon system should be able to handle targeting, shooting, upgrades, and other weapon behavior regardless of what character fires a weapon (for instance, maybe there are bad guys who will use the same kind of weapon as the player). In addition, any classes in a system should be able to handle change without breaking code in the other systems (we’ll get to classes in another article).

You’ll also notice that I added two more use cases in this step that I hadn’t thought of before. Again, one of the most important parts of this process is that it helps you think through what your software is going to do. That way you don’t realize you have to make a bunch of changes once code is written. I’ve added what we did today to our Woebot Chapter 1: Design Document, please feel free to review it.

So, that’s it for this post! Now the project is separated into manageable chunks that should operate independently from each other. Next time in Step 5: In which we build of tower from things we should be worried about we’ll learn our third analysis super power! Thanks again for reading, and I’d love to hear any feedback you might have!

 

So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!

In our last post (Step 2: in which we figure out how our software is going to be used) we reviewed the importance of creating a good use case diagram to get a solid idea of how our software will be used. That information, when combined with a list of features will imbue us with only the first of our Analysis Superpowers!

Analysis Superpower 001: Figuring out what sucks and what doesn’t!

The first superpower we’re going to learn is figuring out whether there are features or use cases in our design that suck (there usually are). One way of doing this is to review each feature in our list and make sure it goes well with one or more of the use cases we just created. If we look at the feature and two use cases listed below, we can infer that some relationship exists between them (hint: they all deal with player interaction).

Feature:
(Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
Use Cases:
(Woebot-UC001): Player interacts with game engine
(Woebot-UC002): Player controls main character

If a feature can be connected with one or more use cases, we know it’s probably worth keeping around. If a feature or use case can’t be connected to anything you have, take a close look at it and make sure you want to keep it around (because it might be Atë, the spirit of crappy features manifest in your very design).

How do I know if my use case or feature is crappy?

So, how do you tell if a feature or use case is crappy? Here’s a handy check list:

• If it’s a feature and you can’t think of a use case that goes with it.
• If it’s a use case and you can’t think of a feature that goes with it.
• If you think it’s too low level to be a feature (see step 1 in this series).
• If it was written by someone who fancies themselves an expert but hasn’t actually written any software (see: The Dunning–Kruger effect).
• If it makes use of words like “synergistic”, “monetize”, or “performant”.
• If it was written by a woman named Medusa and involves a phrase like “Kitten-Cam”.

If at this point you’re thinking, “Oh snap-a-dap, that’s totally like one of my features!” then it might be time to kick that feature (or use case) to the curb. However if you still feel like what you have makes sense; then something is missing from your design. If you’ve got a stray feature – make sure to create a use case to go along with it, if you’ve got a stray use case – you need a new feature.

Using our new Analysis Superpower on Woebot – Chapter 1:

So, now we’re ready to use our new found analysis superpower. I usually do this right on the UML diagram, but spreadsheets (or napkins) can be used here too. But, before we do anything else, let’s review our feature list from Step 1:

Features:

• (Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
• (Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
• (Woebot-F003): The game shall provide a choice of weapons to the player at the start of the game, which can be improved as the player collects power ups.
• (Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
• (Woebot-F005): The game shall contain narrative elements explaining the back story for the relationship between robot and human. (e.g. The robot civilization decided to sunder themselves from the humans over a thousand of years ago, and why that happened).
• (Woebot-F006): The game shall provide a simple narrative ending leaving the door open for sequels while providing clear completion to the goals of the game.

Looking at that feature list we’re able to draw some pretty clear relationships between it and our use cases. Here’s what I came up with:

What happens to a use case diagram when you think about things a bit:

So, that didn’t go so well – we obviously have some features and/or use cases missing. Though this part of the process almost never gets it right the first time through. That’s what’s so great about it, the process encourages you to think about all the problems to be solved, and how you’re going to solve them.

So, to make this work all we need to do is look at any feature or use case in red and decide whether or not we want to keep them. If they’re all keepers, then we’ve got to make room for them in our design (by adding features and use cases). Here’s what I decided to do, though this is a situation where’s there’s really no wrong answer:

A newer, better use case diagram:

As you can see I made some changes to the diagram. Not only did I fix the directions that the extension lines are supposed to be pointing (I’ve been doing this for ages and I still get that wrong) I also added a new use case and two new features! I also removed part of one of the features I had a problem with before (we can always add it in later on if we design our software well). Here are the changes we made to the feature list:

A newer, better list of features:

• (Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
• (Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
• (Woebot-F003): The game shall allow the player to collects power ups that will affect damage and output of the players weapon.
• (Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
• (Woebot-F005): The game shall contain narrative elements explaining the back story for the relationship between robot and human. (e.g. The robot civilization decided to sunder themselves from the humans over a thousand of years ago, and why that happened).
• (Woebot-F006): The game shall provide a simple narrative ending leaving the door open for sequels while providing clear completion to the goals of the game.
• (Woebot-F007): The game shall provide multiple types of enemies each with a common/unique UI to provide an interesting player experience.
• (Woebot-F008): The game shall provide an informative game ending screen detailing the success rate and improvement level since the last time the game was played.

This leaves us (finally) with a nice balanced set of features and use cases that we know we actually want in our software. Hopefully by this point we’ve started to flush out some parts of the program we hadn’t thought of before (e.g. displaying game status, and what we actually do with the game over screen). Now that we’ve got all that done we can add it to our Woebot Chapter 1: Design Document.

Now, we’re ready for the next big thing: Step 4: In which we transform big software problems into smaller, more manageable ones. Where we’ll take our use cases and features and organize them into logical systems (which can be worked on independently by different developers).

Unfortunately, that’s won’t be until next time. However, in the meantime I hope you enjoyed the post, and please let me know what you think!.

So, in case you haven’t visited before I’m writing a small game using a simple and very effective methodology. I’m also taking you, dear reader, along for the ride!

In our last post (Step 1: in which we figure out what our software is going to do) we reviewed the value of features in software development, and created a features list for our project. Features give us a good “birds eye view” of what our software is going to do.

The trouble with only knowing what your software is going to do is figuring out which one of a billion ways you’re actually going to make that happen. It’s easy to rush right in to code, which potentially (almost definitely) causes you to miss details that come back to bite you in the ass later. So, to help solve this we need a better understanding of the problem, which is hard to get if you’re only using big abstract ideas like features.

So, what we really need is to organize those features into smaller chunks that are easier to manage. One of the best ways to figure out what those chunks should be is by creating a list of possible use cases (stories detailing how users interact with the solution) which tell us how our software is going to be used. Once we know that, we can tie the use cases in with the features to break our software up into one or more sensible categories, or packages. I know that last sentence might not make much sense yet, but a lot of ninja training is pretty befuddling too, and ninjas-are-awesome, so but please bear with me. So, one of the most ninja-licious tools for figuring out how a system is going to be used is the use case diagram. Use case diagrams allow easy communication about the relationships between users and a solution. There are a lot of great tools for making them, but honestly you could draw it on a napkin and the results would be just as good (though slightly less professional looking).

The Use Case Diagram:

Use case diagrams are a common UML diagram showing the relationship between consumers of a solution (actors), and what those consumers actually do (use cases). For people who haven’t spent a lot of time with UML before, some explanation of the key elements you’ll see in the diagram is in order:

Concept:	Definition:
	This is a UML element representing the title of single use case.
	This is a UML element representing an actor/consumer of your solution (it doesn’t necessarily need to represent a human).
	This is a UML association line, and in use cases we can use it to denote a relationship between one element and another (e.g. An actor and a use case).
	This is a UML aggregation line, and in use case diagrams it can tell us that one use case always <<includes>> the functionality of another.
	This is a UML extension line, and in use case diagrams it can tell us that one use case optionally <<extends>> the functionality of another.
	This is a UML generalization line, and in use case diagrams it can tell us that one UML element represents generalized functionality of another. (e.g. a Wii Player and a XBox Player  can both be generalized as a Player)
	These are UML stereotypes, and in use case diagrams they can tell us a use case is written at a summary-goal level. This kind of use case is generally written to be accessible to non-technical readers.
	This is another UML stereotype, and in use case diagrams it can tell us that a use case is written at a user-goal level. This kind of use case focuses on the goals of the user and generally provide more user oriented detail than summary-goal use cases.
	These are UML stereotypes, and in use case diagrams they can tell us a use case is written at a sub-function level. This kind of use case focuses on more technical details and is generally most useful to the development team.

How not to make a use case diagram:

When people first start using use case diagrams it’s common to see them treated like an actual use case. While there is technically nothing wrong with writing use cases this way, that’s not what the diagram was created for. A bubble in a use case diagram is only supposed to convey the highest level of a use case, which enables us to see all our user interactions at a glance. If you really want a diagram to convey step-by-step information look up activity diagrams, but we won’t be using those here – in my experience a well written use case is a far more powerful design tool.

A better way to make a use case diagram:

Below you can see a use case diagram that is a little more well formed. The thing about this or any of the other steps we discuss is don’t get too hung up on making it perfect. All you need it to do is convey a clear idea about how the solution will be used, and if you don’t get it right the first time there will be plenty of opportunities to update it before you start coding. Software design is an iterative process of discovery – you will always find details you missed later on.

The Woebot use case diagram:

Now that we’re all on the same page with use case diagrams we can go ahead and make one for Woebot. I’m also going to include some of the UML stereotypes from the list of key elements above, though it’s perfectly acceptable to leave them out if you prefer.

Like most things in software development, everyone is going to bring their own style to the table, so don’t be surprised if you would have come up with a completely different set of use cases than what I have here. Now that we’ve got a general set of use cases we can add them to our Woebot Chapter 1: Design Document.

So, now that we know how our software is going to be used we can learn some Analysis Superpowers! Unfortunately that won’t be until
Step 3: In which we discover that our feature list sucks is written. In the meantime, I’d love to hear any feedback you have – Even if you think this article was a stupid waste of time (which it wasn’t, unless you don’t write software, in which case, maybe you need a hobby – I’ve heard writing software is a good one).

So, in case you haven’t visited before I’m writing some articles about a simple and very effective design methodology. This methodology is for writing great software, and consequently we’re going to be writing a game to make it more fun (there’s a lot more to game development than this, so don’t take it as best practices for writing games).

Today, we’re figuring out what our features will be. If you continually find yourself at odds with clients or end up with crazy marketing people who say one thing before you write a project and expect another when you’re done – a good set of features can make all the difference.

I’ve seen a lot of developers get burned by not figuring out what their software is supposed to do before they start writing code. In fact, thinking back – I’ve been one of those developers more times than I’d like to admit. If you get a reasonably big project, and you’re the type who starts coding right away – stop now, seriously – a little time spent on upstream activities can save you many-a-late-night in the long run. The biggest problem with the “Jump right in” philosophy (and there are many) is that it usually doesn’t involve effective communication between the developer and the person they’re writing software for (even if they’re the same person). So, how do we fix that? Well, making a list of features describing exactly what your software is going to do is a good place to start!

People usually get confused between features and requirements (especially marketing people), so it’s important to note that features and requirements are not-the-same-thing! Features are big picture items that help people visualize what software is supposed to do, requirements are all the small details that make up a feature. In other words, features let you talk to anyone about what you’re going to make before you make it, while requirements are really more for your technically savvy co-workers and stakeholders.

Here’s the wrong way to communicate about a feature:

Ok, obviously this is entirely too detailed to be a feature, and is really more like a bunch of requirements (we’ll get more in depth on requirements another day). As you might imagine, most people have an idea what a ninja is, but not everyone is going to know what a kursarigama is (a weapon consisting of sickle, chain, and a heavy iron weight, naturally). The point of a feature list is that it’s as descriptive as possible using as few words as possible (almost like a haiku… except different). That way, you can talk with other people (even your grandma) about what your software will do without them getting distracted by all the nitty gritty details.

Here’s a better way to talk about a feature:

This is much more like it – it allows people to get a good idea what might be happening without overwhelming them with information. A short, concise (and sometimes intentionally vague) feature is much easier for people to form a mental image of.

So, now that we’ve gone over what features are and why they’re good – let’s write some for the game! My goal is to create a horizontal platformer/shooter that can be played in five minutes. Let’s make a list of features, and maybe add a quick synopsis just for fun.

The Woebot feature list:

Project:

Woebot Chapter 1 – Ascent into the ridiculous world of the pretty much extinct humans

Synopsis:

Woebot is a short game about a small slightly depressed robot who has decided that the cure to his depression is to leave the underground home of his peers to live with humans on the surface. Unfortunately the road to the surface is full of peril, and the robots haven’t seen a human in over a thousand years!

Features:

• (Woebot-F001): The game shall allow the player to control a humanoid robot character in a single level of side-scrolling-platforming-shooter-style awesomeness.
• (Woebot-F002): The game shall provide a time based scoring system – the faster you finish the game, the higher your score.
• (Woebot-F003): The game shall provide a choice of weapons to the player at the start of the game, which can be improved as the player collects power ups.
• (Woebot-F004): The player shall posses a health meter which can be reduced by taking damage or increased by collecting health units.
• (Woebot-F005): The game shall contain narrative elements explaining the back story for the relationship between robot and human. (e.g. The robot civilization decided to sunder themselves from the humans over a thousand of years ago, and why that happened).
• (Woebot-F006): The game shall provide a simple narrative ending leaving the door open for sequels while providing clear completion to the goals of the game.

So, that’s my attempt at developing a set of features for the game. Now I can use this list to discuss the game with other stakeholders and improve our design from there. Remember that features shouldn’t be set in stone until you start to code, these will need to change as we go through the design process and realize some are missing, and others are just plain wrong.

I’ve added what we did here to our Woebot Chapter 1: Design Document, please feel free to review it. Next time we’re going to figure out how our software will be used in Step 2: In which we figure out how our software is going to be used (obviously). In the meantime, I’d love to hear feedback if you’ve got some!