A Theory of Fun for Game Design by Raph Koster is not a new book, having been published in about 2005. However it’s still very relevant, and as the title suggests, puts forward a theory about what makes games….fun. Given that games are (often) meant to be fun and entertaining, understanding the concept of fun is important. It’s a very easy read, and I found it pretty interesting and educational.

The Art of Game Design : A Book of Lenses by Jesse Schell was first published in 2008. I can’t recommend this book highly enough! It covers a wide range of topics relating to game design, from developing the core experience, through story and character development, gameplay, business models, and much more. The “Book of Lenses” part is interesting too – each subject area contains one or more lenses, which are focus-giving questions that designers can ask themselves to help understand and improve their design. Picking a random example, The Lens of the Interest Curve asks questions about pacing and what captivates players of the game as the game progresses.

There are 100 lenses, so any game design can be tweaked, modified and improved in great detail by examining it through the lenses. There is a  companion publication, The Deck of Lenses, that has each lens and its questions in card form – very handy! There is a lot of material in this book, and I expect to be referring back to it a lot in the future as I explore new game ideas.

Both of these books would fit quite well in any game designers bookshelf.

Presently, it’s out in Europe and Oceania (meaning Australia and New Zealand basically). (A full list of countries can be found here)

If you’ve been looking for a easy-to-learn strategy game that can be played in short bursts, (or extended sessions if your in the mood!), maybe consider checking it out. (If you have Media Go installed, click here)

Oh, and here is a video I made for the miniS release last week:

Coolio.

L8r, Paul

A test that is often performed to find if a game is robust and stable is random button pushing. That means what is says – somebody just presses lots of buttons randomly to see if the game can handle it…or not. I decided to take this a set further and use code to simulate random button pressing.

Star Hammer Tactics uses an “input manager” class. This means that between the instructions that reads the state of the physical buttons and the code that performs the game logic, there is a class that transforms the raw button state data into “commands”. So, for example, instead of the code that manages missiles having to read the ‘square’ button to see if it’s being pressed, it checks with the input manager to see if the “fire missile” command has been issued. By using an input manager, it means that player input code is in one place, instead being being spread all across the game codebase. It also means that if there is a design change, and the assignment of buttons changes, there is one place to make changes.

I decided to use the fact that the input manager deals in commands to test the robustness of the game code. I (temporarily) disabled the code that interfaces with the physical buttons, and replaced it with code that randomly issued commands. When running the game like this, it obviously didn’t play like the game should – the actions that occurred were completely random. At the main menu, for example, the command to toggle music on or off might be issued many times per second, meaning that the music would repeatedly turn on and off. The advantage of getting the game to generate the command, instead of a human, is that the game can keep the virtual button-mashing up for hours at a time.

I was pretty pleased when the first time I ran the game in virtual button mashing mode, it didn’t crash, and after a full hour I eventually turned it off. Test passed.

Nothing fully replaces humans for testing, but with a bit of thought, it is possible to engineer solutions that take of lot of the manual labour out of testing, in turn leading to more stable and solid games.

I’m excited to announce that Star Hammer Tactics for PSP and PS3 will be available in Europe and Oceania from July 14th. That’s next week!

The complete list of countries is:

• Australia
• Austria
• Belgium
• Czech Republic
• Denmark
• Finland
• France
• Germany
• Greece
• Ireland
• Italy
• Luxembourg
• Netherlands
• New Zealand
• Norway
• Poland
• Russia
• Saudi Arabia
• South Africa
• Spain
• Sweden
• Switzerland
• United Arab Emirates
• United Kingdom.

Star Hammer Tactics will be available via the PlayStation Store, which can be accessed by anyone with a free PlayStation Network account from your PSP, PS3, or via Sony Media Go.

Cool!

]]> http://blacklabgames.com.au/blog/2010/07/star-hammer-tactics-for-psp-and-ps3-available-in-europe-and-oceania-from-july-14th/feed/ 6 http://blacklabgames.com.au/blog/2010/06/using-ai-to-find-bugs/ http://blacklabgames.com.au/blog/2010/06/using-ai-to-find-bugs/#comments Tue, 29 Jun 2010 02:16:35 +0000 Black Lab Games http://blacklabgames.com.au/blog/?p=332 I wanted to share a technique I recently used in developing Star Hammer Tactics to find crash bugs. (BTW, this post will probably be more interesting to developers, especially programmers.)

A few weeks ago, I thought the game was finished. All of the tasks on the task list were complete, and I’d tested the game extensively. I tried all sorts of crazy things to try and crash it, or make it misbehave, and it always worked just fine. Convinced that it was ready to release, I submitted the game to Sony for acceptance. A few days later, I get the acceptance testing report, and to my disappointment found that the game had failed. Apparently it was unstable and crashed a lot. What!?!?

Now, being a small company, I don’t have access to a huge QA department. Whilst I make every effort to ensure that my code is as robust as possible, I’m only human, and I guess a few bugs had crept in. I got some friends to try the game, and after quite a few rounds of combat, the game froze. Awesome!

The problem was that it took at least 30-45 minutes to find *one* instance of the game failing. Furthermore, there was no way at all to tell what might have caused the game code to freeze. I needed a way to test the game in such a way as to find problems more quickly. At this point, I remembered that earlier in development, I’d used two competing AI players to tune the gameplay and balance the power of the various types of ship. Hmmm, competing AI…

What I was able to do was configure the game to play itself, non-stop, for hours at a time. Doing this through the debugger meant that if a problem occurred, I’d know were the problem was, and would  have a better chance of finding the cause. The good news is that it didn’t take long to find a couple of bugs that only occurred in rare circumstances, but had caused the previously reported “instability”.

So, if you’re working on a game, consider a mode in which the game plays itself. It’s a great way to find bugs!

Since I’m working on PSP miniS lately, I’ve been keeping tabs on new releases via pspminis.com and the Sony PlayStation Blog. And one title that’s been getting some attention is Coconut Dodge.

In Coconut Dodge, you play as Clawrence, a treasure hungry crab. You collect falling treasure whilst dodging falling coconuts. It’s addictive, and a really easy game to learn to play which is something I think is underrated these days. I think the most awesome thing about Coconut Dodge though, is that after it was released the developers solicited feedback from players and then made changes and released a free update that addressed issues that player had. 360 degree feedback….excellent!

Coconut Dodge is good, simple fun, and worthwhile looking into if you’re a PSP or PS3 owner.

L8r, Paul

If you have an Xbox LIVE account in the United States, United Kingdom, Canada, France, Germany, Italy, Japan, Singapore, Spain or Sweden, you can download a trial (or buy the game!) right here.

Cool.

I really like the concept of strategy games. I like the idea of marshalling your resources, devising a plan, and crushing your opponents with your strategic brilliance. The problem I’ve found with most of the strategy-type games I’ve played over the years though, is complexity.

Complexity in a number of forms. Controls that take a while to learn, and even longer to master – whether it’s menus that are nested quite deeply to get to the command you want, or needing to learn a gazillion shortcut keys, or HUD’s that look like they belong in a stock trading system. Complexity in the form of dozens of unit types, with multiple upgrade paths, resulting in hundreds of combinations of unit types to choose from when deciding what to deploy and where.

Now, I’m not saying these things are bad or wrong. Just that I feel that perhaps not everybody wants that much complexity in a strategy game. Sure, a lot of people do want things to be as complex as possible. Fine. Great! You’re pretty well served by the existing games available, or in development.

I wanted to make something that had the feel of a strategy game, with a bit less complexity. Enter Star Hammer Tactics.

In Star Hammer Tactics, there are two sides : the humans of Novus and the alien Nautilids. Each side has a total of 4 units types – a small fighter, a larger fighter, a medium sized “warship” and a larger “destroyer” class vessel. A fleet is usually no more than 10 ships, meaning two things : battles are fairly short, and each ship is individually controlled by the player. Rather than giving “high level” orders (go here, guard this area, etc), you move each ship into position, fire a missiles at a specific enemy, attack a specific ships in close range combat, etc. Each ship has precisely two stats : Attack and Defense. Attack is the firepower of weapons, Defense the power of shields or hull strength.

So, the gameplay goal in summary :  Create a strategy game with enough variables to make  the experience interesting and compelling, whilst maintaining a  simplified control scheme  and a rule set that makes the game accessible to players that might not currently play strategy games.

I guess I’ll find out if I’ve succeeded soon enough.

L8r, Paul

So, what now? Well, testing and publishing.

I’ve come to realize over the last few years just how important the publishing part is. As a young plucky coder, I thought that developers did all of the work. We make the games. What else could there possible be to it? Step 1, Game idea. Step 2, Code, Step 3, Release game on unsuspecting public. Right?

Well, not quite.

Publishers in the games industry are generally seen as lumbering giants of organizations, corporate fat cats preying on developers and milking them for all they are worth. (Or at least that’s the view of many developers). Deals are done often in a skewed way that ensures that the publisher takes the least amount of risk, and seemly gets the greatest reward if a game is a hit. (This post I read last week was quite interesting!)

Whether this view is correct or true or fair, I’ve decided that for now at least, Black Lab Games will self-publish through digital distribution outlets. Services such as Xbox Live and the PlayStation Store are moderately accessible to smaller developers, compared with the various retail outlets on offer for boxed games.

Lately I’ve been getting Star Hammer Tactics ready for release on the PlayStation® Store – soon it will be available for anybody with a PlayStation Network account, and a PSP or a PS3. All games on the PS Store require an age rating. That means PEGI in Europe, and ESRB in the US, so I’ve been signing up Black Lab Games to these various organisations, and I’ll have to spend time submitting the game to get is age rated.

At the start of a project, when you’re designing game systems, code systems, presentations of the game etc, tasks like getting the game classified aren’t really on your mind. However such tasks are part of the broad ranging area of “publishing”, and without completing them, the game will never be played by anyone (other than the developers).

There is a lot more to be an independent game developer that just writing code and doing art!

Now, if you’ll excuse me, I’m off to plan an advertising campaign.

L8r, Paul

• Star Hammer Tactics for PSP/PS3 minis has been the main development focus of BLG over the last few weeks. It’s progressing really well. I have to say, working on the PSP is awesomely good fun! Kinda like old times, back in the ’90s when I was in my prime Most of a re-usable game “framework” has been developed, and most of the game is playable. I’m hopeful that it will be finished in a few weeks.
• Star Hammer Tactics for Xbox 360 is “complete”, minus some minor tweaks. It’s been to peer review (a process in which it’s reviewed for technical and content problems) a couple of times, but hasn’t passed yet. Generally the issues have been pretty obscure and minor, but still valid enough reasons not to release the game.  When the “minis” version is done, I’ll get back to fixing the handful of review  issues and putting it back into the review queue.
• Star Hammer. This project is currently on hold. As the project has developed, the scope and ideas for what I’d like to do with the game has increased a lot. I have a pretty clear vision for what I want the game to be, but I don’t have the resources at my disposal to make it at the moment. Rather than build and release something I’m not completely happy with, I’d rather hold off a bit and tackle it again when the time is right. The project is not cancelled, just “delayed until further notice”.

I don’t like committing to release timeframes, because as a lone developer it’s so easy to miss deadlines when things go wrong or change. It’s not like I can delegate work to somebody else on the team. That said, I’m hoping to have both versions of Star Hammer Tactics out in June. But that’s not a commitment, ok!. Then probably on to something without “Star” in the name for a while.

Oh, and I’ve also been working on a special project with a friend that I’ll probably be able to talk more about in a few months. Good times!

L8r! Paul