Games

My only game that lacks a gui, and not surprisingly the only game I've stuck with a single iteration. Partially also due to using a more modular event based system that requires less full system knowledge to work on.

Latest iteration, now written with KorGE. With this go I renamed from Automon to Mechamon, and started using KorGE, the first game engine I've really liked and not felt constrained by.

In this attempt I tried to go for the thinnest possible slice by just focusing on a battle, without a map. I also gave up and used spring and angular to attempt to avoid my gui woes.

Calling this version automon suit reflected my move to the idea of a wearable suit instead of an autonomous bot. Using Zircon for the front end helped me get the map part up and running quickly, but I still quickly became frustrated with building the gui.

My second attempt at this game idea, made in java instead of Unity. This attempt used JavaFX for the UI and played with the name 'core gear'. Also worth noting that this was built before I knew about git, and so the history is mostly lost due to a poor port from svn.

Latest iteration, now written with KotlinJs. Inspired by how nice wildermyth-legacy was to develop. I'm hoping writing html and css will help me more quickly build out the gui layers. Effectively combines the portability of Korge with the web UI I tried in the spring iteration.

An attempt written with KorGE. I really like Korge, but still ran into issues quickly building a UI.

My last commit before moving to KorGE, this version attempted to eschew gui pains by just making a terribly performant spring app and angular web page. While it was much nicer than any previous gui tool, creating controllers and services and web sockets to make it run not only was terribly non-performant, but also caught me up in loads of wiring code. While I find html and css easier to style than KorGE UI, KorGE far surpasses any other Kotlin compatible UI I've used and it's benefits far outweigh trying my ridiculous web hack.

I thought if I could reduce the scope of the game, maybe it would be easier to manage? This burnt out quickly when I still had to fight JavaFX to build a UI.

I intended to create a separate ship building tool from the main game, but didn't get very far.

I thought breaking the project into multiple libraries would help me, and thus learned the downfall of too many micro services.

These saw my move from maven to gradle.

I also moved some of this code to Kotlin once I started learning it.

I also made an effort to convert from Swing to JavaFX.

Ultimately all these services created a web of dependencies that I wasn't mature enough to manage, and my problem space was made no smaller.

I did have fun with generating planets though.

My first iteration, made before I knew about git or even SVN. I used to copy my whole project folder every so often to make a backup. This was my first real hobby project, and I made a hundred mistakes that I now fondly look back on. Front end built with Swing.

A port to Korge.

I decided to go full Minecraft and try doing the low level graphics myself. Turns out, this was still painful. While drawing to the screen wasn't terrible, I ran into issues trying to get my collision maths working.

My second attempt (after a lost Unity project), Lib GDX seemed simpler than going full LWJGL, but wasn't worth fighting for when an update suddenly broke the repo.

What we built mostly over a one day min-hackathon, though we did prep work beforehand and hope to keep working on it afterwords.

Used Korge to quickly be able to play sound and deploy to the web. Very rough prototype with bad sound quality and awful visuals.