Posts Tagged ‘game’


Server Resource Manager:

So remember a couple of devlogs back (or about and hour ago, for me) when I was going on about how blockmaps are at the core of world generation? Well, if this is the case, then the resource managers are at the core of Creo, the entire game. I worked on this development version while on a cruise. It mostly involved heaps of file system stuff. I am currently (after D174) writing the methods for parsing item information sent from the server.


Miscellaneous Player Stuff:

Anotha one. In this development version, I tied up a lot of loose ends surrounding player events and states. Things like quests, buffs, health, experience, the item a player has in their hand, and (possibly) more are handled client side. Players can also smack eachother up. Death and the whole losing-one-item-when-you-die thing has also been implemented.


Different Lag Compensation:

I’ve switched up the way I do lag compensation a bit. It’s better now. Trust me.


Devlogging Spree:

Keep in mind that, as I said in the previous post, what follows is just an approximation of things that I remember working on around the time of this development version. These logs are more of an indicator at what I’ve accomplished over the last months as opposed to an exact record of what I did each development version, as most of my past devlogs have been. Anyways, lets continue.


Server Blockmaps (And Why They Are Important):

In the Creo engine, a blockmap refers to a data structure which contains a grid of block types, the coordinates of an origin point in the graph, and a layer of the blockmap (background, foreground, or solid). Client side, blockmaps are the conduit used between any block generation function and any block spawning functions. Want to generate a tree from a set of parameters and then queue the tree to be spawned 20 blocks away from the left side of the island? Easy! Just call the tree generation function which returns a blockmap and then plug the blockmap into the block queuing function. Naturally, to maintain some cohesiveness between client and server code bases, the blockmap data structure had to be maintained. Also they are very convenient to use.


World Generation And Thing Spawning:

Naturally, blockmaps and the corresponding functions are at the core of world generation. After the blockmap system was set up, it was simply a matter of porting client code to the server. As I soon hope to do for the client, the server generates columns concurrently to the world’s step method. In addition, after I figured liquid stuff out client side I could work on dynamic block behavior, including sapling growth and spawning of flowers, etc. I’m saving mob spawning for when I am completely done with the mob system.


Let’s Do This:

I’m sitting here in a classroom, nearing the end of high school. I’m without any of my personal computers, and am currently using one that the school provides. We aren’t doing anything in any classes. I inhale, and realize that I have no excuse. It’s been two months. Let’s do this.


Let Me Explain:

I’ve been fairly busy recently. I’m currently in the beginning stages of some client work, which is taking up a good bit of time. Add school, which until recently has been a large time sink. More recently I’ve been scrabbling to get everything ready for my freshman year of college. In addition, I’ve been taking steps to get Creo on Greenlight before any radical shifts occur in the indie scene on Steam (more on this quest later). And finally, multiplayer is boring to write about. I’ve spent a lot of time working on the game server, replicating functionality already found within the client. There is, however, a light at the end of the tunnel. Now, let me take you back in time to two months ago.



Much of the information in the coming few posts could be wrong. I don’t remember entirely what I did in each of these versions as they all kind of blended together. These next devlogs should serve as more of an indicator as to what I have been up to in terms of Creo.


How Liquid Works:

Every liquid block checks all of the other blocks of that liquid type which are form a continuous, horizontal line. Then, the “weight” on each of these blocks is calculated (how much liquid is above them). If one of the blocks has less weight above it then the others, some liquid is moved on top of the stack above the liquid block with the least weight. This creates the illusion of pressure. I’ll put the link to a twitter GIF here after I get a chance to edit this post.

Liquid (The Good):

The main benefit of this system is that it works within the current, established CTag system which is ingrained in the server and the client. To review, each block can have one tag, which is a signed, 32 bit integer. For liquids, this is how “full” a block is (out of 16). For saplings, this is how many seconds the sapling has been growing for. This is why liquid blocks cannot be saplings (something that I’m not completely sold on as it restricts the creativity of the user; I might have to change this system up in the future).


Liquid (The Bad):

Well the first thing is that it is not exactly beautiful, especially next to this asset which I had originally planned to implement (but failed to as it wouldn’t work server side). Also, there is a lot of room for optimization within the algorithms. I haven’t run into any huge performance issues, however I suspect that things could get pretty crazy if some hooligan decided to make the “stone” material in biomes a liquid. The issue of performance can be sorted out over time, however this is not the end of this systems’ problems.


Liquid (The Ugly And The Solution):

It is buggy as hell and only half works. This has led to me disabling the spawning of water once again. I think that most of the bugs can be solved by isolating the liquid and running the pressure function on each liquid system independently. I have already written a script to create a map of all blocks of the same type which are touching each other (for checking the bounds on bushes).


Fun Multiplayer Things:

Crafters and storage (known fondly as Block Inventory Crafters [BIC] and Block Inventory Storage [BIS]) are now working in multiplayer, though testing has been limited. Also, if you haven’t already seen, no picture today. Really, because this update (like the vast majority of these multiplayer focused update) didn’t really add much to the game. Hopefully I’ll get a GIF of some play testing up for the next one.



I’ll be tying up some loose ends before I move on to mobs and world generation respectively. This includes things like quests, buffs, damage/exp and hit detection (among other things). I’ll also take another look at the broken liquid system and get that up to release standards. Sadly, it looks like this extension that I so eagerly waited for won’t be making it into Creo (for now) because porting the extension to Java (which I would need to do for game servers) would be a monumental challenge. In addition, much of the strong performance of the system stems from running code on the GPU, something most lower tier VPSs lack. For now, I’ll stick with something like this.


Next Release:

As I mentioned, I just have to tie up some loose ends and then implement mobs and world generation, both of which will probably take less time than crafters and storage. A release could arrive next weekend.



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).


Starting Multiplayer:

The first orders of business for this development version were some unexpected additions for GMxJN:

  • To integrate the ability for multi-server communication. This allows for the client to communicate with both the game server and the master server.
  • To add functionality for inter-Java-server communication. This allows for communication between the game server and master server.

My primary accomplishment with the new game server was to give the master server a way to index them and later send them over to the client. While I briefly considered a Minecraft-style fend-for-yourself approach to users finding servers, I decided to opt for the Valve-style centralized index of user game servers. Each server carries with it a customization name, three customization tags, and a 16×16 logo. The master server also tracks the players and max players. Client-side, the index looks like a more advanced version of the single player map selection menu. The menu allows for ascending and descending sorting by max players or players, as well as searches for tags or names. This degree of indexing was possible thanks to the servers being stored in an Apache Derby database server-side.

Closing Remarks:

Now that I’ve missed my mid-December goal by a long shot, I want to go without any specific goals for a while. That being said, I won’t be getting lazy. I want to work on Creo with most of my free time. I’d be lying if I said Overwatch (an early holiday gift) wasn’t a driving factor in my recent slacking, but as I come back from vacation I intend to curb the time I spend playing it. Speaking of holiday and vacations, I will be away from my computer until early January. The good news, however, is that all of my college applications will be submitted by about-then as well, meaning I will have that weight lifted off of my shoulders.