Tag: Game Dev

Once Upon a Time

What better way of starting a new year than looking back?

During the holiday season I was mostly amongst family and friends, or just plain chilling out, hence not much got done on the game. Now I got my gamedev mojo back, but check out what I found in a treasure chest (no, really) when digging through some stuff I moved into our new house from my childhood home.

This is how it started. And no office is complete without that memorabilia on the wall, right?


My old 5.25″ floppy disks (don’t know what that is? Ask your dad, he might have a 5″ floppy, tee hee), most likely still in working condition if such a drive still existed. My first computer programs and games on them, in Basic-8000 format for the Zilog 8001 processor, 512×256 monochrome graphics, and occasional monotone beeps for sound. Sweet. Ordered from left-to-right, top-down, there’s:

  • My first disk ever, “Programs”, from 24th of October, 1987, so I’ve been 10 and a half when I got the computer. It contains various not-so-advanced programs, like the infamous 10 CLS 20 INPUT “What’s your name?”, A$ 30 PRINT “HELLO GOOFBAG!”, and so on.
  • I didn’t even remember it, but one of my first”real” game attempts seems to have been “Fighting Master”, from 1988. I now recall it being an arcade-style fighting game where two dudes hit and kick each other. It never worked if you were two on the keyboard, which kinda defeated the purpose.
  • Then my most precious gem, the “Games” disk no. 1. I recall it being the first new disk I have ever purchased, and I started to fill it will all the games I came up with, complete with a “menu” program to launch them. Some games I even finished to a state where I and my brothers could play them, like “Jackpot”, a one-armed-bandit into which I put secret keystroke codes to win more. My own favourite was a game about our local bus driver who drove around in a city of boxes and picked up invisible items and passengers, some lenient, some aggressive. I think there’s something like 60-80 games on the disk, not sure thou.
  • Piilosana” is a finnish word for a kind of a crossword puzzle. This baby, from 1992, is actually one of my fully working software, originally made for my mother who made sometimes crossword puzzles to magazines. It could load, save, edit, and print puzzles, all in a nice WYSIWYG UI. Yay.
  • Ah, my “MasterWorks“. What a unique name and a great piece of office software. No, really, it had MasterDraw which was quite advanced, given I had only the monochrome display. It had the standard drawing primitives, but also text with bitmap fonts, “spray can” painting, gradients (looked like crap), saving, loading. It was in this code I kinda invented GIF. There was MasterFonts for the bitmap font making, MasterMusic (for monotone beeps, WTF!?), MasterCard (LOL) for printing cards and labels, and MasterNumPaint, which I’m not sure, but I think is my complete failure of mimicking Excel. Seems to be from 1992 – I was 14 at the time.
  • “Rescue 9116dX”, oh, this I had forgot also! My attempt for my most advanced game ever, a side-“scrolling” space shooter. I think I tried to clone that Nintendo 8-bit game, can’t remember the name right now. First time I started to use sprites. It never got anywhere as the memory (56kB free for Basic) was not enough to contain the sprites plus running code, and the drawing speed of the 4 MHz processor was anyway too slow for any real graphic processing (in Basic – perhaps assembler could have done more?). Simple small lines and circles Ć” la Pong were OK, but a circle greater than 50 pixels in radius was so slow that you could see it being drawn, arc-by-arc, if you animated it. From 1993, cool that I labelled all disks properly. Loving the cover art. šŸ™‚

Alright. Let’s get back to the future, I have a game to make!

Tiny Notes for Tiny Effects

So far the game has had very little details like visual feedback on actions – meaning mostly small visual effects when you do something on the screen. In the prototyping or first testing phases you naturally don’t need such, but no game is finalized without. I’ve been putting in mockup art for both the iPad and iPhone/iPod resolutions so I could do better testing on the actual devices but after a while of testing I had a nagging feeling “duh, this is a bit boring and plain somehow”. The risk of making a bit of a minimalistic game, I suppose.

But most of it was actually due to these FX being missing. It’s hard to grasp what happens in an action game without all those small details – why, how, did that character just disappear? Wow, how come there is an Oggiput on the playfield now? So I’ve been playing around with this, getting in various effects, but as I started doing it without any real vision on how it should look, I am not particularly happy with the end result. Well, on the positive note I got really acquainted with the animations Cocos2D has to offer.

Now that I’ve let it simmer for a few days I am convinced I should stay minimalistic with the effects as well. No insane particle effects with blurs and lighting effects, but more in the style of the characters in the game. As a beginner it is easy to get carried away with a particle editor… If you’ve seen the screenshots you can tell the shape “round” is quite a generally occuring thing. This got me the idea for the burndown timer particle effect and when you happen to squash a Kisau Veela. Round sprites with some fading and blinking added, in that arcade game style, is what the game needs I think.

Also, there is a lot happening on the screen at the same time as the game progresses, hence a huge particle effect would not be kind to the eye – the main part of the game is about being able to keep your eyes on the Kisau Veelas’ colors and amounts on the screen.

The insertion of all the mockup art made it possible to get rid of the debug draw methods as well. Together with an optimization I made – actually more a must-do-refactoring due to a bug in my state machine – the game actually runs nicely at 60 fps on the iPhone 4. Whew! With debug mode on it was like 7-10 fps and I got worried there for a while…

Testing on the iPhone revealed at least one thing. The game is notoriously hard on the small screen. And if it is hard for me as the developer, it is probably impossible for you a a casual gamer. I knew from the beginning this game would be better on the iPad, but I really want to make this a Universal game for both device families. I’ve got some tuning to do to make the same as similar on both device families as possible, even though they will never be exactly the same due to the resolution differences as the game mechanics are tied to the shape of the playfield. For this reason I need to implement separate Game Center leaderboards for iPhone and iPad, but more on that later.

There’s also a technical issue special to this game while making it a Universal game. Due to the resolution difference and usage of Box2D I need some scaling to happen on iPhone compared to iPad. Otherwise the characters are way too fast and large on the iPhone (think of a ball being kicked with the same power on a small field and on a big field – on the small field it arrives faster to the other side). The Box2D bodies do not scale automatically according to the sprites when Cocos2D is loading the sprite sheet appropriate for the device. I had to hack the class which handles the Box2D fixture loading from the Physics Editor files but in the end this was a very simple thing to do.

Pietari has been doing backgrounds for the Game Over, Level Up, High Scores, and Start Menu scenes. Next up is the playfield background and HUD and finalization of the characters. On my side I need to adjust the game mechanics on the different devices, continue the FX implementation, and tune the scoring. There is one particular game mechanic “glitch” I need to fix somehow – that is, how to handle the scoring et al. in the case the player just whacks around the playfield like crazy. This sort of behavior should not yield a particularly good score and/or chance of leveling up.

Screenshot Saturday #3 and Various Ramblings

I’ve realized I haven’t really spilled any beans on the first game I’m making. There’s a whole science behind how and when indie developers should announce their game and the general consensus is “as early as possible”, while the other angle being “if I now tell my awesome idea to the public, there will be someone ripping me off and releasing a clone of my game earlier than I can push it out”. Valid points, both of them – just look at the mess the awesome Dutch game studio Vlambeer has been facing. I gotta admit, I have a slight, irrational fear of losing the worth of my work by some a-hole cloning my game idea and releasing it faster than the original. I say irrational, while it is clear I have no real traction in the game development community (YET!) and who the heck would actually stumble upon my idea and decide to clone it. But the issue is a bit deeper than this – my fear is not so much a fear, but a realistic computation of when it actually makes sense to spill my beans. It has to do with the equation of how much I have implemented right now, and how much I have left to do: in case the game announcement gets traction in the press, I, just like anyone, would like to be sure I can push through and get the game out there in due time. Hopefully faster than any competitor. Another factor for me is the state of the art [sic] – I prefer to have the grand part of the graphics of the game finalized/near finalization before making the official announcement. Kind of “having something to show for real”. This could be a Finnish mentality thingy. And perhaps something I drag along from my previous work in a bit heavier financial IT projects.

But I’m sure the announcement and releasing of the next game will be different in the positive meaning. This slight irrational fear is bound to go away when I am more seasoned in game development, I am sure.

Well, the previous post certainly left us with hopes for a more informative blog post. Describing the developer side of the game making is probably interesting mostly to the fellow developers. And there was some features I forgot completely I had actually implemented when I posted the previous post!

Let’s take a look on a more recent screenshot. Please keep in mind that the art is still only mockups. And don’t mind the debug texts there, they are for testing the scene transitions.

The feature I forgot to mention is that red/black bonehead of a guy you see in the screenshot above. Yes, da Oggiput, he’s now in the game, and messing it up but only if you mess up first – he pops into the playfield when the player does an erroneous move. The usage of him has evolved a bit from the original idea: I think I will use him as “lives” in the game, in the traditional “three lives and you’re out” kind of way. That way the game gets a bit more dynamics into it – but rest assured, it is still very unforgiving about errors and will pop up that Game Over screen in no time.

There is only one finalized feature you see in the screenshot – the timer bar on the left. No, the particle effect on it is not finalized. The timer, or “burndown” as I also call it, has a few other uses in the game than just a timer. Surely it will remind you that the time is up once it burns down to the bottom, but if you pay attention to the gradient colors of it, you may see that the gradient’s color, order, and relative size seems to correlate with the Kisau Veelas on the playfield. Wink, wink. This was a fun thing to code, BTW.


Let’s treat you to another screenshot as I spoke so vastly about scenes and layers in the previous post. The “Level Up” is a feature I came up with while testing the initial prototype of the game and I think this feature gives the game much more longevity. We have, with Pietari, a certain minimalistic take on the game so I have to be careful not to overdo it with new features, but this one is certainly going in. Ta daa, hereby follows the official beanspilling of the goal of the game: to get a high score. Yes, how disappointing. All this just to get some points? Well, arcade games are quite often like that.

And for that purpose the Level Up is a good feature. With only the “Level Up” text and the Play and Menu button as finalized art, you can get a sense of leveling up meaning to get another Kisau Veela into play for the next round, thus making the next round harder. How many you will start with and how many you will end with is still up for tuning on my side, but most likely I’ll go for fourĀ Kisau Veelas to start, and six for the last round, thus making three levels in the game. So, in these three levels you’re chasing that highscore to brag with among your friends. A pretty pure gaming experience, in my humble opinion.

Bruce Lee

Counts as a Milestone

What an awesome week. I got a full three days of game dev done, and even if that does not sound like a lot – would you believe, I work more or less normal 8-hour days even on “my own game dev days” – there was significant progress made on the game. Unfortunately there’s not enough new art in it to cater for a Screenshot Saturday, so I’ll just list the stuff I got done instead:

  • As I finally have a development device, I tested and tuned the multi-touch gesture handling I already coded like 3 months ago in Spain. Funny to see that the code actually worked – the log was filled with the expected gibberish as I played around with the real device. Funnier still, I did not know that one can actually test, if not all, at least some multi-touch gestures on the simulator by pressing the Option key on the keyboard while clicking the mouse. (Don’t know exactly which gestures, but at least the pinch gesture (zoom-in and zoom-out) can be simulated with that.)
  • Scenes and layers, baby. I have now real, functioning placeholders for all the scenes in the game. So far I had only “Start Menu” and “Play” scenes. I still use “placeholders” as the word for them, as they contain only mock-up art and animations.
  • I tied the scenes to the game state machine and therefore made the game really playable for the first time. What an awesome feeling when firing it up on the iPad Mini!
  • I adjusted various game mechanics details, as I have had doubts on how the multi-touch gestures and the game mechanics I came up with a year ago after a glass of red wine will actually work in real life.
  • I tested, a.k.a. played, the game quite a lot.

So now it’s really rollin’ and I assume I could say I will be a game developer when I grow up. The game is fun enough and I’ve got so nice feedback on the art that the game is certainly up for releasing in the App Store. Release a game -> Officially a game dev -> Great success!

I haven’t ever had a real schedule or deadline for the game. My initial “probably by change of year” was just a guesstimate, so it does not bother me much that the releasing will be shifted with a couple of months to about February/March. This is mostly due to me moving back to Finland and all that – the practicalities shaved away about 5 weeks of proper 3-day-a-week game coding. If I estimate the hours I’ve put in and how many I still need to put in, my initial guesstimate is actually quite accurate. I’ve still got one big part left – audio. I will commission that and hope there won’t be any nasty surprises. Hey, if you’re into game audio, drop me a line on Twitter!

Alright, conclusions and next steps after first real game testing:

  • My initial thought that the game will be best on an iPad or iPad Mini probably turns out to be true. Well, this is not that surprising: MOST games are probably better on a tablet than on a phone due to the screen estate difference. The iPad Mini seems a particularly good gaming device.
  • The tuning I’ve done to the game mechanics was certainly required, but luckily I haven’t diverted too far from the original idea. On the contrary, together with some new ideas like the “Level Up”-style game progressing, I think game is simply better. I noted one “severe” issue in the current version in how the Kisau Veela’s are behaving, but that will be an easy fix for the next version.
  • We will start finalizing the character art and the “static” art like the backgrounds for all the scenes with Pietari now. This will make the game look much more finalized and that will certainly trigger a need for a Screenshot Saturday and a teaser trailer, right?
  • Trailer making. Sheez, don’t get me started, I have no idea how to do that stuff…
  • I will need to whip up a spec-kind-of-document for the audio part. It’s probably good to start earlier than later with that.
  • I’m still a bit unsure, but I think I’ll need one moreĀ scene. Currently there’s “Start Menu”, the play scene, “Level Up”, “Options”, and “Game Over”. There are two ways the game can end: game over, and game over, and I need a scene for the “good” game over kind.

Oh, yeah, the icon of the game is awesome, me thinks!


Simple, clear, clean. Stands out amongst the hugely crammed icons of nowadays’ games. I scientifically tested that: I put it on my iPhone in the middle of all the other games, and this one shines through, take my word for it!


This is a Silly Status Update

I really hate blog posts where the writer starts with excuses why there has not been much activity on the blog lately. So I won’t write one.

The location of the office for the company has moved. And while the company is a rather small one-person game studio at this time, the “we’re moving office” is an indirect way of saying me and my family moved – we’re located back in Finland into our new old house now. Took a bit longer than expected.

Even though coding has ceased pretty much competely for the last month, there’s been some action in the peripherals of game development. Aside of getting a proper home office (yes, I probably need to write one of those blog posts soon), I had finally the time and the place to order a development device – an iPad Mini – and I’m just short of registering it via Xcode to run the game on a real device for the first time. While wifey’s iPhone got smashed on a concrete floor I ordered a 5c in the same go, and now there’s an iPhone 4 & iPad 2 with iOS 6, and a 4S, iPad Mini, and 5c, these with iOS 7, in da house. That should be a good-enough testing bed for the near future. Furthermore, and partly driven by the need of a dedicated dev device, my company is now registered as an Apple iOS developer. Woohoo. It took about a week and a half but all in all the process was pretty smooth; no surprises, no hiccups, except the one fear that calling that weird long-distance call to frigging Luxembourg to activate my account could potentially have costed more than the yearly subscription fee of the whole dev program. I’ve heard miscellaneous horror stories about it but my experience was pretty much by the book and I had to listen to the “you’re on hold” song in bad quality for only 20 minutes.

Just before starting the journey back home – hey, it was only five days in the car with two kids and two dogs – I also commissioned Pietari Posti for some new art. He’s got a new web site BTW, check it out, pretty sweet. I had the PSD in my inbox forever, annoying the hell out of me every time I saw it as my fingers itched to put those sprites into the spritesheets and finalize some effects in the game.Ā But now it looks like I get to


the game for real on a real device for the first time! And I promise, this blog will get at least




no no, no,


better in the near future!

Screenshot Saturday #2

Yay! Another screenshot – looks like I could make #ScreenshotSaturday a habit! Of course I will, but the game is still in-game mechanics tuning stage, so it does not lend itself very well to fancy screenshots. Rest assured, there will be much more revealed about the game once we get into the art finalization.

Since the last post the game has sprung from being a prototype into a full-fledged game-in-development. I’m very satisfied with the progress – of which a big part isĀ my progress, meaning how well I progress in becoming a game developer. I think I got both Cocos2D and Box2D pretty well under control by now so I can concentrate more on the game mechanics tuning itself instead of figuring out objects and classes of the said frameworks. I’ve got no formal (commercial) experience with game design & programming so I’m still a bit vary about how my ideas will be on-screen. As a game concept designer, however, I have no reservations of my talent, none whatsoever. I’m most awesome in that, hence the jump into independent game development, right? šŸ™‚

Small digression permitted, I looked into Sprite Kit which comes with iOS7. Apple has clearly noticed that their platform is excellent for gaming and to push in a nice 2D framework for game making is an excellent move. I’m not overly happy with the lack of documentation for Cocos2D, and what I’ve read on Apple’s site, Sprite Kit is essentially a full Cocos2D-like framework with nice, vast documentation and most important, excellent integration of the other iOS parts – as an example the touch input handling, which seems to be kind of aĀ hack in Cocos2D. I mean, the touch moves like two-finger rotate, pinch, zoom-out, multi-finger swipes, are all a central part of the Cocoa framwork and hence they should be easily available also for games. Ending this digression, I have a new game idea which I’m eager to start coding on, and with the introduction of Sprite Kit, I decided that it will be my next game while I want to get my feet wet with Sprite Kit. May my other ten-or-so awesome game ideas forgive me and stay put on my To Do-list.

Oh, I almost forgot the screenshot!

Box2D debug lines are STILL sexy!

This week’s coding had me improve the shapes of the playfield in Box2D. By building the playfield out of sturdy polygons instead of b2EdgeShapes I got rid of an annoying issue, known to many – the “tunneling” of sprites though the walls, if they are shot against one with enough speed. You can also see a timer on the left, with a particle effect, one of the basic features I have been tinkering with. I bought Particle Designer 2.0 as the integration of particle effects it produces is so straight forward. So far so good, but none of the added FX are final, and there are many more to do. You can also see partly faded-out score multiplier sprites if you pay attention – also a basic feature (not only for this game, but for game programming in general), which I needed to get my head around.

I also programmed some game state logic (welcome back to my life, singletons!) which allows me to test the game mechanics more thoroughly – there are rudimentary “game starting” and “game over”, and some in-between states so the game is, for the first time, playable. Big milestone, pop the champagne!

The game mechanics still need tuning. A lot. Seems like the game would be much more fast-paced than I anticipated, but it might just be my parameter setup playing a prank on me. Luckily this game is no up-front-written-specifications-monster – I go with the flow. That has already resulted in a few completely new, nice features which most likely go into the final game.

I love the creative freedom. Peace and out!

Information for Geeks

Alright boys and girls. You can also create a game. What do you need for it? Well, I have no idea, but I can list the tools I use. I guess you have to put in some talent in programming, art, and game design, but other than that, you can probably just download some frameworks and tools and get going.

Fellow game developers seem unreasonably interested in what goes on behind the scenes of game development, so here goes. Nothing fancy, I tend to pick out the “best practices” by just googling around. You know, top hits and what seems to be most widely used.

  • Game engine: Cocos2D with the all-awesome Box2D physics engine. I’m not very interested in flame wars on what engine is the best – such discussions go into the same category as “which programming language is the best”. You can always spot an amateur from those statements. Every seasoned developer knows that the answer is “whichever you know best“. Ā If you don’t know any, well, then it does not matter which you choose. None of the “best of breed” are bad.
  • Lower level stuff: Macbook Pro 15″, Mac OS X 10.8, XCode 4.6. I develop games for the Apple mobile devices, hence.
  • Photoshop Elements 11 for miscellaneous art stuff, but I don’t do the main art, I just fiddle around with the awesome art from Pietari Posti
  • TexturePacker for optimizing the sprites. This is one hell of a good tool, very nice integration into Cocos2D (and several other engines).
  • PhysicsEditor for creating the bounding boxes for the sprites. This is also hell of a good tool, very nice integration into Cocos2D (and several other engines).
  • I have not yet, but I am with utmost certainty going to use Particle Designer to create particle effects into the game. The tool has just released version 2.0, which is supposed to be an excellent improvement to version [Update: I bought it the next week.]
  • And depending on the artzy need, I will in the same go go with Glyph Designer for font creation, because, why not.
  • Sounds. Now, this is an area I’m unfamiliar with. I see, at this stage, no reason not to go with Cocos2D’s internal sound engine. Please correct me if I’m wrong. (My sound specs so far: sounds and music have to be AWESOME!!1!)

And that’s it, ladies and gentlemen! The list is actually not that long, now that I’m looking at it. Which must mean it is easy to do computer games!

Screenshot Saturday #1

Ah, my first #ScreenshotSaturday! I remember it like it was yesterday…

The drafts from the game art experiments are only for trying out game mechanics. And the prototype is not THAT far yet, alas, I present you one lame…ish screenshot from the prototype! There’s not much you can conclude from this screenshot but let’s leave it like that – future posts will present the game in much more detail. I haven’t even released the name of the game yet!

Box2D debug lines are fancy!

This week I’ve been playing around with TexturePacker and importing the sprite sheets into the build. Excellent tool, by the way, highly recommended if you’re into 2D game development. I particularly like the take the guys from Frogmind have; use as much as possible existing tools, don’t bother developing your own (unless you are aiming to be a tool developer, duh). This is particularly important for small indie teams. Focus on the game mechanics, storytelling, and game polish.

Now that I have a company there is also another aspect of these supporting tools. And that is the supporting of the tools. I’ve gone the whole circle of using warez only (in my early days), moving to free/open source (last 10 years), and now, finally, buying proper licenses. I mean – I can charge like $80 and hour when doing some subcontracting in my previous industry – what kind of excuses can I have for not buying a great tool for $29? Or for $119 for that matter? None. On top of feeling great by supporting fellow coders, there is one ethical rule that trumps everything in this matter: if you are a developer and aim to get your livelihood thru your coding, you cannot use pirated software to do your coding. Especially if you’re a company. Else, that would be like, uh, dunno, awkward and double morals and bad stuff. So buy your licenses or I bomb your country!!1!

Furthermore, this week has been a bit of “architecture” and clean-up. Think “what should I put into a new class, what should I just dump into this big ugly Layer class? I need to get this prototype further – quickly“. So I ended up moving around and renaming properties and classes – having that “HelloWorldLayer.mm” in there is a bit embarrassing. However, every coder knows it’ll ruin the night if you cannot get anything visible done. So I got also a Box2D body moving around according to some states in the game. Felt better immediately!

Alrighty then. I’ll remain with best regards, chilling, coding, and hey, follow us on Twitter! Please! Please? Thanks, dude, you’re awesome! Just like me. We’re awesome, we should hang out together!Ā On Twitter!

The Oggiput

In addition to the Kisau Veelas, the other character in the puzzle game is this bone-headed guy,Ā the Oggiput.

Da Oggiput, yo!

He sure looks like one grumpy guy who will mess with your game, so you will probably want to get rid of him as soon as you spot him. Who knows what kind of damage he will otherwise do to your new high score you’ve been hunting for the whole morning in the bus on your way to the office? Squash him like the bug he is!

Or maybe he is just misunderstood. He can’t help his rather scary looks and thick skull, clinking into everything in his path. Perhaps he has a heart of gold. Shall we forgive him?

But then again, the Kisau Veelas do not seem super eager to meet him.

Kisau Veelas not diggin’ it.

I’m a bit puzzled about this. Tee hee, puzzled by a puzzle game. Who writes this stuff?! You’re fired!

Meet the Kisau Veelas

“An indie game developer does not exist before he has some screenshots posted on his blog”, some ingenious game developer said. I think it was actually me on Twitter. Anywhoo, I am pleased to introduceĀ the Kisau Veelas to you! These funny guys are one of the main characters in the upcoming puzzle game.

Hit play to play!

They’re a bit shy in this start menu image above, but they will get used to you.

Falling down. Without Michael Douglas.

Ā And goes without saying, these are only the first drafts of the style and characters of the game, by no means the final art of the game. But look at this one on the left go! Whee! Awesome.

If you are curious on who made these, I shall proudly presentĀ Pietari Posti, easily one of the best current illustrators in Europe if not in the world. His illustration style is kinda art nouveau- and art deco-ish, which I’ve always liked in print – to the extent that I have this style of posters, which I’ve hunted down on my travels, framed on my wall. Not from Pietari, though – yet.

We’ve got a bunch of these Kisau Veelas, and about six of them are going to make it to the game. Furthermore, there will be another boneheaded character in the game which we’ll present in later posts. Also coming up in later posts; more about the game itself. It would be rude not to write about the game itself, huh? But for now you have to settle with another draft of some of the Veelas, here you go:

Ooga and booga? No.

Excellent. I like these.