Blog

From time to time, I have a thought or two I might want to share, and I hope I'll find the time to write them down...


2016-06-28 · Alter Nordfriedhof

Around September, we will pack our stuff and move to a different (calmer) neighbourhood. We enjoyed living in Maxvorstadt for 6 years and we're happy to move on.

I will, however, thoroughly miss the old northern cemetery - it's such a beautiful place that breathes art and history with all its old graves where knights, lords, royal privy councillors, professors and more people of strange and long forgotten professions have been buried. While being here I often thought about making some kind of paper chase game for the location and now that I'm leaving I came up with an idea that is minimalistic enough for me to build in my (no longer existent) spare time: It's a mixture of paper chase and geocaching and it gives you time to contemplate and observe. The graveyard itself consists of 4x4 parcels, and I made up a riddle for each of them. The riddle describes a certain gravestone - once identified, you check the inscription for the first year that occurs and enter it to proceed to the next parcel/riddle/gravestone. I love the simplicity of the idea together with the (potential) depth of the riddles. I also love how easy it was to build it with Unity - I was even able to do some polisihing and include GPS coordinates. For now, it's still work in progress, I'm heading for a release in Google Play next week or so. As my farewell gift for the old cemetery and everyone who visits it, it will of course be free. Anyone interested in some riddle solving can join the beta here - I'd be grateful for feedback.

2016-05-01 · The year of VR

It's the year of VR. Oculus, Gear VR, Playstation VR, HTC Vive and others are going to change the way we play. Or will they? Well, while VR obviously has the potential to dramatically increase immersion (or create 'presence') on the one hand, it's pretty unclear to what extent games (or their designers) will be able to pick up on the new medium and its constraints on the other. Over the last ~10 years, mobile has taught us that it's by no means possible to simply port successful concepts to a new platform (just look at the tons of uninspired virtual stick games to get my point) but that it is instead necessary to create new mechanics that are optimized for a new medium. And mobile also taught us that games (resp. companies) that manage to overcome this obstacle (like, e.g., Fireproof did with 'The Room') will thrive.
Now as VR hardware is (in contrast to mobile hardware) still relatively expensive it aims (as far as games are concerned) for core gamers first of all - simply because all others will hesitate to buy it. On the other hand, the typical core gamer genres (FPS, RTS/MOBA) are almost unportable to VR (or at least don't really profit from it) and even those genres that are (like racing or flying games) will suffer from the fact that it's almost impossible to play for several hours with today's VR headsets. It's just too exhausting. So the fact that it's already hard to design good (slow paced) games for the new medium in the first place will probably be aggravated by the fact that casual players that would probably enjoy such games (like, e.g. 'escape-the-room-games') might have no VR hardware to do so.
On the other hand, the most impressive footage I have seen so far wasn't interactive/game footage anyway: 360° Movies have a steady frame rate, don't expect you to react on anything and thus provide an overall-enjoyable experience over hours. The Oculus 'Weclome to VR' trailer shows off how well VR works if you disband the problem that interaction is exhausting, user attention is hard to control and frame rate is an issue for VR and just use it to display documentary movies, AAA prerendered CGI movies or your own footage of your children or your holidays. As a consequence, I'd say, VR will change the way we watch movies long before it's going to change the way we play. For game designers this should, in my opinion at least, imply that we should first try and copy what films do (i.e., provide a passive, slow-paced experience) and then gently and patiently try and add interactivity and see how it does. Integrate 3d steroscope photos and movies in Game Engines and augment them with simple mechanics that don't waste user experience by overstraining them. See what works and what doesn't and that add some more of what works. And at all cost, avoid the virtual-stick syndrome that mobile games suffered from. Upcoming winter semester's suggested bachelor thesis topics include UX-augmentation resp. gamification (my apologies) of photospheres and stereoscope videos in Unity/Unreal, using VR for clinical studies and using Kinect to emulate head tracking for Google Cardboard devices.


2015-12-24 · Christmas and the new year

Merry Christmas! It's christmas eve and my parents-in-law are taking care of our daughter, so I can... wait, didn't I say I'd publish the incredible baby timer app before wasting any more time on blog posts? That's true and in fact two days ago 'Easy Baby' (it was hard to find an app name with baby in it that wasn't already taken ^^) hit the appstore and play store.

I won't put any efforts in marketing it, so I don't expect many downloads, but an app project isn't finished until it's in the stores and I wasn't going to start new projects without finishing old ones first. I hope I'll find some time to work on either Condemonium or Space Odyssey in the new year beacause I really do miss my beloved indie projects.

2015-10-16 · Tommi Kindersoftwarepreis

Today, Knard was awarded with the german Kindersoftwarepreis Tommi.
This makes me a happy chappy, especially because, even though the nominees are selected by an adult panel of 'children software experts' the final winner of each category is selected by a jury of children. And who would know better what's good for children than... No, wait, you've had enough icecream for today!
Anyway, I am really happy that the kids seem to love what was made for the single purpose of making them happy, and this feels more rewarding than any review so far.

It also makes me terribly aware that the time of indie development seems to be over for me for the time being. With my lovely daughter keeping me busy, my indie output is converging againgst zero and I haven't even managed to publish my BabyTimer app. So here and now I promise myself that I will do so before writing another blog post. :)

2015-08-20 · Baby Timer

Once again, I am on parental leave - meaning I have two hours spare time a day and the largely unsatisfied urge to code something. When your child is old enough (~ 2 months I'd guess) to follow a clear pattern of eating and sleeping every x hours you'll want to make notes to check when he/she last slept/ate in case his/her mood changes. At least in our case we found that this mix of scheduling and on-demand resulted in a super-happy baby (fingers crossed to keep this status).
While making notes 10 times a day is not really satisfying it's a necessity because sleep cylces of say 120 mins and eat cycles of 90 mins start overlapping/interleaving after half a day. In a way that's gonna drive you mad!
So, when our best friends were expecting a baby, I thought, why not pass our distilled parental knowledge on to them, guised as a present: The Baby Timer App...

The app let's you tap buttons on the lower right, whenever your baby eats or wakes up. You can drag them left and right in case you forgot and add a time point late. The timeray evolves to the right over the day and you can always see with a single glance (that's what it's all about) how many minutes your baby is still 'fueled'. Disclaimer: I am well aware that a baby's no machine, and the app isn't meant to inform you *when the baby needs food* but rather to allow you to check *whether he/she is likely to be hungry* when he/she seems unsatisfied. When I started out creating the app, I didn't (of course) count my tendency for perfectionism in. But luckily the project's scope was tiny enough project to get it done amongst all the things I had to do over the last months - and still allow me to push it to a level where it now provides a quite enjoyable user experience. As I was going to make a basically UI-only application I decided to hits two flies with one squatter and acquire some experience with the Unity UI features that were added last year - so I made the whole thing using only Unity.UI which was a very pleasant experience overall. The Unity staff did a really great job with the UI features: with scroll rects, draggables and anchors, things came together perfectly for a large variety of android and ios devices. Just recently, Anna replaced my coder-dummy-UI with real assets and our present is about to be 'shipped'. Once this is done, I'm probably gonna publish it for free on Android and iOS for other parents...

2015-07-01 · Google Deep Mind and Game AI

Earlier this year, Google Engineers published results about an neural network that was able to play old Atari games. The clue, however, was that this AI hadn't be designed to play those particular games, or more precisely, not to play Atari games in general, either. Using reinforcement learning (a technique that is basically just trial and error in the start and becomes more sophisticated with every try) Deep Mind learned to play games on its very own.
As input, it received a video stream that was produced by the Atari. As output it was allowed to create simple joystick commands (steering direction + two buttons) that would then be retrieved by a virtual joystick that sent the corresponding signals to the Atari (or so I guess, without finding further details about this on the web).
Google published a list of the games that Deep Mind tried to master together with information how well it did one the various games. The results range from '20 times as good as the best human' to 'totally shitty, as bad as a blind monkey'. While the former have been widely picked up and hyped by the media, the latter seem to be widely ignored. And while I don't doubt the achievement itself (they made a generic AI that learns tasks on its very own, only being fed by a videostream) I don't like the way people focus on the numbers mentioned above (they made a generic AI that is 20 times as good as the best human...). An AI that is 20 times as good as the best human in breakout does not have to be smart, as mastering breakout obviously depends on reaction and precision much more than it depends on brains. On the other hand, if the consumers focused more on the games where Deep Mind failed, they might learn so much more about the restrictions that reinforment learning suffers from. And if they did, there wouldn't be so many discussions in gaming forums about whether 'we will soon have super smart cops/criminals/pedestrians in GTA' (and which made me write this post in the first place). The question to these discussions is plainly: No. We won't have super smart whatsoever relevant game AI that is driven by a neural network (or a neural turing machine, i.e. a neural network that has a memory). One reason for this is the fact that reinforcement learning can only be successfully applied when action and result are closely related (timewise).

That means, if the AI gets a point within a short time-window when catching/bouncing off the ball in Breakout it is rewarded. If it doesn't, it is punished immediatly by losing the game. So it quickly learns that is has to prevent the ball from leaving the space, to continue playing and earn score.

In other games that are more complex and yet by far not as complex as today's blockbusters (e.g. Montezuma's Revenge) the actions (moving the joystick) and rewards (getting points) are much more loosely connected. The AI makes 0% w.r.t. to a human player here. The reason for this disastrous result is that trying random actions with a joystick won't earn you a single score point in Montezuma's Revenge. So without ever being rewarded the AI can't learn what's wrong and what's right. It is worth noting that this will be the same for every game that involves any non-trivial boundaries, walls, or even a maze through which to maneuver is part of the game. Wait, you'll say, Deep Mind doesn't suck at Pacman, according to the list it makes 13% (of human skill level). Well, Pacman's streets are paved with score, you could say. Moving trough the maze means collecting points - at least until you did collect them. And doing more complex actions, even like finding its path to a section of the pacman maze where there are still points left to collect is completely out of scope for Deep Mind so far. And that's why it won't stand a chance against traditional AIs (who are presented with a high level abstraction navigation mesh of their surroundings) for a couple of decades.


2015-05-14 · Getting Featured

We did it! Knard got featured on itunes. With over 1000 apps being published on itunes every day this is probably the highest accolade for our storybook and it just feels awesome.
In my last post about visibilty I wrote about how I think it's important that you put all your love in your product (instead of slapping out app by app) so that you'll have the required endurance when it comes to promoting it. That being said - after writing over 500 emails to almost everybody who has an audience that intersects with our target audience, I was close to calling it a day. Instead of further trying to promote Knard, I was going to do the English loca. Not to increase the audience (there are plenty of german-speaking people left who could buy it) but to ease my PR efforts which suffered a lot from having created a german-only App:
It hadn't occured to me earlier but it's very diffcult to promote a german-only app for children, mainly because the top blogs, website or magazines you'd want to contact to do that, are American.
However, I wanted to try one more thing after having read this article on reddit. I wanted to use all those great reviews - which I had accumulated by harrassing mom-blogs and magazines, cf. the Knard website - to convince apple that Knard was worthy of a second glance. I wrote an email to appstorepromotion@apple.com in which I told them how 'magical', 'outstanding' and so on our app was, giving them a weblink with each quote and suggesting they should have their german colleagues look at Knard.
Some weeks later, I received a very short response that my email was 'forwarded to someone appropriate' and not long after, a friend of mine found Knard featured on the Appstore.
Sales have risen by factor 15 or so, taking us into regions where we finally get some money for all our efforts. The greatest thing about it ain't the money though, it's the endorsement that every indie developer yearns for, together with the knowledge that so many children out there are now going to get to know Knard.

So what can you make of all this? Well, even though I admit I didn't plan things this way beforehand, but rather built this strategy on-the-go, I still think the whole thing might be a well applicable strategy for indies. Just writing to apple's promotion adress probably won't do you much good if you can't tell them anything essential. And they won't be suprised that you like your own app. So why not start out contacting every blog and website that might be interested in your topic, provide them with a quick glance at your product - I used the Knard trailer - and ask them whether they're interested in a promo code. If they love your app they'll come up with a review that you can cite on your website or the appstore. And once you feel like you have enough of them (hopefully positive ones), write a nice email to apple mentioning those. I think it's obvious that they'll pay more attention to what others say about your app.

2015-03-17 · Visibility

Knard has been on AppStore, Google Play and Amazon Appshop for 3 weeks now and my parental leave has started. It's time for an early résumé!
When people talk about their awesome indie games, the first thing that'll come up in the discussion is 'visibility'. Will your game/app (even though it's oviously awesome) be found in order to be bought?
I've been doing a lot of PR in the last few weeks. I emailed mum blogs, parents web magazines, parents print magazines (mostly local ones) and my feedback so far has been great. A lot of very nice people have answered my mails, even installed TestFlight and mostly found Knard to be an awesome app. A high percentage even promised to write an article about Knard and thanks to those people Knard got some visibility in the first place.
Lessons learned?

  1. Someone once told me that it was all about getting apps published quickly (instead of working on them over years when you have no idea how they will be liked by their respective audience). This statement made me (to some extent) doubt my own approach of creating something highly polished in the first place, and I still dont know which is the better way, but i know this much: If you consider visiblity the greatest hurdle, make one polished thing instead of many prototypes. It's much easier to go through the tedious process of writing a hundred emails if you already invested ten times as much in the quality of your app in the first place.
  2. Don't overlook whole categories. The first 'category' i adressed was mum blogs. The second one was general app 'tickers', and finally after not receiving answers from the two big german familiy magazines, I found that the many smaller local parent magazines where a good idea to address. And many of those (every big city in Germany has its own) answered me.
  3. Don't try to judge categories. I would have assumed that parent blogs and magzines were most important because their audience would be most likely to actually be interested in Knard. Still, I contacted apps news pages like ifun.de and i was really surprised by the impact they had: being connected with many other apple news ticker pages their news about Knard (which wasn't really enthusiastic and just mentioned that 'nice new children app') was forwared to many other pages and resulted in one day with a peak of 204 sales.

To me, number one is the most precious lesson: Put all your love in what you create and you won't get tired of doing PR, even if you're not the type who likes to adverties your own work. And so far, some nice people's answers have definitly been the most rewarding part of publishing Knard!


2015-02-10 · Waiting for Review

Wow. I finally submitted Knard for review on itunesconnect. Current status: 'Waiting for review.' According to this statistics Knard should have been reviewed two days ago. I suspect that Apple changing the requirements for newly-submitted Apps to include a 64 bit version created a little onrush, so it might take longer than the average 8 days.

Anyway I am really happy to reach this 'milestone' and while Knard is idly sitting on his tree waiting for review I am not: Over the past view days I have contacted a lot of different blogs and websites that discuss and recommend apps for children and to my absolute delight received quite a lot of positive answers. Many nice people want to try the App, most are reacting very positive and some even promised already to publish articles or app-tipps that mention Knard. Submitting an App to itunes is quite a pain, after recording a video with fraps, I used virtualdub to resize it to four different resolutions, converted each of them to mov and when trying to upload them I was finally told I needed OSX 10.10 to upload a video. Where they kidding me? Am I kidding you? Sadly, no! Why they wanted me to download several gigabytes to update the operating system just to upload a video is beyond me. Luckily, other people seemed to be as unwilling as I was to follow the laws of the crazy king (Apple) and I found this exquisite hint for a very short and smooth workaround that I am happy to share with you: Just turn developer mode on in Safari and tell it that it's running on OSX 10.10 and everything works out fine.

Oh, and just minutes after writing this, my app is now in review. HEY APPLE I KNOW YOU ARE READING THIS!!


2015-01-10 · Unexpected Obstacles

I really wanted to have Knard submitted for the AppStore by the end of 2014, so I spent the days after christmas polishing stuff and fixing minor bugs, pulled the latest versions of libgdx and robovm, built a new version for ios and - BAM - experienced a crash after right after starting on iPad.
The app showed the loading screen and the cover but when I flipped to the first page, it crashed. Now what? With robovm still lacking the possibility to debug my code on ios I was bound to trial-and-error-debug and it took me almost a whole day to figure out that asynchronous loading of music crashed the app.
I created a new example project that did nothing else but create an assetmanager in libgdx, load a piece of music asynchronously and play it, which worked on desktop and android but crashed on ios.
After having found the issue I was able to properly search the internet for it and found out that the libgdx/robovm guys had recently documented the issue on github but were not sure which of the two frameworks were to blame.
Niklas, the guy behind robovm marked the issue as fixed shortly after, and according to github, using the gradle snapshot version of robovm should do the trick.
Right from the start my biggest problem was that my app made plenty of use of async music loading for the narrator while most other indie apps just need a main theme that is loaded (synchronously) when the game is started. Worse than that, the few others that had reported the crash said it only occured when the used a certain release of libgdx/robovm, while in my case it now even occured for older projects for which i hadn't even updated the versions in the gradle build file. I spent several days discussing possible issues on libgdx irc and trying pretty much everything (installing newer versions of xcode and eclipse, updating eclipse plugins, deleting gradle caches and so on). Again and again, i was told that the issue had been fixed and I was very close to installing my whole setup on a second Mac because some kind of cache (obviously not the gradle cache which i deleted several times) had fucked up my build pipeline. And the fact that my issue occured for older procjects that used libgdx 1.0.0 and robovm 0.0.14 and that had once run smoothly left me without a clue.
Luckily, the fucked up holidays ended and I had to start working again, which left no time for that robvom issue. And two weeks after the issue had initially been claimed to be fixed, there finally was a new robvom eclipse plugin. Installing it instantly fixed all my problems.
Once again I learned a hard lesson about wasted time, trying to figure out stuff you can do nothing about and how bad it can be to depend on other peoples software (even if those people are outstanding programmers).


2014-12-16 · Content-complete

Yay! Knard is finally content-complete. In other words, all animations, sounds, particles, lights, narrator- and music-streams, all ui-stuff, even the credits - everything is in there waiting to be published on google play and the app store.
Here's a snapshot of what stuff looks like in my custom book editor:

The red and yellow stuff are triggers (that listen for taps or items being dragged or a page being flipped or physics objects) and effects (mostly animations, sounds and such things) that are performed by those triggers. I am pretty confident that I'll be able to do some polishing, bug-fixing and testing on older devices (and iOS of course) over the holidays so I'm hoping to finally release the app in January.

2014-11-13 · Distractions

Long time no write. I am presently facing far too many distractions, fortunately most of them of a positive nature. I am very busy with my new job at MDH, giving lectures one day at a time, and preparing upcoming lectures on the run. Also, I resumed work on Knard, mostly because respected friend and respected artist, Hennes, finally found the time to complete the artworks. While 50 pages with high quality illustrations was probably a bit overambitious, I am now postitive that we can release Knard before christmas. Besides, my 4 months old daughter, Juna, is doing her best to keep me occupied. Given these suboptimal circumstances (only from an indie game developer perspective of course), I really enjoy this very special time and I actually do get some shit done besides: Polishing Knard is something that has to be done in the end, and even if I can't really do big steps project-wise, it is quite cool to do some animations, and sound effect editing in the late hours.

In this context, I would like to point out the very unique 2D animation tool Spine to those of you, who don't know it yet. Check it out, it's the best choice for people who want to create 2D animations but don't have an artist background that you require (at least to some extent) to do such stuff, e.g., in Adobe After Effects. It's very accessible and that makes it fun for programmers who can use it do prototype their own UI animations and end up with real mesh deformer animations like the laughing troll king on the right.. What's more, in contrast to after effects you don't just export gifs (with shittish quality) or sprite sheets (that use vast amounts of memory) but instead Spine comes with backends for various engines (LibGDX, Unity, and many more). That means you just export a single texture plus information how the texture is triangalized via vertices and a json file that stores the animations (via keyframes for the vertices). Memory-wise, that's a whole different story than using sprite sheets and especially when developing for mobile that's a really big deal.

2014-09-18 · Space Odyssey Version 0.01

Time for the first pre-alpha release :). I have implemented a lot of stuff, the skirmish mode is basically content-complete, (but still totally lacking balancing and polishing) and I have prototypes for the first one and a half missions.
So it's now or never to get some input about what others think about the game. I am aware that there are gameplay 'issues', they have been there from day one: I have redesigned the touch control input from pure virtual analogue stick to point and click move commands (like in RTS) and partially back to throttle + direction. So far, none of the solutions felt really convincing to myself. And while the gameplay is quite exciting in 'late game' will it be interesting enough in the first missions when you see only a small part of it. Also, I am expecting to face technical issues when testing on a wide range of devices.
Anyway here's a first version for testing, I am grateful for any input, gameplay-related or technical. If you have anything to tell me, please go ahead and contact me...


2014-09-12 · Artstyle

I love black & white. Not the game, the lack of colors for art in games. That might have to do with the fact that everytime I use colors it gets coder-ugly but nonetheless, many black & white games (LIMBO, e.g.) do have a very adultish and beautiful look. So when I first started out with all this, of course I made iconic ships (that also had to do with their very restrited size, some are as small as 32x32 pixels) and I made them black and white.
Now that I started the campaign and made up its very crude and cliché story (aliens destroyed earth, you're in your rocket looking for a new home...), I started to ask some friends what else they'd suggest art-wise. One of them told me that the iconic style was good, esp. for my (as mentioned) small entities, but that a little bit of a retroish look wouldn't hurt.
Now as far as pixel-graphics are concerned retro has really been beaten to death, but he was referring to shapes of stuff and dropped Bioshock as a reference. Once I dug a little into retro spaceships it occured to me that there is a whole retro sci fi community with an (in my opinion) absolutely amazing and unique art style that reminds me of old arcade machines. I couldnt think of anything better to raise exctly the right expectations in the potential audience for space odyssey that I am hoping to satisfy gameplay-wise...
But enough talk, just click this google images search example and see for yourself...


2014-09-02 · Campaign

After throwing together quite a lot of interesting ideas/features I have something I'd call a game. Even though its different units are far from balanced, even though input is far from polished and even though its not half as accessible as I'd like it to be, the gameplay is nice and quite fun if you know how to play. I was even thinking of releasing a prototype to get some early feedback but accessability is still an issue and I wasn't really satisfied with my tutorial.
Now one of the advantages of having an 8 week old daughter is that she keeps you awake during the night and allows you to think about your indie projects. Last night, when trying to get her to sleep the solution jumped right at me:
Instead of a (rather boring) tutorial that is cramped with information, I will go the (hard and lenghty but promising) road of developing a set of missions to teach you the game. That way I can include my little story ideas I had for the game in the first place but without having to center the game all around the story mode. Once you finished the campaign and know the mechanics, the Skirmish option is unlocked.
I hope I can quickly come up with some missions and that the whole process helps me to sort out balancing issues, so I can soon submit the game to google play for something like an open beta...


2014-08-30 · Humble Store Space Weekend

Always on the lookout for inspiration I was stunned when I looked into my emails today. Fate obviously decided to throw me a bone! The humble store space weekend is here and I expected to find loads of inspiration (and the chance for competetion analysis) so I checked out all the games that were listed there.


In the end, even though there are some nice looking games among them, and you can always get inspired by art style and the use of UI, I was disappointed to find not a single 2D game in the offer. On the other hand now I don't have to play stupid indie games but can instead focus on programming my own stupid indie game. Take that, fate!


2014-08-07 · AI Patterns

To have nicely configurable enemies, I started out with a java enum that has loads of parameters for each enemy type (and I intend to move those params to a txt-file later). This enum included the firing rate, the bullet speed, the velocity, health and so on for each enemy.
AI on the other side started very prototypic: I just had a controlling AI class for enemy ships that looked for the closest enemy planet as a move target, while checking for the player ship on its way there to fire at it if in range.
While this behaviour was static/prototypic or even hacky (I like to play around with ideas and include , e.g., a few switch case statements) I recently transformed it into something more elegant.
Any ship AI (allied as enemy) now includes a priority list for its movement target and one for its firing target selection. Enemy fighters, e.g., move towards the next enemy planet and their prio list for firing is: (enemy planet, enemy player ship).
So while the fighter moves towards the enemy planet, it will, in each framewise update of the AI class, walk over that prio list. If there is a corresponding target in range, it will break and fire at it. This implies that a fighter that is on its way to your planet (but not yet there) will fire at your ship if you come close enough. However, once it has reached your home planet, it won't try to attack your ship, but instead fire at the planet.
That simple priority pattern allows a nicely readable and maintainable implementation of enemy behaviour. A fighter that only wants to attack your planet and ignores your ship on its way their sucks. A prio list deals with that. Also you can play around with the priorization:
A stronger fighter unit (with homing missiles, e.g.) could priorize you over the planet, because - unlike the fighters - it can really do damage to your ship. The move target prio list allows for characteristic behaviour, too: A hunter unit can just priorize your ship over your planets, i.e. it would seek you out. But once your ship is destroyed and takes time to respawn it would (without any additional code) use your next planet as a new destination and fire at it until you respawn.
Now all I need to do is add an enum for AI behaviours and configure them with prio lists (simple arrays) as parameters and add a behaviour to each enemy - which I can even replace or modify on the fly.
When coding AI, keep the code small (which makes it maintainable and debuggable) and unless you are very experienced, absolutely do all sorts of debug visualization right from the start!


2014-08-04 · Content Pipeline

Looking at my progress I have to say I am quite satisfied with the content pipeline I have established for the game:
Spine and LibGDX are going hand in hand out of the box. The ability of Spine to give names to bones and look them up in the game makes it easy to denote, e.g. a barrel (that is rotated towards the firing direction)or a barrel-exit (that is used to spawn bullets) that can be easily accessed and used in the game code.
When

I add a new enemy, I just name a barrel in spine, give it an idle animation and the (still rudimentary) AI moves it from A to B (B is your home planet) and lets it fire. However, enemies need physics (mainly for accurate collision detection) and all I need for that is a png image and Aurelion Ribon's Physics Body Editor.
So beware: The next enemy type is always just a few clicks away. :)
To round this up, particle effects are easily added with LibGDX's particle editor, and I added a computer voice to comment on whats happening ('entering gravity field', etc.) via the free version of this text to speech software.


2014-08-01 · Enemies

What started as a cute experiment of a rocket travelling from planet to planet soon turned into an arcade game with enemies.
With Box2D (which is integrated in LibGDX) at hand, I couldnt resist the urge to implement some little enemies that fire lasers at you and your planet.

The overall style of the game is cartoonish (or iconic?) enough so that it won't feel to much like a war game. And anyway, I loved 'Starship Troopers' so let's forget about moral standards. Anti war game ftw!
I added some asteroids for the atmosphere, some crates to collect to emphasize the effect of gravitiy fields (because its always fun to collect a crate, getting stuff in life is never that easy). I like homing missiles, so I added them and they nicely make up for the lack of control precision that you have when steering with a virtual analogue stick. All in all, shooting enemies is fun and I am hoping to build up the atmosphere of a (not all-too-serious) intergalactic war.


2014-07-25 · Emotional Prototyping

My usual approach of getting something really, reeally right is the following: First, I exagarate doing way too much or way to little of it.

Then I adjust from both sides, to get it right. Not like a binary search where I would try the center value, but rather moving those to extrema closer and closer to the center. E.g. trying to get the right shade for a UI item, I'd start with black and white. If I started with grey, I might be ok with my solution too early, never noticing that a little darker would have been better. Ok, in this case the whole process has to do with the fact that I am a zero as far is art is concerned, but the approach does work for me in general. After trying to design games from a very gamedesign-theoretic point of view, putting all the focus on mechanisms (rock, paper, sciccors, etc.) I lately found that there is a totally different approach that seems promising: Gamedesigners will tell you that your vision is all about the feeling of the game and that you have to keep that vision up throughout the process. So instead of building a design concept around the vision of the feeling I wanted to evoke in the player, I thought I could as well 'collect gameplay situations' that evoke this feeling. Aiming for a lovely lost-in-space-and-time feeling I started to prototype some game around some cute iconic rocket that is attracted to planets by their gravity and that can land on them and take off again. My working title for this game to come is 'Space Odyssey' and I am curious where putting together pieces of nice stuff will lead me..