OOAD Exercise Step 5: In which we build of tower from things we should be worried about

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.

Poor risk analysis can leave your interfaces a bit like this...

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:

It won't crush you, you'll just have to do twice as much work this way...

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:

Before you ask yourself if anyone's dumb enough to organize their systems as I did in the "how not to" section, let me answer your question by saying, "Yes, yes I am".

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.

Posted in Software Design, Woebot Chapter 1 | 6 Comments

OOAD Exercise Step 4: In which we transform big software problems into smaller, more manageable ones

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!

Not really the best way to choose what use cases/features to start on first!


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 one or more systems seem to have common behavior then they can usually be combined.

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.

This level of abstraction is going to make the rest of our work a lot easier, you'll see...

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).

Encapsulation is good for all kinds of things, not just software development...

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!

 

Posted in Software Design, Woebot Chapter 1 | 12 Comments

OOAD Exercise Step 3: In which we discover that our feature list sucks

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).

Analysis Superpower 001: The best way to get rid of Atë (the spirit of crappy features)

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?

Recognizing bad design decisions isn't always this easy...

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.

You generally don't want a crappy feature like this to sneak into your game...

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:

Items in red mean that something about the feature and/or use case didn't quite match up!

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:

You only need a design that's "Good Enough" shooting for perfect in software design is usually just a waste of time.

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!.

Posted in Software Design, Woebot Chapter 1 | 10 Comments

OOAD Exercise Step 2: In which we figure out how our software is going to be used

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.

They're that good, seriously

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).

While you can do your design work on napkins, your boss may not actually be all that thrilled...

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.

How not to make a use case diagram

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.

A better way to make a use case diagram

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.

The use case diagram for Woebot: Chapter 1

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).

Posted in Software Design, Woebot Chapter 1 | 10 Comments

OOAD Exercise Step 1: In which we figure out what our software is going to do… (or, How to write a Feature)

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.

This guy needs some features

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!

You two could’ve discussed a feature list *before* you turned her to stone…

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:

No amount of alcohol is going to make what you’re saying sound less complicated…

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:

There’s no hope for Grammy – she’s in sales, but that feature was well written…

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!

Posted in Software Design, Woebot Chapter 1 | 3 Comments

Sometimes things just don’t work out…

Ok, so, we (and I really mean me) made every mistake possible up until now. Choosing Nintendo as our target platform was just a silly idea that we put a lot more behind than we should have (it seemed to make sense at the time), and now when I work on the project I just can’t seem to muster the strength to complete the Windows port – Especially when I look at the support costs vs. earning potential on a platform like Steam vs. WiiWare. In addition to that, I no longer have Saturdays to focus on the project – and have recently started an awesome new job (I need to rewrite my Bio!). So, for now – life is busy and we’re going to have to shelve it.

How I'm feeling about my project right now...

In that vein, I need to talk to my other team members and find out if we want to do anything with the code / assets. Maybe we can make this open source, which should at least help others learn about homebrew development on the Wii. *sigh* It sucks to fail but it’s a great learning experience.

In the meantime, while we’re on hiatus from the currently-stillborn “Swim Fishy Swim” I thought I might write a few articles about some of the best ways to approach game development from an architectural perspective. Truth be told, I’ve learned good game design takes a lot more experience than I thought, so I won’t try to tackle any of the benefits of prototyping and level design here. However, what I thought might be a good exercise is to make a game that can be played from start to end in five minutes, and take any aspiring developers who want to go along for the ride through what I feel is the most effective software design life cycle for small to medium projects. Hopefully through this process I can improve my skills as a game designer too – that’ll make it a win-win for everyone involved :D.

What’s a software design life cycle, you say? It’s a methodology, that helps get rid of bugs/design flaws before you write even one tiny single little line of code (and a lot more fun than you would think)! If you haven’t been exposed to this kind of idea before, it might seem a little counter intuitive – but stick with me, a tool like this can have a huge impact on your life as a software developer! (I know it changed mine)

We’ll be using Unity for this adventure, something I wish I’d known about when I started Swim Fishy, and I’ll be uploading design documents as we go. I’m only giving myself thirty minutes a day (a small lunch break) to work on this, so it’ll be slow going (but hopefully not as slow as it has been, so take heart dear reader (if you exist))!

So, that’s my current plan to not-abandon green door games in the wake of our first big failure – I hope one or two of you people out in the world come along for the journey.

Posted in News | Leave a comment

Porting just got more fun… actually, it hasn’t been much fun…

Well, it’s been quite some time since we were able to give an update to the project, so here it goes!

Finally got our engine working in Windows :)

It took a lot of effort and some lengthy moments of pure confusion porting our engine over to Windows. I was surprised to see that Microsoft didn’t support the C90 standard (realizing that kind of sucked), and had to spend a few of my Saturdays banging my head against the wall in confusion as I got used to switching from a left handed coordinate system to a right handed coordinate system (or is that the other way around?). Either way, we’ve finally got the rendering engine working in OpenGL. Bump and Normal mapping isn’t implemented yet, but I think we’ll wait for the polish phase to get that done.

We did get our official rejection letter from Nintendo early this month, and it was hard not to just give up on the project. I’d just like to say thank you to everyone who offered us kind words and encouragement – it was really appreciated, and helped us muscle through the retardedness of porting to a different platform. Personally, I’m finally starting to get excited about the project again, and I’m looking forward to being able to send out demos, and get some real feedback. Hopefully in the next few months, that will be a reality for us :). Or not…

Posted in News, Swim Fishy Swim | Leave a comment

On being a noob Indie Developer

It’s kind of frustrating going from consummate professional in business to total noob in indie gaming. We got our rejection letter from the indie fund last month, and I have to say it was a bit of a bummer. We should have expected it, this was never a conceptual title, but I just had a fantasy that things would go a little like this:

Eagans fantasy-land expectations

After several weeks of checking youtube every 30 minutes to see if someone, anyone on the west coast looked at our project, the reality of being a noobie finally hit:

What reality more/less looks like

I have to admit – this part of the experience is, well… sucky. I imagined the indie community as a utopia of programmers and designers joining together to make great and affordable games. If one was misdirected we could band together and give them some sage advice to help them along the road. That’s what the indie fund is doing really, and they can’t do it for everyone. It occurred to me what kind of draw indie development must be for all of the geeks in the world. The indie teams probably have to sort out the geeks who don’t know anything about programming, or game design, from the ones who do and I imagine the difference isn’t always obvious!

It’s kind of like when you’ve got a stack of resumes to go through, and after a while you start throwing out candidates arbitrarily because it’s just not humanly possible to give each of them the time they would need. “What? A misspelled word? *Discard Pile*” “Improper verb conjugation? *Noooo thank you.*” A person (even one you admire) can only stretch themselves so thin – why didn’t I realize that?

Of course this gave me a lot of pause… Wow – are we totally clueless indie fanboys sucking the life out of real developers!? We might have seemed that way. I didn’t really expect praise so much, as I was looking for someone to say “No thanks, but nice effort. Have you thought about changing this or that?” I expect my emails with questions looked like this: “YOU CANZ LOOKZ AT MY GAMEZ?! PEEEZ?!” There’s so much to learn as a noob in this industry… So, what do we do? Should we just give up? Do we even finish our game if no one is going to look at it? O.o

After I finally stopped moping around the office (that we may not have needed to rent) saying “I’ve made a huge mistake…” (half for entertainment, half because I felt that way) – I realized that starting anything new is never going to be easy. For whatever reason we all have to do a certain amount of walking into walls before we figure out where the doors actually are. If that wasn’t the case, everyone would be doing this. So, after a short stint of the blues we decided to take what we learned and apply it in any way we can to make the game better. We’ve been reviewing our design in detail, and finding out what parts we can make more fun. We’re getting close to the point where we’re going to implement those changes and hit the final stretch – the game will finally be done, and getting rejected has actually made our title a little more worthy of a first serious offering.

That may mean accepting that the people we’d hoped would be interested in us just aren’t right now. There’s other platforms we can use, even if it isn’t what we’d been hoping for. That’s what life does with your plans, and I think if you keep looking for openings and ways to make them work – you’ll eventually get where you wanted to go.

Posted in News, Swim Fishy Swim | 2 Comments

Two years down, one big milestone, and a little time…

The Texture of the Bumblefish

The Texture of the Bumblefish

Two years. That’s a lot of effort for almost any project. Not just from the development team, but from our families. Every weekend and major holiday has been filled with game design, software design, reading hardware documentation, patents, engine programming, game play tweaking, texture mapping, model animating, controller waggling, button mashing, sound effect generating, music composing, and lots of other hard/fun stuff. That doesn’t even include all the work it took setting up a business!

Well, all of that effort really culminates into one major milestone for our team: The submission to Nintendo of America for official developer status… and we just sent in our documentation!

Unfortunately, it looks like a long process to complete (hello reality, nice to see you again). Since everyone else who already did this signed a NDA, we don’t really know what to expect. What if Nintendo doesn’t like us? What if they look at us, scoff, and mumble “N00bs” before throwing us in the discard pile? What if they don’t like goldfish? What if they don’t like Pickles?! *GASP* … that’s really too horrible to imagine!

Anyway, the multitude of horrifying and pickle-less possibilities are endless, true, but so are the awesome ones. Those are the ones we’ve been banking on this whole time, and I’ve just got a feeling that we’re going to love these guys/gals at Nintendo. If we’re lucky, we’ve done our homework right, and they’ll love us too.

Posted in News, Swim Fishy Swim | Leave a comment

Waiting with bated breath…

On August 8th, 2010 we officially submitted the storyboards and game-play for our upcoming title “Swim Fishy Swim” to the Indie-Fund. Although youtube insight only updates once a day, I can’t help refreshing the page at least three times an hour. I can’t tell if anyone’s looked at it, but we did get one hit from Arizona (so I hope that’s Flashbang Studios) and one hit from Japan.

‘Having read nearly all the blog entries on the most excellent 2D Boy website, I know that one of them went to Japan once… for like 2 months… in 2008… So, I’ve decided to pretend they’re looking at it, too (it was probably the search for “Swim Game, Adult”). Sadly, no hits from California yet.

I am left to wonder, with 70 submissions already – does the indie fund have a wellspring of totally awesome, creative projects to choose from? Will gDg get lost in a sea of brilliant designers and engineers who’ve all been footing the same rocky cliff that we have? One part of me says, “I hope so! Imagine the impact of all those new ideas!”, but after two years of weekends putting swim fishy together, I was harboring a fantasy that they’d be impressed, or at least, pleasantly surprised with our work.

On that thought, wouldn’t it be nice if everyone submitting had a forum where we could all commiserate, share, and compare?

Well, we’ll see what they say – and if you’re in the mood – knock on some wood or keep your fingers crossed for us! (We can’t, we have to keeping hitting F5 on the insight page)

Posted in News, Swim Fishy Swim | 2 Comments