Archive for January, 2017



Anotha one. I’m on the back end of this Creo devlog double header, and since I wrote War and Peace 2 for the last one, I’ll try and keep this one brief. I had a lot of fun this version (sarcasm), because I was privileged enough to port all player movement and collision code from GM:S over to Java. This was just as frustrating, boring and tedious as it sounds. The good news is that most of this code also applies to mobs and pickups, so implementing the latter should come pretty soon. It was cool to be able to move one player in one client instance and see that player move in another open window.

GMxJN Fast Tracking

I figured that I would soon run into a problem with GMxJN. It was designed for HTTP-like messages where the objective was to transfer the packet in the safest way possible as opposed to the fastest. Using this same protocol for player movements yielding hilariously laggy movement. The solution is simple: adding a fast track for some packets. This should reduce laggy movement by about 60%.


Holiday and QuickFour

You know what time it is? That’s right! It’s time for me to catch up on all the devlogs that I have been procrastinating! And this time should be even more fun because I don’t have any nice pictures. So, after so spectacularly missing my deadline (Dec. 19th) I went on holiday. During this time, I didn’t have access to my desktop computer. I did, however, engage in quite a lot of thinking about Creo. That and I made a rap-lyric-sharing social network. Looking back, I realize that QuickFour was sort of a step back from Creo. It worked, because coming back from the Holiday I found myself refreshed and ready to go.

Object Orientation “Re-jiggling”

Well, I’ve succeeded in implementing in multiplayer what I’ve had in singleplayer for years! This includes chunk loading, block breaking, and block placing. I’ve also reworked the game server to better take advantage the object orientation that Java offers. I figured since I will be releasing the source code of the game server, I should clean things up a bit (unlike the master server, which is a mess and completely ignores object orientation). This means that chunks are objects, which have properties, methods, and more, making everything make more since and be more efficient.

Chunks and Blocks

So, what would happen if you joined a multiplayer game right now (I’m pretending that I’m writing this when I should have, so when I say “now” I actually mean as of D167)? Well, first the server would send you all of the nine chunks around you, some world data and the three chunks worth of column data. This had all been done using a ChunkUtils class which was referenced exclusively statically, but I later switched things up. You can explore the world (I generated a GIANT world in singleplayer and put the save in the server directory), but not without some awkward bugs that leave chunks M.I.A. Blocks can also be placed and destroyed, although placing blocks will not remove the item from inventory (yet) and blocks destroyed will not drop pickups (yet). These are two systems which have yet to be implemented. Later, server will track input and output of a player’s inventory to determine whether inventory outputs (ie placing blocks, throwing items, taming mobs) are valid. Also collisions have yet to be implemented (again, as of D167), which is another core system that needs to be in place for pickups. All in all, a good start. Its been greatly satisfying to wander the world in multiplayer.

Asynchronous Chunk Loading

While it would seem like chunk loading in multiplayer would be harder on the client, loading chunks actually causes no lag spikes (in contrast to in singleplayer). Because lag spikes across chunk borders have long held Creo back from any meaningful level of immersion, I have been looking to rid the game of them for a long time. I’m considering programming an extension which would allow me to load chunk files in another thread (something that is impossible within GM:S) and server up buffers asynchronously to the client. These buffers would be identical to the packets sent from the server, so performance would be comparable to multiplayer (in theory).