Rough Sea Games

Today I have some great news.

In December 2008 our team was able to sign a very promising deal with Gameforge and founded Rough Sea Games GmbH! The details are published in an official press release, which you can read here.

I want to thank the whole team for the great work they did in the last year. It is absolutely awesome to be a part of such a great bunch of people.

Sure, most of the work still has to be done, but from our point of view, we are expecting a very bright future. We were able to defy the psychology of the economic crisis, which gives us additional confidence and self-assurance.

So, watch out for more news on our upcoming games.

Popularity: 5% [?]

While cleaning my hard drive I discovered a comic strip I did some years ago. Because it is game related I don’t want to withhold it. Just click on the title image or ‘HERE.’ to read it.

… and who knows… maybe there is someone out there…

… who thinks the joke is funny

Chris

Popularity: 9% [?]

In game development, state machines are the most common way to structure the behavior of code.  Wikipedia defines a state machine as :

A state machine is a model of behavior composed of a finite number of states, transitions between those states, and actions.

Probably every game programmer has worked with or even created a state machine that turned into debugging mayhem. The road there is short and simple: Game programmers usually do not bother with planning a state machine carefully before starting to code. They usually just create an object, add the obviously needed states and add more states and functionality as needed over time. After a while, the code is full of “set state” calls mingling the states and creating a most complex structure, whose behaviour becomes almost impossible to predict.

We believe in the DRY principle propagated in the book “The Pragmatic Programmer” by Andrew Hunt and David Thomas. DRY is short for “Don’t Repeat Yourself”.  It simply means that duplication of information should be avoided. Creating a state-machine diagram and an implementation is an duplication of information already.

How can the DRY principle be applied to state machines?

Our answer is: Include the state-machine diagram in the code! Using such an in-code diagram makes it really easy to understand how an object works and how states are connected. This transparency is gained by triggering the state changes through observing changes in the internal data rather than using external stimuli. To make this possible we completely eliminated the use of the “set state” method (except for setting the initial state of an object).

Let’s get practical: We declare our state-machines in the constructor of our objects. First, we define all the needed states. States consist of a state method (reference to a member function) and a state id (constant integer value). Each state can have an arbitrary number of transitions. Each transition contains a reference to a transition-trigger method and a target-state id.  (A transition trigger returns true if a state-change condition is fulfilled, false if not.)

 1 // set up state- machine diagram
 2 m_sm = new cStatemachine(NUMBER_OF_STATES);
 3
 4 m_sm.AddState(ST_ANCHORING, StateAnchoring);
 5 m_sm.AddTransition(ST_ANCHORING, IsAnchorUp, ST_FLOATING);
 6
 7 m_sm.AddState(ST_FLOATING, StateFloating);
 8 m_sm.AddTransition(ST_FLOATING, IsSailOut, ST_SAILING);
 9 m_sm.AddTransition(ST_FLOATING, IsAnchorDown, ST_ANCHORING);
10
11 m_sm.AddState(ST_SAILING, StateSailing);
12 m_sm.AddTransition(ST_FLOATING, IsSailIn, ST_FLOATING);
13
14 // set initial state
15 m_statemachine.SetState(STATE_ANCHORING);

Let’s have a closer look at the example (Look here for a more extensive version): There you see the state machine of the object “Boat”. It starts in the state “STATE_ANCHORING” (line 15). As soon as the method “IsAnchorUp()” returns true, the corresponding transition kicks in and it changes the state to “STATE_FLOATING” (line 5). If the sailors should decide to lower the anchor again, the second transition of the floating state will cause the boat to return into “STATE_ANCHORING” (line 9) again. You are now surely able to easily understand what the other states do and how they interact.

Besides all the good things this approach brings into your project, it also has its downside: It is simply a bit of more work. The programmer has to think about the design of the state machine constantly while programming. It only works if you design your states well. In addition, a little bit more code is needed to implement a particular functionality, too.

Still, the benefits you can gain from this methodology are well worth it. This especially applies to a distributed multi-programmer environment like ours where you need to understand other people’s code fast.
Happy coding!

Popularity: 7% [?]

Almost all computer games with “role-playing elements”¹ force the player to spend a lot of time on boring, non-challenging, repetitive tasks. These tasks, called grind, translate play time into in-game power. Often, they are disguised as something vaguely heroic — killing ten orcs, for example — but sometimes, especially in online multiplayer games, designers seem determined to rub new players’ faces in the fact that they are worthless nothings by sending them off to collect ten balls of lint instead. In either case, the question is “why deliberately include grind?”

The advantages for the game developers are clear:

1. Grind slows content consumption.  You can have a pretty small world and still write “50 hours of excitement”  on the package if the player has to spend ten hours in each new region walking back and forth between the lint orchards and the marketplace.²

2. In an online game whose income is based on advertising or monthly subscriptions, grind ties player success to developer income. The more powerful a player wants to become, the longer she must play — and hence, the more money she generates for the developers.

Why do the players accept this?

For one thing, grind often comes packaged in fancy visuals and perhaps a new world to explore, so it doesn’t feel like work until the novely wears off. But there’s more to it:

3. Steady progress is seductive. In real life, achievement involves hard work and often risk. Computer games offer an easy sense of accomplishment; their challenges are designed to be overcome. Grind distills this:  if you put in the time, you are guaranteed the reward, which is the way we’re taught as children that life is supposed to work.

4. Competition motivates. If there’s a chart somewhere that says that I’m better than you, I get a satisfying feeling of superiority, even if the chart only measures our respective willingness to have our time wasted.

5. People will put up with a lot of crap to feel cool. Games with grind are often designed so that increasing power means prettier equipment, fancier special effects, etc. This also explains the humiliating newbie lint-quests: increasing the coolness gap between new and experienced players increases the incentive to level up.

So grind is tempting… but it has dangers:

• Grind at the beginning of a game, before a player becomes hooked, can cause her to stop playing before “getting to the good stuff”. And if there is no “good stuff”, those who do stick it out will be very disappointed.
• Grind consumes bandwidth and server resources for online games, and these cost money, so it actually reduces profits for games with a flat monthly fee.
• Grind plagues the game designer’s conscience — or should.

Is it possible to get the good parts of grind without the bad?

I’m not sure, but I’m doing my best in our game. My approach is two-pronged:

a) Grind is optional. Our game can be played, even at a high level, in a few minutes a day. However, to satisfy those who crave grind, or who simply would like to invest more of their time, there will be special, grind-based tasks and rankings that interact only weakly with the core gameplay

b) Grind isn’t too boring. I don’t think it’s possible to make grind really interesting, because interest arises either through challenge (which would void benefit 3) or appealing content (which contradicts 1). Still, there’s a world of difference between an entertaining mini-game and just clicking a button repeatedly.

I don’t want to bore my players unless they insist. Time will tell if I can avoid it.

---

¹  Unfortunately, “role-playing” in the context of computer games just means “you have a game token or tokens that becomes more powerful the longer it is used”. (back)

² And if you’re willing to  lie about the “excitement” part. (back)

Popularity: 7% [?]

Take a look at the following image…

… and tell us which square is the dark one… square A or square B?
Easy isn’t it!? … and to show you your answer is the right one click
HERE!.

Chris

Popularity: 3% [?]

Over the last several years I have managed and participated in different projects of different sizes. I made a lot of mistakes, some of them more than once. This time I want to talk about mistakes in estimating the time to complete tasks.

Estimating tasks is really tough work, and it’s done wrong most of the time. Estimations are never precise. I think that most project managers are aware of this problem, but may not know how to get better information out of their team.

Mistake 1:

The task is estimated by somebody who is not working on it — maybe by the lead, which is even worse.

Solution:
Tasks should be estimated by the owner of the task with the help of his colleagues or his lead. Programmers especially have different working speeds, which can be ranked from 1-10.  This means a very good programmer can be 10 times faster than a very bad one.

Mistake 2:

The task has no proper description and/or is unclear to its owner.

Solution:
How do you know if the task has a proper description? Well, it’s a mixture of common sense and experience. If you, as a project manager, do not understand the task (e.g. it’s too technical), it might be already a very good hint. Tasks should be described non-technically, understandably and in only a few sentences. If you prefer working with user stories I would recommend to you this book from Mike Cohen.

Mistake 3:

The task is estimated with worst case and best case scenarios and the average is taken for the project plan.

Solution:
This doesn’t make sense because the owner has to make 2 estimations. In the worst case scenario there is probably a hidden buffer time, which is not obvious to the reader when checking the project plan. Ask only for one estimation from the owner or the team when estimating the tasks.  It’s much clearer to them and they know you will add the buffer.

Mistake 4:

The task is too big and cannot properly estimated by its owner (tasks with 8- 16 hours are a maximum)

Solution:
As soon as a task is bigger than 2 days, it is time to break it down, because nobody can foresee the problems that are going to arise when approaching such a big issue. If you are not able to break down the task (e.g. because of a missing design),  but you need the information desperately, you should estimate it and add at least a 100% buffer. Don’t forget to mark that task with “??”, to be sure to break it down later and re-estimate it.

Mistake 5:

The task has dependencies on other tasks that are not clear to its owner.

Solution:
This is not an easy problem. Try to make tasks as independent as possible when defining them. If you work with user stories, add the dependencies of the task to your war-room board and check if your priorities match the dependencies.  It is really hard work for the designer and project manager to get this right. Communicate as much as possible with the team to avoid dependency hell early: it can vaporize your whole project plan if you do not care about it.

Mistake 6:

The owner puts some unknown buffer time into his estimation

Solution:
Again you need your soft skills and experience here to identify this problem. Some people just add buffer times to be sure they can handle the task. Be open with them, tell them that you will add enough buffer time, holiday and sickness absence.  They will only tell you the right time if they trust you. Collect all the estimation data of each owner to get an idea of how well they estimate over the whole project.

I have some more mistakes on my list, but It is late already. So stay tuned for more in the upcoming days. Cheers for reading and I would love to hear your experiences…

Popularity: 10% [?]

Hello, welcome back and a happy new year to all readers from me as well!

Today, we are going to shed some light on our unit-testing process. It is one of our vital safety parts to ensure that our development process is still on track and that we are not breaking anything.

Before we started the project, I did some research on unit testing with AS3 on the web. I stumbled upon AsUnit at http://www.asunit.org by Luke Bayes and Ali Mills. I integrated their framework into our newly set-up project and we were able to start coding right away. Just now I realized that the  tutorial to set up AsUnit with FlashDevelop disappeared from the web. So, I decided to quickly assemble a new tutorial. You can find it at my web page http://www.ruelke.net.

When we started using it in real-life, we discovered a few minor issues. Consequently, I added and changed a couple of things over time, which transformed AsUnit into our very own version.

1. Process: Run tests first: if one fails do not start project code
2. Extension: Our Asserts can be checked
3. Extension: Controlling the debug output

Ok, let’s explore these things a little further:

1. Run Tests First: If One Fails Do Not Start Project Code

Out of the box, AsUnit just doesn’t do anything after it has finished the tests. We all are regular game programmers that have used C++ before. So our unit-testing experience revolves around UnitTest++. I tried to get AsUnit to behave as similarly as possible. Accordingly, AsUnit needs to do the following:
- Start and Run the tests
- Check the result
- Continue with the game code if everything was correct

To do this, I extended the TestRunner-constructor with another parameter: a function pointer (callback). The callback is called within the TestRunner’s testCompleteHandler-function if the unit tests passed successfully. Then the callback takes care of continuing with the game — starting the game loop, loading assets and so on.

2. Our Asserts Can Be Checked

It is important to integrate our assert-handling into the testing process. You may remember my posts about assert-handling a while back (http://blog.rough-sea.com/category/methodology/). It is possible to use our debug class’ HasAsserts()-method, which returns true if an assertion failed, to check if an assertion actually fails as expected in a test case. The AsUnit framework has a class called Assert, which contains all checking methods used in the tests. By using what’s already there (like the assertTrue method), I could realize the check for assertions in a very simple way :

/**
 * Asserts assertions.
 * Usage: assertError(m_object.ErroneousMethod())
 * If assertion does not fail an AssertionFailedError is thrown
 * with the given message.
 */
static public function assertError(...args:Array):void
{
    assertTrue("Assertion failed to fail!", Debug.HasAsserts());
    // clear the asserts so there is
    // no interference with other tests
    Debug.ClearAsserts();
}

3. Controlling The Debug Output

A lot of our classes, especially the state machines, contain automated debug output. When running our tests, this debug output is overwhelming … and useless as well. All of the console output goes through our Debug class. So I added a flag that is able to disable the sending of messages to the console. This flag is activated right before the tests and deactivated right after. The spam was history.

Alrighty, these are the three most important changes I did to the AsUnit framework to make it suit our needs. Well, you have reached the end of my little trilogy. Don’t worry, I still have stuff to talk about.
So see you next time and happy coding!

Popularity: 13% [?]

Hello ,

today I am going to write about server security. I decided to split the post into 3 parts. The future parts will be published during the next weeks.

Part 1 deals with server security in general and the conception of your personal strategy to avoid security problems.

Security has become more and more important in the last 10 years , as the numbers of internet users and server services are growing year by year. Especially the web 2.0 revolution brings new security problems. Nowadays users with a bad understanding of the technical background are setting up blogs, forums, websites and other services.

Therefore I wrote a small introduction for those newcomers!

In general there are 3 main areas you have to keep an eye on.

1. Network infrastructure:

I will not deal with this, because usually only professionals can influence the network infrastructure or your provider does this for you with routing , firewalls and filters.

2. Operating System:

A big part of security solutions and problems rely on the chosen operating system. All common operating systems (e.g. Linux, Windows, Unix) have advantages and disadvantages. If you expect me to write down which is the best one, I WILL NOT ! Nobody can tell you. It depends on so many factors like the services you want to run, your personal knownledge about the operating system, etc… . Maybe you do not even have the chance to choose your OS as your provider pre installed already one for you.

Unfortunately, I will have to focus on one operating system in the second part of my post. In my point of view the most common one is Linux. Although I am aware of the fact that other operating systems are great. So do not bug me with comments like: “You hate Windows ! Why not using FreeBSD ?  Solaris is the best one !”

3. Applications & Daemons

Daemons or services are the core of your security solutions and also the source of most security issues. Before offering several services, e.g. a Web-Server , Ftp-Server or an Email-Server, think about which services you really need and if it is really smart to offer all services on a single machine. Every application can be corrupted or compromised. Avoiding services and daemons is always a clever strategy to minimize the risks. Moreover security tools hinder security issues as well, for example virus scanner, firewall, spam filter, a handy user rights management, etc… .

Please think about all these facts before you run a public server.

The second part will be about the practical parts of server management to build a secure server. We are going to leave the boring theory, promised!

Popularity: 6% [?]

Our blog started a few month ago and the feedback is already very good. I want to thank all our guest bloggers, readers and friends for their great support. I hope you had a good start into 2009. We had a very good time in the last year and there is much more good stuff to come.

We will continue and intense our blogging activities in the month ahead. So stay tuned for more helpful browser game articles and news about our upcoming game.

All the best from the Rough Sea Games Team
Chris, Joerg, Manuel, Matthias, Rafael and Ole

Popularity: 4% [?]