2016 retrospective

It seems I negleted this blog for most of the year. Upps.
I'd love to say "I was working all the time behind the curtains, just did not have the time to write posts here" - and I actually had a few projects going that I was working on very regularly. But then Overwatch happened and my hobbyist programming went down to 0.

So let's have a short look at what I was working on this year, have some early New Year's resolutions and maybe even some deadlines to miss becasue those are always fun, right?

tiny GIANT planets

Once upon a time I partcipated in the libGDX jam and created a small, unfinished puzzle game prototype where you shrink/enlarge planets to redirect streams of stardust using the planet's gravity forces. It was called tiny GIANT planets and you can play it on itch. My original plan was to

"develop it fruther in a private repository, add way more content, more / nicer assets and release it commercially on PC and Android later this year"

which of cause did not happen, at least not the "release" part. I continued working on it, cleand up the code, made it run on Android (as in "it starts and is a bit interactive, but not quite playable") and reworked the engine so the physics stay constant on devices with very low framerate. For that you have to fix the timestep in your game (which sadly is something many AAA studios still don't :/ ).
To be able to do that I had to fork Ashley (the ECS that I used) and provide a possibility to run the physics systems in a fixed timestep seperatly from all other systems that still use the delta time. There was some nice discussion on the pull request but it sadly died down without a real conclusion.
After that I struggled to come up with a GUI that works in small touchscreens and finally lost motivation to continue working on this project 😞

XPLOSIVE

In april, the lowrezjam happened. The most important principle there was "have a resolution of 64px x 64px". My thought was "I'm curious if you can fit a 4-player bomberman clone into this resolution". I knew that with the time constraints and some other stuff going on I won't be able to have anything playable for the jam itself so I did not officially enter it. But I started a project and just continued worling on for a few weeks - it turns out you can fit at least 2-player bomber man in 64 pixels.

I plan on finishing this game pretty soon and releasing it on itch for free.

Server registrar

I hate it when you have to set up port forwarding to play games with your friends over the internet. The obvious way of dealing with it is running official, public game servers - but that can get very expensive very fast and it also kills online play when you decide to shut down your servers.
I looked for a solution to this problem in many places and found a technique called NAT-punchthrough. You still need a central server for that but it only has to deal with "introducing clients to servers" so in theory it does not need a powerfull machine, maybe an aws micro instance or a respberry pi could be enough.
I found a few blogs where programmers talked about their implementation and they all seem pretty similar. That's what brought me to the thought "hey, let's make something generic, that you can easily use with your own game without having to implement it by yourself". So I started work on something that in its final form you can put on a low-end machine, point your game to and have NAT-punchthrough "just work".
There a re a few milestones for this project (or its scope) and they all have a probability of happening:

1. Working for XPLOSIVE. Probability: very high - if I'm not able to do this, then the whole project is basically doomed, so let's just say I'll do it
2. Usable for games using KryoNet. Probablity: high - XPLOSIVE uses KryoNet for networking stuff, so this step might almost come free after step one
3. Usable for games made in Java: Probability: medium - Java sockets... enough said
4. Usable for PC games made in any language. Probability: low - This would be so fucking awesome, but right now I'm pretty sure that I lack the skill and knowledge to even start on something like that

Currently I'm pretty sure that reaching step 2 is very likely. The plan for the project is to be released free and open source when step 2 is reached.

Plans for 2017 (and some deadlines to miss)

• 15.02.: Finish and release XPLOSIVE
• 01.04.: XPLOSIVE multiplayer works without the need of port forwarding
• Reach step 2 of the Server registrar project and release it
• Finish and release tiny GIANT planets
• Write a blog post at least every month (has this ever worked for somebody?)

libGDX jam is over!

The libGDX jam is over! Well it actually has been over since three weeks but I didn't get around to posting anything here. The voting period also has concluded and my game made the 58th rank (out of 83 submissions)! I am pretty content with this result - my first game jam and the game even had some unfinished stuff and other rough edges in it! Goal for next year: rank 57!

You can find it here:
tiny GIANT planets on itch.io
Source on GitHub



A few things I learned:

• libGDX is awesome. If you know Java (or other JVM langauges like Kotlin or Scala) and want to create a cross-platform game for Win/Linux/Mac and Android/Ios (HTML5 is also possible but it's pretty limited which libraries you can use) give it a shot. Of course some Java pitfalls apply, so be a bit wary about performance and garbage collection. Also when developing a game that should run on a phone with very limited RAM and CPU power you cannot apply all the "usual" Java best practices like immutable classes or use the Java collection framework (you get high performance collections from libGDX). But besides that I love working with this framework.
• Entity-Component-Systems are awesome for making games. They make the code way cleaner than a object oriented approuch usually would and make adding/altering behaviour pretty easy. I used Ashley which was created for libGDX but is not tied to it - you could use it in any Java project. I wrote a post on how I transformed my object-oriented code to Ashley in my dev-log.
• One small note regarding Ashley: Using a pooled engine instead of the "normal" one may not always result in performance increase. For me it even reduced the perfomance by a few FPS on PC. Here my commit where I refactored the code to use the pooled engine and here I undo it a few days later.
• Podium Free is a nice free DAW. It is not as user friendly as e.g. FL-Studio and not as feature rich but if you don't want to spend hunders of Euros to get a program you can create music with it will do (I like it more that LMMS, at least on Windows). I created all the music you can find in the game with Podium and with free VST instruments/plugins.
• Inkscape is great for creating programmer art. And it's also free. A guy named Cris Hildenbrand runs an awesome blog with tutorials on how to create decent looking game art with it. Also not having a retro-inspired pixelart look can be a unique selling point for indie games nowadays.
• How to use Lombok in libGDX. Project Lombok is an awesome tool/framework/addon/whatever that lets you replace dumb boilerplate-code like constructors, getters, setters with annotations. I created a tutorial how to get it to work for desktop and android.
• How to use Java 8 lambda expressions with android. I created a tutorial here.
• ScreenToGif is an awesome, simple tool for recording your desktop/application and outputting a gif.
• I totally suck at time management. Also it's sometimes really hard to motivate myself to work on the project. I already knew that (at least I should have, looking back at my time at school or during university) but I got some proof for it again. Welp.

My plan for the game is to develop it fruther in a private repository, add way more content, more / nicer assets and release it commercially on PC and Android later this year. The jam version will still be available free of charge on my itch.io page.

libGDX jam

I am taking part in the awesome libGDX jam with the theme "Life in space". As per rules of the jam the devlog of my game can be found here: http://itch.io/jam/libgdxjam/topic/12172/loganthemansters-dev-log
The code of my entry will be published to GitHub.

Mario is finished for now...

This will be the last version of my Super Mario Bros. project for now. I've learned a huge deal and got most of the stuff to work the way I wanted it to. There are still some things missing (e.g. the invincibility star or some eye-candy like the animations for the coin blocks) so maybe I will come back to it again.

Here is the latest executable (should theoretically run under Windows, Linux and Mac as long as you have JRE 8 installed).
If someone is curious: all jars I created while I was working on this project are located here.

There are some bugs you just don't want to fix...

Mario just ate three mushrooms here:

EXCEPTION_ACCESS_VIOLATION

While following the tutorial that I wrote about in my last entry I got stuck on the lesson about spawning items - my game randomly crashed the JVM when spawning a mushroom with a very nice fatal error:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000066bcbd0d, pid=156, tid=7088
#
# JRE version: Java(TM) SE Runtime Environment (8.0_45-b15) (build 1.8.0_45-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.45-b02 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [gdx-box2d64.dll+0xbd0d]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Today I finally had the time to dig into my code (since I don't use Brent's code 1:1, I like to "tidy it up" after each lesson so it adheres to my own standards) and managed to find the culprint.

The problem was in the end that PlayScreen.update() tried to set the boodies of destroyed Goombas active - that caused the Box2d engine to try to access memory that is not available anymore (Box2D is written in C, there is just a tiny Java-Wrapper around it so it can do that).

The solution is something like this:
In PlayScreen.update() instead of

if(enemy.getX() < player.getX() + 224 / MarioBros.PPM) {
                enemy.b2body.setActive(true);
            }

do something like

if(!enemy.isDestroyed() && enemy.getX() < player.getX() + 224 / MarioBros.PPM) {
                enemy.b2body.setActive(true);
            }

For that to work we need to create this variable and method in Enemy:

protected boolean destroyed;

public boolean isDestroyed() {
                return destroyed{
            }

and remove the variable "destroyed" from Goomba and Turtle.

My own current progress can be found here.

As my first actual project I am following this awesome tutorial on recreating the classic NES game Super Mario Bros.
You can find my current progress here.