Movin' on

I've sold 64 copies of Downwash so far; I had hoped to sell 200 by now. Epic fail! Well, it would have been anyway, but now it's even more epic.

I'm going to make my next game a puzzle game. I thought it was going to be super easy to come up with a good puzzle game idea, but I was very, very wrong. Eventually I settled with a bit of a 3D clone of Addicing balls, which is a good game, but not so much "puzzle". Addicting balls is very good, apart from some minor problems such as always restarting from scratch after game over. A bit 80'ies. Instead of inflating balls, I'll let the user cut away part of the level (I saw that somewhere in some youtube clip on a similar free game, but for Android) until a threshold is reached.

I'm thinking something like this (although using soccer-textured balls instead):

The line is a cut in progress. It's going to be relatively easy and quick to develop. And I think it will be pretty fun to play. Here follows a memory dump from my nightly thoughts (couldn't sleep).

Idea
Start with a box ("level") with some balls inside.
Cut box into smaller pieces, using straight "lines" which are projected into 3D.
Cutting is not instantaneous. The cut starts as a small, round saw blade which grows. If a ball hits the cutting blade before it's cut off all the intersecting surfaces of the box, that cutting blade is destroyed and "number of lives" is reduced by one.
If the cutting blade chops off a part of the box, the living space of the box is reduced. All parts of the box which does not contain a ball is eliminated.
When more than 50% (or so) of the box is cut away, the player has completed the level.
Each level has one more ball in it than the level before.

Shapes
Box is a triangle mesh.
Only use triangles in the box, for simplification.
Let box be a cuboid which is deeper and wider than it is high.
Balls are spheres.

Rendering
Balls are soccer-ball textured.
Balls cast shadows.
Cuboid is shining, flat-shaded. Change color each level. Avoid white+black for ball distinction.
Cutting blade is flat-shaded, double-sided, transparent with saw teeth on the edges. Color is complement or not close to cuboid color.

Cutting
Cut with line+blade until released. If starting ray does not intersect with any triangle, choose plane through origin as depth midpoint, otherwise use average depth midpoint.
Don't start cutting until delta dragged >= 4px (so angle can be determined).
Use cylinder shape as cutting blade trigger.
Start growing cutting blade cylinder as soon as depth midpoint has been determined.

Movement
Camera moves as soon as a cutting has been initiated, and as long as there is no cutting in progress.
Camera moves 2/21 of a revolution counter-clockwise each time it's animated.
Camera also bobs some up and down to give a clearer view of the 3D space.
Cutting blade rotates while cutting.
Balls have a maximum speed, if reached their speed will momentarily be reduced to the maximum.
The total sum of the speeds of all balls must exceed a threshold, or they will all have their speeds momentarily set to a minimum.
Balls gain a little energy when colliding with one another, but loose a little energy when colliding with a wall.

Math
Calculate volume of mesh: http://stackoverflow.com/questions/1410525/volume-of-a-3d-closed-mesh-car-object#1898484.
Calculate ray against mesh (hopefully using ODE).
Calculate plane of cutting blade, given a camera angle.
Cut mesh in two using two planes (to give cutting blade some width+volume).
Check if a mesh contains a ball. (Otherwise it will be removed.)

Sounds
Keep 'em subtle.
Music, let's use XM format. Keep volume low.

Demo
Banner ads at the top.
Restart from scratch on each game over.
Limited to level 10.

I'll start working on it in a couple of weeks. First I'm going to build a home-brew alarm system for the house with my eight-year-old son.

Postmortem: Downwash

What went wrong		What went right
Simulator Everybody in casual gaming hates simulators. So do I.		No specialcasing During development I tweaked the game engine a lot, but in the end I didn’t have to make many hacks. This bodes well for the upcoming games. For me, the biggest part of making this game is developing my game engine.
Interactivity The interactivity in the game is really poor. I had foreseen a much better experience when playing, but I was way too optimistic. From my first test levels it didn’t improve at all. That partly had to do with level modelling being a bit cumbersome in Maya. Maybe I have to make a level editor soon. Everyone else has one.		Bug free Well, at least not that many boogs when doing this simple games. Especially the tooling improved this time around. And as I’m planning to make a few of simple games now, this should be good news.
Overall look The overall graphics look like shit. There’s no design, so it all looks like kitsch a 10-year-old would proudly produce. But I didn’t want this game to look like kitsch produced in the kindergarten. I tried to make it work on the iPhone 3GS by reducing poly count and texture sizes, but eventually it just came out ugly on the fast platforms and slow on the ‘ol 3GS.		Portability This time I made it for the PC, ported it over once to the iPad in the beginning then made all the development on PC before finally converting to iOS. I also release the game for free for Win/Mac. Apart from C++11 porting (which was quite hard and took me 20 hours of intensive work) the rest of the porting probably took less time. This is good news as I expect most consoles start allowing home-brew development soon.
Controls The controls are not only the controls. The controls are also the avatar inertia, the feeling, the steering; indirect things that are not so easy to pinpoint. So while the controls are ok per se, they are also pretty bad. The helicopter inertia is way too big. It’s too difficult to steer. If people wanted to fly real helicopters, they’d go do that instead. So control-wise it’s alright, but steering-wise it’s a disaster.		Controls The controls are alright.
Instancing In my tooling, I just had game object classes, no instances. That is to say, each instance of a game object I created in a level was exactly the same. Each car. Each helicopter. Each turret was exactly the same. The only way to remove the most rudimentary similarities (like color) was to hard-hack. Not good. But in some upcoming games I’ll generate content I think. It’s more fun, and I can postpone fixing the tooling. Which is hard as the game engines’ resource pipeline is a mess to change.		Opens the door to the future Now it’s time for me to shine. After a well-deserved break, I’ll produce several game titles in a pretty short amount of time. I’m hoping at least one or two of those will be good.

 To sum up: this game turned out pretty dull and sad, but I'm where I want to be with my engine. So I still feel like a winner. For the next game I must learn how to create great content!

Work load distribution

If I have time, I'll create post mortem in the end of this post. Otherwise it'll have to wait. First some stats. The game took 5 months to complete. Yaiks! That's way too much for such a simple game, but I feel there is some explanation lurking behind the scenes. Let's dig.

First off, I'm a bit curious as to how my work was distributed between the game itself ("Downwash") and the engine. If almost all the work was invested in the engine I'd be danged pleased and proud, but I fear that that is not going to be a reality. Although the game only turned out to be 4052 lines of code and 2274 lines of game object configuration (in all fairness, it's a very simple and dumb game, but it's still half the amount of code in my previous game which was equally bad), I'm pretty sure that a lot of the tinkering went into the game itself as the engine evolved. So how did I manage?

Aha. Ok, most of the "other apps" is a big refactoring I started with, before creating the Downwash stub. So in terms of work, I'd say it's an even split between game engine and game. If we lay it out over time and stomp the initial app/engine refactoring we get:

So approximately 2.5 months engine development and 2.5 months game development. This game helped the game engine mature, and it really improved the APIs and definition of what goes into the game and what goes into the engine. 2.5 months isn't very good for a boring game like this with ugly... everything. But I'd say about half of that time was spent tinkering with the interface and other dumb crap like having to port all code to C++11 (apart from some iOS 4.3 support, which still is on C++03 for some inexplicable reason).

The split between application and engine is a fairly good one now, and it works for my various other projects, both released and not-yet-released. The interface is portable and allows a well-defined server/client split, support for building the server into the client as well as creating a dedicated server (intended for Quake/Minecraft style games). It's easy to add split-screen rendering, each using a different network client towards a local or remote server. Each local client has it's own configuration environment, camera and mic, but share a common physics engine (currently ODE) for performance. (When the console makers open up for indie, I'm ready for some split-screen stuff!)

Especially the multi-threaded code for running rendering, scripting and physics in parallel is poorly designed and only yields a small performance gain while at the same time being very unstable. But I think I'll keep it that way. I can always fix most of the stability issues, but re-designing it is too boring and too much work. Also the core of the system is a monolith, but while the main "manager" is a big goo in the middle, it also centralizes data and code in a way that makes most things very straight-forward. I won't be re-writing that either any time soon.

This time I feel very confident that making a simple physics game would be very fast and easy to do. But nah... too easy+boring! Hm... but wait a second... I could create 10 simple games in a year, and at least one or two would be pretty fun. Now I'm thinking that maybe I'll learn more from that than I'll ever do if I just push on to the next big hurdle - adding skinning to the tooling, adding animations to both tooling and engine (gulp), adding landscape/city/dungeon generators, improving rendering...

Ok then. I'll create a few simple 3D physics games. Do they need to be 3D? Do they need to have physics? I can't compete with 2D. At all. 2D is all over App Store, and they do it so well it hurts. So it needs to be in 3D; that's my niche. Regarding physics, I'm pretty sure I could skip that part. But when you've built a nuclear plant, you don't want to power a bedside lamp with it. And apart from physics I don't have much; the rendering is... well... pretty lousy. I'm bad at art, sound, music and game design. That doesn't leave too much, does it? But alas, I'll make one or two tap-and-swipe pointless type of games without physics in them. And surely the mob will think that those games are the best ones. Morons! (Mm-mm, this must be how Allah feels. I just need to learn how to set bushes ablaze. Does he too burn bushes when he wants attention?)

No time for post mortem this time. Next post.

Victory!

Grand! App Store says

The following app has been approved and the app status has changed to Ready for Sale: Downwash

Good riddance, Knäwelbart! It is actually a bit intimidating to look ridiculous all day, but fun too. And it's real nice to be able to drop the look in other peoples' faces in a heartbeat, as opposed to say overweight. I've always kept one thing in the back of my mind for things like this. Although I'm not religious, I've always respected stroving Word of Faith-people for exposing themselves to the ridicule. It's something every person should do once in a while, it teaches you both humility and strength.

Post mortem due next post! :)

Gaaah!

I submitted my binary to App Store, nice! I turned off my computers and thought I'd have a well-earned week off or so. Not so fast said Apple. Two days later I started my machine to check mail and to my surprise I had gotten a mail from Apple stating that

Invalid Launch Image - Your app contains a launch image with a size modifier that is only supported for apps built with the iOS 6.0 SDK or later.

After some googling I realized this was part of a coup from Apple to invalidate old devices (iOS 4.2 and earlier). I have one of those myself, and hadn't updated Xcode for ages (3.1.5 I think), so instead I removed my hi-res launch images and thought what the heck, nobody's gonna buy this game anyway. But still App Store wouldn't allow me to submit my app, a rejection e-mail saying the same thing landed in my inbox a couple of minutes after I submitted every time! Probably due to some bug I guess.

Didn't leave me with a whole lot of options. So I've had to spend hours (and still is) on:

• Installing Xcode 5 to be able to release at all.
• Scrap STLport as LLVM headers as bundled with Xcode 5 didn't play nice.
• Evaluate Boost. I'm still hoping I don't have to go there.
• Evaluate C++11. LLVM in Xcode 5 supports unordered_map and unordered_set, which is pretty much all I've used.
• Installing MSVC++ Express 2010. I had used 2008 up until now, but now I have to abandon the older version as it still uses a separate namespace for unordered_xxx. MSVC++ Express 2012&2013 won't install on Windows XP, so soon I need a newer version for that shit too.

Duh! I'm betting this shit is going to come down to some horrible linker error which will take me days to resolve on both platforms. This is when you realize that Microsoft still does a pretty good job of upholding some type of compatibility.

Ok, let's see... the app just finished compiling and linking for C++11 in Xcode 5... Hmmm... porting wasn't bad at all... Oops, but no it won't start. Debugger in Xcode can't launch. I pretty much know where it's going from here. I'll release in T-7 days instead of T+2 days. FUCK THOSE SHITHEADS, I WAS FUCKING DONE!

Almost there

Spent the evening with menus, which went a lot better than I dreamed of. Everything is a lot easier as I'm only releasing for one (good) platform. I also started testing. My eight-year-old has been conducting the tests. From what I learned I conducted a remake of kids controls.

I also confirmed that simulations on iPad is really bad, for several reasons. Kids play on iPads. Most small kids don't have any interest what so ever in simulations. Secondly, helicopters are difficult to fly; that's why I like 'em. Most people don't like difficult things when playing casually.

In all: it's another epic fail! But I'm not sulking, I feel pretty good about what I've accomplished this time around. The bugs in the tooling are almost gone. The game is 3746 lines of code before cleaning up. I used 44 3D models along with 2274 lines of configuration; 33 images; 29 sounds and 7 songs. Most of which I can reuse in future games. Not too shabby eh?

Release, come to daddy

My son is feeling better, so everything back to normal. I'm guessing some pin-worm induced amoeba, but not sure. Game-wise, I'm (almost) done with everything apart from the menus, and I'm celebrating this by taking some development time off! Here is a small explanation on why it takes for ever to make a game. 40 days ago I thought I'd just spend 15 nights on:

• Create the menu.
• Create icons and splash screens.
• Surf around for free music.
• Create or download some background images.
• Fix some bugs.

I haven't have time for creating the menu just yet, but this is what I've done instead:

• I looked around and listened to some free music, and eventually settled on reggae. I downloaded, mastered and converted seven tunes to OGG/Vorbis.
• Improved music loading code.
• Downloaded some nice scenic photos, photoshopped them for left/right tiling and used them as background textures.
• Tweaked look and feel of iOS touch buttons.
• Fixed level 3 bug (camera sometimes moved above through the ceiling). Fixed door shadow bug in level 5 (door looked awkward with shadows). Added three levels, one of which was the crazy final level with some strange content. Added a couple of different turret enemy thingies on a couple of levels.
• Improved configuration for turrets.
• Added scaling when loading meshes.
• Added a nice "well done" thingie when the player completes a level.
• Added support for saving settings on iOS.
• Renamed the application (and all files within) from project name HeliForce to Downwash. Pretty easy to do using my neat Python script for cloning applications.
• Fixed native auto-rotation for iOS. Before (Kill Cutie) I had just rotated the camera, but I really wanted the nice frame and iOS feel. It was a bit fiddly supporting my home-brew rotation, iOS6 and iOS7. Keeping iOS stuff portable and flawless between the 6 and 7 doesn't seem easy if you're doing anything advanced with the UIKit. For portable games and simple apps it is pretty much a walk in the park though.
• Fixed volume settings. Before I'd just turned the volume way up, but as I started playing the game on all platforms, I realized I need to adjust the overall volume to get the sense of distance and direction I'm after. Also added support for setting the music and master volume individually.
• Fixed the joystick look, and adjusted the feel somewhat. Now it's pretty good in the iPad, but too small on the iPhone. I won't fix that.
• Fixed order of levels. The next level doesn't exactly start where the previous ends, but it's along those lines. A bit.
• Added better support for measuring in-game time. Before I only had support for measuring calendar time, but that is not very good when there is support for slow-mo as well as app moving to background.
• Added support for actuators which are very simple to configure. As an example I used one for a boat that bobs up and down in the water.
• Fixed a bug in the actuators which caused them to move in the opposite direction if they didn't have any dynamic parent (i.e. the world is the parent). ODE is a little bit strange in that respect.
• Added (nice) support for playing ambient sounds.
• Added support for spawning objects with an initial velocity.
• ... and a bunch of smaller stuff.

After my break I'll add some more content to some levels, I'm thinking barrels and coffins or similar man-made stuff, just to make them feel less sterile. It will have a marginal effect, but I'm not doing more than that. And then I'll fix the menu. And then release! It should take about six evenings, I'm guessing. Let's see if my guesstimations are 3.14 times off this time too.

I feel that the engine is in a much better shape now than after Kill Cutie, and the support for adding simple content (without having to wrestle bugs) is a lot better. The engine is still lacking some nice rendering, but apart from that I could very easily do some physics sandbox games. But that wouldn't be a challenge, so I'm not doing that. But I should.