Archive for May, 2017


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