Opinions needed: which art style for Cello Fortress?

The gameplay of my live performance game Cello Fortress is nearly finished, but the graphics are still basic blocks with some crude textures. Recently I've been working on figuring out what style I want for the game, and I've ended up with two possible styles that I like: one dubbed "Surreal Architecture" and the other "Rough Polygons". Since I have a hard time choosing, I figured I'd just ask here. Which style should I use for Cello Fortress?

I've also added the pros and cons of each style as I see them. Several are just my personal taste so let me know in the comments if you disagree.

"Surreal Architecture" style

The basic idea of this style is that you travel through a world of surreal architecture. The surrealism is of the subtle sort: on first sight it might look like normal classical architecture, but if you stop and think for a second you realise this cannot be: buildings are too big and repetitive, it makes no sense to have a city with nothing but church towers, and why is there an area with giant organ pipes?

This style is inspired by the graphic novel series Les Cités Obscures (also known as Cities Of The Fantastic or De Duistere Steden) by Schuiten and Peters. To get an idea of their style, have a look at these beautiful images. To a lesser degree it is also inspired by the Rork series by Andreas (picture).

The main reason to do this style is that I love classical architecture. I haven't done a lot of 3D modelling recently and this kind of stuff is one of my favourite things to model so I'd love to get back to that. The biggest problems with this style are that the link with Cello Fortress isn't very clear, and that it might distract from what the game is all about: the live cello. So the main reason to do this style is that I'd enjoy making it so much.

As concept art I've made some basic environments in 3dsmax and even rendered a video as if it were the game:

Click for high resolution

Click for high resolution

Previz video of the Surreal Architecture style.

Pros

• More unique and notable
• Lots of fun to make
• Very close to me as a person

Cons

• Lots of work
• Distracts from game's core (the live cello)
• Gameplay less readable for players
• Link between visuals and gameplay less clear
• Needs serious optimisation for good framerate
• Doesn't fit style of existing vehicle and turret art very well
• Not entirely happy with this concept art yet

"Rough Polygons" style

This style is a lot simpler. It is mostly about big, untextured polygons. It has a rough rook and most of the potential beauty of this style comes from the lighting. Using a combination of pre-baked lightmaps and some simple tricks I think I can achieve a global illumination-look as in this image.

A big benefit of this style is that is does not distract from the gameplay. Cello Fortress is such a weird concept that I often need to explain quite a lot to the audience and this style won't distract from the core. It also helps that the gameplay will remain very readable under poor lighting conditions: I often perform with Cello Fortress at festivals and it is not rare to have a beamer projection on a rough wall with too much environment light. Such conditions make the game look a lot less bright and crisp than a normal gaming environment.

Click for high resolution

Pros

• Very readable and understandable for players
• Looks good with crappy beamers on bumpy walls
• Faster to make
• Higher framerate
• Fits style of existing vehicle and turret art

Cons

• Less original / notable
• Not as much fun to make
• Strong shadows on the floor might be too dark but are crucial for this look
  

Why am I not sure which style to choose? The Surreal Architecture style is much more fun to make and would stand out more, but it just doesn't seem like the best choice for the game. It has little to do with the rest of the concept and would distract from what it's all about: the live cello performance.

Which do you think I should make, and why?

Cello Fortress micro vlog #1: Big Chord Attack

I've added a new cello attack to Cello Fortress! Check this little video for a demo and explanation. :)

3D printing Captain August

To use a 3D model for 3D printing it usually needs to be altered quite a bit, since 3D printing adds a bunch of additional requirements that rendering and games don't care about. I've recently done this for the first time so today I would like to explain the process and show the result.

Let's first have a look at the result:

Click for high resolution

I used a model I made in 2007 of Captain August, a webcomic that ran until 2010. The author of Captain August is a friend of mine, Roderick Leeuwenhart, and I made this 3D print as a birthday gift for him. Awesomenauts players might be familiar with Roderick's work as a writer: he wrote the voice scripts for a bunch of the latest additions to Awesomenauts, including Ksenia, Rocco and the Wildlife Documentary Announcer. Roderick also writes books: he wrote the "Pindakaas en Sushi" series. This title means "Peanut Butter and Sushi", which must be a delicious combination since I personally came up with the name. ^_^

Click for high resolution

To 3D print a model it needs to be one mesh without intersecting polygons, and the mesh needs to be without holes. When modelling for normal rendering geometry is often a lot of interesting objects and this mesh is no exception. The arms stick through the body, the eyes through the head, etc. To fix this I filled all the holes in all the individual objects by hand, and then used the boolean union tool to combine all the objects into one mesh and get rid of all the intersections. This crashed a lot because of the high polycounts (and probably also because I use the ancient 3dsmax 2009), but after a bunch of tries it worked and I got a usable model.



For the 3D printing I used Shapeways, a company specialised in 3D printing on demand with all kinds of different materials. They even do expensive stuff like silver, but that wasn't intended here.

I uploaded my 3D model into their system to see whether it would accept it. Shapeways runs a lot of automatic tests to find problem areas and it found a bunch that I had to fix. The biggest thing to look out for is whether walls and wires are not too thin. 3D printers can print fine details, but those might not be strong enough. The limits depend on the material and I suppose also the manufacturing process. With the Color Sandstone material I wanted to use, details cannot be smaller then 3mm (there are some further details to this, check the Shapeways site for more info).

In this case I had to fix things like the long pointy nose and the fingers. The fix was rather easy: I just made them thicker, and in case of the nose I also cut off the thinnest part at the end. I performed the fixes on the original model and then redid the boolean union step (including the crashes).



A bit more subtle is that the model needs to be balanced and not snap. Shapeways describes this as the "Sandcastle Rule: if this structure was made of wet sand, would it break?" However, exactly what the limits are is unclear, so I had no idea how far I could go. To be on the safe side I just made the legs and arm a lot thicker and asked Shapeways whether it would work. Within two days they had a look and emailed it would be fine. The model indeed worked out well so apparently this was enough.

3D printers cannot interpolate normals, so polygon smoothing does not work for them. This means that if you make something for 3D printing, you need to turn off all surface smoothing. If the model is not smooth enough at that point, you need to add polygons to make it smoother. In this case I was lucky: the Captain August model was made entirely through low-poly modelling with meshsmooth in mind. I could just increase the number of meshsmooth iterations to get more polygons and thus smoother surfaces. The end result is around 200,000 triangles.



To do a colour model Shapeways wants either a texture or vertex colours. Since my 3D model is mostly just flat coloured parts I made a quick texture with those colours and that's it.

This is one aspect where I think I could have done a better job: since notches and details are so tiny on a figurine they don't get the shading and sharp shadows that a full-sized model would and thus are less visible. A Warhammer model painter once told me you need to paint the lighting to compensate for this. I didn't think of that for Captain August and I think he might have looked better had I done this. For example, I could have made the insides of the creases a bit darker.

Shapeways does a lot of different materials, at very different price points. I wanted a full-colour figurine and didn't want to pay too much so I went for the Color Sandstone material. This is an interesting material: as the name suggests it looks like sand, but it is really a hard material.



From up close this material looks really weird. I wonder whether it was the inspiration for the strange material of the character Joy in Pixar's brilliant new movie Inside Out. It looks a bit similar. Looking at this concept art it probably wasn't, but I couldn't resist an excuse to mention how awesome Inside Out is (yes, I know, I'm a Pixar fanboy).



An interesting aspect of most current 3D printing techniques is that they print in layers. If you look closely, you can often still see those layers. In this model this is especially noticeable at the top of the head and in the wood. My wood mesh has a noise applied to it to make it look less flat. In the 3D print this generates unintended layer patterns that actually look pretty cool. However, in some spots it looks a bit too much like a map of terrain heights.



It turned out to be surprisingly difficult to make good sharp pictures of an object this small. I tried several lenses and lighting conditions to be able to make sharp pictures. I also tried a bathtub trick that I heard about somewhere: I put the figurine in an empty bathtub, giving an exciting all-white background. Pity the lighting conditions in my bathroom were pretty bad so these photos aren't as good as hoped. Still, funny idea.



To conclude this blogpost, here are a bunch of pictures of Captain August under several angles:







Click for high resolution

I'd love to do more art for 3D printing at some point, but for the moment the price of the actual 3D printing is just too high to do just for the fun of it. I'll first have to look for a good excuse to try this again. Maybe another birthday or something? ^_^

Why adding multiplayer makes game coding twice as much work

Most gamers and reviewers these days expect almost any game to have online multiplayer. What they might not realise (or not care about), is that adding online multiplayer makes a game twice as much work to program. Most programmers who build this for the first time hugely underestimate how much work it really is. For those who have never made an online multiplayer game, here are some of the reasons why it doubles the programming effort needed.

Before I start, of course note that the real complexity of building multiplayer depends on the game. Adding a multiplayer match-3 minigame to Mass Effect probably wouldn't be much work compared to the main game, but that isn't realistic: big, complex games usually also have big, complex multiplayer features. Roughly doubling the time it takes to program a game when multiplayer is added is in most cases a good guideline.



Latency
The basic cause of all multiplayer complexities, is that it takes time for a message to travel from one computer to another. This might take anywhere between a few milliseconds and a few seconds. Whenever you need to know something about another player, you always have to take into account that you don't know when the answer will come. To make things worse, it's impossible to know exactly how long any specific messages takes and latency might vary wildly between packets.

Gameplay synchronisation
All players need to have the same view of the game world. When things happen on one computer, packets need to be sent to make sure all computers know about it. This adds a lot of complexity to an otherwise simple game, because the game suddenly needs to be able to put all the information about the game in packets and send those over the internet. And what to do if we want smooth animations while some packets take way longer to travel over the internet than other packets?

Waiting
In a normal game, when you want to start a match, you just do so. In a multiplayer game, computers first need to talk about that to make sure all computers go into the game together. Since sending messages takes time, you need to wait for answers to come back. But what if a message takes longer than expected? Is it indeed coming later and should we just wait, or was the other computer suddenly turned off and is the reply never coming? Basically, any communication you do needs a timer to keep track of how long you are waiting and to cancel communications if the answer takes too long. And, also important: you need to handle if the message unexpectedly comes in after you decided to continue and not wait for it any more!

Gameplay balancing
All the other topics in this list are about tech, but of course game design for a multiplayer game is also really complex, especially in the balancing department. Our game Awesomenauts now features 22 characters and a thousand upgrades, and more are underway. What if some very specific combination of characters and upgrades is way too powerful?

Even with thousands of hours of balance testing you can still be certain further balance issues will be found once your game launches. Even Blizzard, with their extensive beta periods, never manages to get balance completely right at launch. If your game involves any kind of balance, then be prepared to spend ages getting it right, and more ages to improve it after launch.

Bandwidth
Modern internet connections can handle lots of data, but not everyone has such fast internet, so any commercial game needs to be able to run on low bandwidth. Most games seem to settle for something around 10 to 20 kilobytes per second as the minimum bandwidth required to play the game. Awesomenauts is no exception. Updating dozens of characters lots of times per second without using way more bandwidth than that requires some really smart optimisation tricks.

Scalability
If your game uses any kind of servers, then those better be prepared for any number of players. What happens if all of a sudden a thousand players all try to join matchmaking? Writing scalable server code is incredibly difficult. Testing it is a challenge since you can't easily get thousands of people to run your game simultaneously, especially before launch.

With Awesomenauts we once had a free week in which the concurrent player count went from 1,000 to over 12,000 within 24 hours. If your netcode and servers can't handle success, then you won't have it. One workaround for this problem is to not have servers of your own at all: Awesomenauts launched using only the services that Sony/Microsoft/Valve provide. Since those are scalable, so was Awesomenauts. I expect that if it had been 100,000 instead of 12,000 it would still have worked, simply because Valve's system are used to much more. Still, we spent a lot of time before launch analysing and testing our code to make sure it really was as scalable as we thought.



Invites
One particular topic that may seem like a detail, but turns out to be horrible, is inviting people. On modern platforms like Xbox, Playstation and Steam players can invite their friends to play with them. The complexity here is that these platforms allow players to accept invites from basically anywhere. Not just while in the menu or while playing another match, but also during a loading screen, during the intro cinematic, from outside the game or even while joining a game based on an earlier invite!

To give a nice example of something that could happen on the Xbox 360: while a player is in the loading screen, another player on the same console might pick up the second controller, log in with another account, and accept an invitation to play with someone online. Now the first player's match should quit as soon as the loading screen ends, the second player should become the Active Player and should join his match. This particular situation is really cumbersome to handle, and it becomes way worse when you realise there is an enormous amount of similarly weird combinations of events and they all need to be handled correctly.

Console requirements
Which leads me to the final topic here. Modern consoles have long lists of requirements that games need to abide by to be allowed to launch, and this list gets a lot longer if your game has online multiplayer. If any of the weird combinations above goes wrong in the game then Sony, Microsoft or Nintendo might refuse to release it until it's fixed. Of course, console manufacturers are right to demand quality for all the games that launch on them, but it does take a lot of extra work to build.

Debugging
Just starting the game to test your code isn't good enough for an online multiplayer game. Instead, you need to start several instances of the game, make them connect to each other, and then test whatever you just programmed. Also, the number of possible combinations of events explodes in online multiplayer situations, so not only does testing become much more cumbersome, it also requires many more tests.

I could easily have added dozens of other items to this list, but I think you already get a clear picture of how complex creating a multiplayer game really is. Many programmers think they can add online multiplayer to their game in just a month or two, but for a game of significant size it generally takes way longer than that, especially the first time you do it!