Rough Sea Games

As promised, this blog will include some thoughts about development processes and their impact on teams and projects. Today I will write about scrum and extreme programming (XP) for distributed teams, because at the moment we are one of those teams.

Scrum is a well known and currently very popular agile project management process. XP is a technical process, for programmers, and is also an agile methodology. The basics of Scrum are summarized in this great video from Kent Schwaber. If you looking for a good overview on XP check the Codebetter.com blog. More info on Scrum and XP can be found at the Agile Alliance Website and Mike Cohen’s blog.
I know both processes quite well, read all the available books, and have had the great opportunity to build up a team using these agile approaches at full scale.  The team included some offsite workers, but that wasn’t too hard to organize.

To implement Scrum and/or XP in a team which does not share an office sounds almost impossible. Everything in agile methodologies relies on communication and transparency. A distributed team talking over e-mail/ICQ/wiki normally has difficulty communicating, and most team members have almost no idea what their colleagues are currently working on.

I will tell you what our team has done to improve communication, and why it is currently working like a charm.  I have to admit that all team members know each other and are quite experienced. All of them have used Scrum and XP methodologies before.  So the techniques described might not work for new teams which have never worked in an Agile way.

Step 1 – a wiki substitutes for the daily Scrum

We established a wiki as our major communication platform. WOW! That’s magic, isn’t it?
Well, the magic is not in the wiki itself, it’s in the motivation of its participants. If the team doesn’t update the wiki several times a day, it becomes absolutely useless.

Every day, I post the latest technical and business news, and all team members, including me, write an update on their current tasks.  We still write e-mails and chat over ICQ, but most important communication happens in the wiki. It contains our business plan, the product backlogs, the complete (and current!) game design, helpful FAQs, various artwork and brainstorming thoughts. We even track our work hours and expenses in the wiki.  We are still trying to improve our communication processes, but for now it’s working out quite well.

Step 2 – removed sprints, and introduced stories as mini sprints

We are currently working part time on our project, because we are still looking for an investor. People work in their free time on weekends, vacation days and so on.  At first we tried to fix sprint timelines to certain dates, but that didn’t work at all. Working in your free time with (arbitrary) deadline pressure is horrific and far too much stress for everybody, so we skipped it.

Instead, Rafael put together a backlog in which the core game mechanics are written down as stories with acceptance tests. Stories get estimated by the programmers — not in a planning game, unfortunately, but the estimations do work out, because the team is quite experienced. It is very important that the stories do not exceed 2.5 points (most of our stories have 0.5 to 1.5 points). One point is a perfect day, so you need 2.5 perfect days to complete a 2.5 point story. This might take up to 2 or 3 weeks, depending on the time available. So the size of the story is important because of motivation issues: completing work in a short time gives you a very good feeling.

Step 3 – sprint demos are done for each story

We have always a working build and our designer is able to update the svn repository whenever he wants to. After updating he just has to start FlashDevelop, press F5 and can play the game.  As soon as somebody moves the story to the “completed” section, Rafael checks the story directly in the current build and adds a comment if something has to change. If the change request is too big,  Rafael writes another story and adds it to the product backlog.  This works absolutely great so far; thanks go to Rafael for doing a fantastic job here!

Step 4 – established test driven development from the start

Fortunately there are some open source frameworks for Actionscript 3 which support test driven development. We are currently using one of them, which Manuel has improved a lot in the first weeks of the project.  Maybe Manuel can explain what he exactly did in some of his future blog posts.

We used TDD from the very first moment, and it proved to be a good decision, because it helps us to have very stable builds. Having a stable version of the game is a must for distributed teams, because it will highly affect the motivation and performance of the team.

To be continued…

So I guess that’s it for today. There is a lot more to say about this topic, so I will write part two in the upcoming week. I hope you enjoyed this post and are able get some valuable info out of it.

Cheers,
Matthias

Popularity: 6% [?]

Hail fellow well met!

My name is Jörg, and I am supposed to be the lead programmer of what will be the best browser game ever. Or at least the best we have ever done…

At the moment, Manuel would deserve that title much more than me, since I did not find much time to work on our game over the last weeks. But nonetheless I am as enthusiastic as all the others about this game and can’t wait to get going on it.

I have wanted to work in the games industry since I was a child, and I managed to get into it by around 2004. Since then I have learned that all that glitters is not gold. Like Rafael said in his post, the industry, particularly in Germany, suffers from a poor relationship between publishers and developers. Developers want to create games that rock – publishers want to make money.  So there is nearly no chance to create the game you’d like to when you are bound to a publisher.

This is why I started working as a freelancer about a year ago, hoping that I would find enough interesting projects to join. But the situation did not change at all. I worked for the same company as Matthias, Rafael, Manuel and Dirk, which was a nice and interesting experience. But after the company broke up, I started working again on titles that I would not even like to play for myself. That sucks…

With Rough Sea games, we want to change all that (at least for us…). At the moment, there are enough indie developers out there that show that it is possible to create thrilling, unique gaming experiences without millions and millions in budget and without digging up licenses that no one has ever heard of (and no one ever wants to hear of again).

So I hope that there are people out there who appreciate and value good games and who are also sick of the current industry tendency to emphasize graphics and splendour over clever and fun gameplay, fascinating story, and enthralling atmosphere, in order to conceal the weak game mechanics of their so-called “blockbusters”.

Alongside my regular job, I have always made freeware games so that I could work on something where I had a say in the design. The most popular is sort of a Turrican remake called “Hurrican” which was released one year ago.

More about me will follow in upcoming blog entries, since I feel this is already getting too long.

So up the irons and wish us all the best

Jörg

Popularity: 7% [?]

This blog is going to be tricky. What I’d like to write is detailed discussions of the design decisions that arise in the course of developing this game. Not only does that seem most likely to interest you, the readers we someday hope to have; it would also help me organize my thoughts and steal ideas gather inspiration from your comments. However, our game is a BIG SEEKRIT, so I’ll have to come up with some way to disguise it for blog purposes. Perhaps a simple substitution code in which “artichoke” means “ship” and “umbrella” means “laser cannon”¹….

And who am I? Well, I was lead programmer for a bunch of games that you haven’t heard of. Not because they were terrible, but because they were solidly mediocre. Any why would anyone play such a game, when sitting right next to it on the shelf is a similar but superior game for the same price?

Before I entered the game industry, I used to wonder why there were so many unremarkable games. Why would anyone propose such a game? Why would anyone spend years of their lives developing it?  Bad, I could understand: bad can happen through honest incompetence, or even a really creative, fresh idea that just doesn’t pan out. Bad can be noble. But average?

I concluded that people didn’t know in advance that their game was going to be merely ok. They must have been trying for “great” and run out of money, ideas, or talent. Then I joined the biz, and it turns out that it does sometimes happen that way. More frequent, though, are projects where almost everyone involved knows from the start that the result will be pap. So why are they made? Well, some publishers believe that also-rans bring reliable profits. Many Developers are just desperate for whatever project they can get, to avoid going bankrupt, and they live from the hope that someday, they’ll get the chance to work on something that they can be proud of.

Screw someday. I am sick of working on mediocre games, and that’s why I’m here today, working on this game with these people. I probably won’t get things right the first time — even talented, experienced designers can fail, and I’ve got nothing going for me but a big mouth so far — but I will not rest until this game is worth playing. Or until I discover that I just don’t have it in me, in which case I will sink into depressed obscurity (and hey! What better place to blog from?). Either way, it will be a ride.

Want to watch?

–Rafael

¹ There are no actual laser cannon in the game, although there may be umbrellas. (back)

Popularity: 9% [?]

There shall be Flash coders!

Hello there, my name is Manuel Ruelke. I’m responsible for large parts of the Flash coding (done in ActionScript 3) for our game.

Games have been a great passion of mine since early childhood. My parents bought an Amiga 500 for me when I was 11 and since then I’m hooked. I started developing my own games during my time at university. Together with a good friend of mine, I founded the hobby developer group “dalama” (www.dalama.de). In about four years we produced about a dozen freeware games. In 2005 we received the “German Developer Award” as “Best Newcomer”, which I always kinda like to brag about. *hehe*

After finishing university, I became a professional game programmer. Until today, I have been involved in a couple of j2me games, as well as console productions for NDS, PSP and Wii.

Besides programming, I enjoy composing music once in while. You can check out some of my music on my webpage at www.ruelke.net or on www.zak2.org (I am that Heimdall-guy).

Cheers, mates!

Manuel

Popularity: 4% [?]

When I am surfing, I often see websites that have big security leaks in the communication between Server and Client. I know to avoid this, and will describe it here.

The most common way for a web server and client to communication is through HTTP Variables. This means that values are stored in the URL (GET) or in the header of the request (POST).
I will give an example for a GET parameter: news.php?id=4. The GET variable “id” has the value 4. This is not a random example; I deliberately used one with the keyword ID.
Databases usually identify records through a number. If a new data record is added, the number is incremented.
If you change the value of the variable “id” to 3 or 2, the website will display the contents of the article with the id 3 or 2. Many websites are built in this way. This is a small security leak and not really dangerous. But think about a message system or a community where somebody can read the messages of another. This would be a really delicate issue. Luckily, it can be avoided in several ways.

Modifying the GET or POST data of an http request can also cause a issue called SQL injection. Hackers can concatenate your variable with an SQL query, executing the query when the request is sent. For example, they could change the GET parameter to “site.php?id=3; DROP DATABASE mydatabase”. Boing! Data is gone.

Here are some tips to avoid this problems:

1. Newer database systems support GUIDs (global unique identifiers). These are 128 bit keys, and hence “more unique” as an id. They can be generated simply by counting, beginning with 000000-000000-00000… . But the big size of the data type will increase the size of your database.
2. Create a user which only has read privileges. Web pages often only need to output data, not to modify it.
3. Have your code validate http vars before using them. Checking string or enum values will increase the source code size, so use a checksum for this. A lot of server side application languages support some kind of checksum function, like a MD5 hash. This works as follows: create a keyword, like “MM3banana13″. Now take your variables id, id2 and id3 and concatenate them with the keyword as prefix or suffix (note that the order is important). Use this string to generate the md5. The destination site receives the GET variables “id”,”id2″,”id3″ and “check” which includes the generated hash. The destination site now also concatenates the id’ s and the keyword in the same way. After that the destination site compares the generated and the received hash. If the data was modified the generated hash will differ. You can improve security by changing the keyword every day. This is a established method for communication with an e-payment service.
4. Use SSL connections for sensitive data. This will keep your data private and inaccessible to third parties.

I think these four things will help to keep a website secure (on the software side).

The basic idea is to expect data that you don’t expect.

Popularity: 4% [?]

Hello! I am a programmer from Augsburg (Germany). I have worked in the software industry since 1998. My knowledge includes several programming language like C#, C++, Visual Basic, and Delphi. I have a lot of experience in PHP, ASP, JS, CSS, HTML and several other web technologies. I also have experience in creating company websites, e-commerce/e-payment systems, Web security, handling huge data masses and optimizing databases.

Beside my job as C#/database programmer in a financial management company, I am very interested in computer games. Most of my free time was, is and will be invested in playing and creating computer games. I worked for one year in a game studio in Darmstadt, and learned a lot about game programming. I learned how to create well-though-out, consistent, reusable, secure and efficient code. Currently, I am developing a commercial casual game in my free time with a small team. We want to release it this year.

Popularity: 5% [?]

Hello! I’m an artist from Germany specialized in creating entertainment art. I’ve worked as a professional artist in the game biz since 1999. I do everything from concept art, character design, environment design, storyboards, illustrations, digital paintings, thumbnails, pixel art, and screen design, to 3D-modeling, -texturing and animation.

Some of the PC games I’ve worked on so far are “Lula3D”, “Far West” and “Railroad Pioneer”. Some of the over thirty mobile games I’ve worked on as a lead artist are “Ancient Ruins”, “Space Guerrillas”, “Pirates Ahoy”, “Townsmen 2″, “Townsmen 3″, “Townsmen Racing”, “Flitzer”, “Glory of the Roman Empire”, “Funky Monkey”, “My Model Train”… and many, many more.

I also work in comics on the side. I’m the artist and co-creator of the creator-owned science fiction comic “Alpha Bettie”, which is written by former IDW-editor Dan Taylor. I work for the US publisher Papercutz with editor Jim Salicrup on new “Tales from the Crypt” comics, and my current comic project is the mini-series “It came from beneath the sea… again!” for the “Ray Harryhausen Presents” line from Bluewater Productions Inc. This is the comic sequel to the classic monster movie “It came from beneath the sea!” from 1955.

I have done twelve covers for the German novel series MADDRAX-Das Volk der Tiefe for the publisher Bastei.

I also work as an author for various game- and art-related workshops for magazines like the 3D magazine “Creative Live” and the biggest German game developer magazine “Making Games“. For many years I taught a course at the University Of Applied Sciences in Wuerzburg on 3D modeling and animation.

In April 2007 I quit my job as a lead artist on mobile games to work full time as a freelance entertainment artist in comics, illustration and games.

You can find more about me and my projects at http://www.chrisnoeth.com

Now ‘Have Fun!’ and keep your eyes peeled for the first Rough Sea Games art, coming soon…

- Chris

Popularity: 4% [?]

Rough Sea Games is a newly founded browser games company located in Darmstadt (Germany) that is currently trying to raise VC money to develop its fantastic upcoming super secret hit title! Yihaaa!

I just want to introduce myself a little bit. My name is Matthias Schindler. I’ve been a professional game developer for about 15 years now and worked on more than 25 different published game titles on multiple platforms. I co-founded two games companies (producing mainly classic handheld and casual games), both of which still exist and which will hopefully continue to prosper in years to come.

In late 2006 I joined 10tacle, a company which has had a lot of bad press lately. I was the studio manager and technical director of the Darmstadt branch of 10tacle Mobile, the division responsible for handheld games production.  I will write another blog post on that really bad issue later on…

Anyway,  4 months ago, in May 2008, I decided to found a new company with some of the guys I worked with at 10tacle. These very nice and extremely skilled folk will introduce themselves on this blog very soon.

I was sure I did not want to make the same mistake as in my former companies: missing focus! Back then, we did games for any platform and any genre we could get. We refused to restrict ourselves to, say, bloody horse games or nice casual puzzle games only. How could we? We thought our employees would run away and we would go nuts developing those games for a lifetime. Later on I realized that this was a big mistake.

Keeping this in mind, we thought about new possibilites, checked out the current state of the market, and, after a few weeks of research, realized that the browser games business is the way we wanted to go.

We could focus on only one title and make it nice, really nice. Improve it over a long period so people will constantly get a better and more convenient gaming experience. And hopefully people would give some of their money for that really nice experience.  Out of this idea Rough Sea Games was born.

Popularity: 2% [?]

It will be a source of information for everybody who develops games, especially browser games. It might also be interesting for gamers who have an interest in how games are created.

All the employees of Rough Sea Games will post different kind of information about their work and their special skills. They will also write about successes and failures, and last but not least about themselves.

This blog will cover the following issues:

• Building a company and a team (peopleware)
• Business plans and investor presentations
• Online marketing (SEO, SEM, SMO, Guerrilla marketing etc.)
• Game design
• Art and illustration
• Flash and Ruby on Rails Development
• XP (Extreme Programming) and Scrum
• Server architecture, security and scaling
• Working with a distributed team

Popularity: 2% [?]