Rough Sea Games

What kind of people are gamers? First, a clarification: I’m only going to talk about electronic games, because if you include all games, practically everyone is history has been a gamer: think of Chinese ladies playing Mahjong, English seamen playing whist, renaissance nobles playing tennis and commoners playing football. Ok, we had a brief period between the seventies and the turn of the millenium during which people watched TV instead, but thankfully they’re back to playing online poker and Zuma now.

So who are gamers? The answer has changed several times in the past few decades: in the very beginning, gaming was the friendly face of Science; then it became the province of übergeeks — but even they sometimes tried to make games for their children. Sharp businessmen brought games from the university into the bar — which makes sense, because an arcade game is like a pinball machine, which is itself like a pool table or dart board with more blinking lights. For a while, normal, hard-working adult women and men became “gamers”, although they wouldn’t have identified themselves as such any more than someone who takes in a movie now and again calls herself a “moviegoer”.

By the 80s, the machines had moved to arcades where they didn’t sell beer, and hence become kid stuff. Early game consoles, also for kids, arose simultaneously. The kids involved were viewed, by the adult world, with a mixture of fear and awe, but actually they were pretty normal for their age. The 90s made gaming geeky again: healthy, well balanced kids were outside playing [nationally accepted sport] while the pasty nerds were shooting down Kilrathi. Nowadays, gaming is steaming towards the mainstream again: pretty much all boys under 20 game; more and more continue to play as adults; and a new generation of gamer girls is growing up.

So is this a pendulum? I don’t think so — I think electronic gaming is destined to be mainstream. The first “geek age” of gaming was caused by the fact that only geeks had access to hardware that could run games; players were also programmers. The second geek age arose because gaming became a solitary activity, which is nearly unprecedented, no longer true, and, I suspect, nothing but a fading blip in the history of games. But that’s a topic for another post!

Popularity: 2% [?]

Hi guys,

I am currently checking out some stuff for the server-side of our browser game. Right now, I am having a look at the so called SmartfoxServer (SFS in short), a “socket server for flash multi player games and applications”. Sounds interesting, so we decided to give it a try.
A good portion of the samples are written in ActionScript2 and only a few are in AS3 which makes it a bit difficult for me since we are using AS3, but fortunately I found these tutorials that deal with SFS and AS3. I already started reading them and I am going to continue this within the next few days.

I am still a bit in a struggle with some Flash and Flex SDK stuff, but here is what I can already say about the SFS:
- simple and clear server configuration using a config.xml file
- foolproof API: you can get started within minutes and there are event functions for every kind of stuff
- detailed documentation
- extending the protocol is very easy by writing your own socalled “server-extensions”
- zones and rooms are already implemented. These are necessary if you want to run multiple instances of your game on one server (zones) or if you want to split your gameworld into different locations (rooms)
- FREE trial version of the SFS pro! The only limitation is that only 20 users may connect. Enough to test it though.

As soon as I am done with the tutorials, I will try to encapsule one part of our demo and feed the game with content from the server instead of pre-generated local content.

I am not aware about the performance at the moment. You may have a look at the benchmark whitepaper or wait until we run performance tests on our own.

I will keep you up to date and tell you my opinion regarding the SFS while getting more into detail the next days.

Popularity: 12% [?]

Please check my last blog entry for the background to this post.

This time I will focus a little bit more on the XP side and explain what exactly we practise here.

Step 5 – regular pair programming sessions

Unfortunately, we are not able to pair program very often. We currently try to meet up once a week and have a 3 – 4 hour pair programming session. At this session we go through as much code as possible and talk about the architecture and the current design flaws. We try to get hold of the worst things we did while coding on our own, and start refactoring on the spot to learn a little bit more of each other’s code.

Sometimes pair programming is not possible because people live too far away, so we are looking into remote pair programming. We have not established it yet, but have collected lots of information. Please checkout Doug Alcorn’s Blog or Andrzej Krzywda’s Blog for some field reports.  We will probably try VNC combined with Skype, because Flash Develop (our current IDE) does not have any collaboration support yet.

Step 6 – collective code ownership is even more important

CCO means that everybody can make changes and fix bugs anywhere in the code. There is not a single line of code in the project that is under the control of only one person. A good description of code ownership can be found at Martin Fowler’s Blog. As mentioned, we know each other very well already. If this weren’t the case,  CCO would be much more of a hassle.  A lot of trust and a lot of communication is necessary and coding divas are not allowed. Fortunately there is no diva in our team yet.

CCO is key for the success of a distributed team, because it helps to spread the knowledge of the code, systems and architecture of the project among team members (as pair programming does). Programmers will perform much better when they know how to use a specific system and how to adapt it to their needs. Not everybody on the web thinks that CCO is a the best idea ever; please check Ralf Sudelbücher’s Blog for a different perspective.

Step 7 – consistent and very regular refactoring

This, you might think, is not something specific to distributed teams — but I’m here to tell you you’re wrong. Sitting at home on your own, without a team mate next to you who reminds you to fix that broken window now (kudos to the pragmatic programmers), makes refactoring much less likely.  The code quality can decrease quite fast for a distributed team if the programmers do not really care about it. What to do?

It’s actually quite easy. At each pair programming session, we identify broken designs and foul code and write our own refactoring stories. We give those stories the highest priority in the backlog. It’s very important to keep these stories as small as possible, because refactoring can sometimes get out of hand and this should be avoided. We only put the most relevant refactoring tasks into stories, because otherwise the backlog gets too confusing.

Step 8 – keep up the motivation

This is by far the most relevant and hardest part for a team which does distributed work, especially when there is no investor yet. The 7 steps already described help a lot to keep up the motivation when done right, but that’s not everything which can be done.

Try to establish a culture of praise and respect in your team. As soon as people start blaming each other,  motivation will ebb and the team will break apart. If possible, the whole team should meet on a regular basis, as this helps a lot to improve communication and trust.

It’s also very important to have progress in all areas, not only the development part. Somebody has to care about investor relations, marketing issues, team building, business development etc.  The team needs to believe that the product will be a success and that it is worth selling to the customers.

That’s it for today. I hope I could shed some light on our Scrum and XP processes and if you have some improvements or suggestions for us, I would be very happy to hear them.

Popularity: 6% [?]

Game design distinguishes between mechanics — the rules of the game — and content — the stuff in the game, like art, music and story. Good mechanics tend to be fairly simple, so that players can understand them, but provide enough flexibility for expressive play (consider chess and go). This often makes them cheap to implement: a clear, simple set of rules is a programmer’s dream. Good content, on the other hand, tends towards the elaborate and expensive: if you want your game to contain a city teeming with life, you’d ideally want every one of its thousands of citizens to look different, and possibly even behave uniquely. Big budget titles like content, because if you have money, it’s the safer bet: it’s hard to come up with good new mechanics, and even if you do, gamers may reject them. Content allows you to distinguish yourselves from the competition without that risk, and you can produce it pretty reliably (of course, there are brilliant and incompetent digital artists and authors, but for an average team, more time & money => cooler content).  On the other hand, Indie games tend to emphasize clever mechanics because that’s all they can afford. Also, games intended for brief play sessions, like arcade or casual games, simply don’t have enough time to show off much content, so they can and do skimp.

But there’s the rub: people associate content-light with short! If someone sends you a link to a browser game with little content, then you will almost certainly play it for only a few minutes, regardless of how brilliant its mechanic may be. If it were boxed for retail sale, you wouldn’t play it at all. There are too many games available to expect people to have the patience to let a mechanic unfold unless they are seduced by content. If chess were invented today, it would fail. A few people would play it, sure, but if only a few people played chess, it would never have reached the depth it has; the scholar’s mate might still be state of the art (unless it got nerfed in a patch).

We here at Rough Sea are making a game that is not short. It’s intended to be played in brief daily sessions, but the world and characters are persistent, so each session contributes towards larger goals. Therefore, we need content. But how will we keep up with the consuming hunger of our hoped-for hordes of fans? That’s a subject for another post.

Popularity: 8% [?]

Finally it’s time to show some of our game’s art. We will begin with a ‘Making Of’ that covers the steps in the creation of an environment artwork.

In the ‘Making Of’ image you can see the creation process, which I will explain below. First some general info on how most of the artwork is done and which tools are used to create the art:

95% of the artwork is created digitally. Only 5% is done with traditional tools, such as a pencil for creating sketches. The digital art and paintings are done with a Wacom Intuos3 DinA5 wide tablet and Adobe’s Photoshop software.

So let’s take a look at the first image in the ‘Making Of’ overview:

1. Compared to the later versions you can see this image shows a smaller area. I started the first layout like this and later widened the view to show a temple to the right and a waterfall at the bottom. In this first step I’m blocking in the main areas of the image while trying to catch the ‘mood’ with the colors.

2. This version adds additional space and more texture, which was painted in with a textured brush. I have also added more saturated colors and changed the contrast of some areas.

3. Note the new details. Also, you can now see the position of the light source, which was planned from the beginning for the upper left area.

4. In this step I added some atmospheric perspective to get the illusion of depth. You also can see still more details.

5. Beside yet more details, I added more yellow to the color scheme. That makes it look more interesting and the new ‘mood’ fits our game. (You will understand when you see what our game is about! )

6. This image contains more lights on the bridge and plants and changes a few details.

The thumbnail image to the right shows the final image with more added details, for example the birds in the background.

I hope you liked the first ‘sneak peak’ of the art.

Best,

Chris

Popularity: 69% [?]