The Netizen Dev Blog

So what do you do when you want to add threading to an application but other parts of the application are not thread safe? For example, lets look at Minecraft server mods and how I’ve implemented multithreading in CivCraft.

As of writing this the Bukkit API and Minecraft itself  are not thread safe meaning it’s not save to grab game data or change data from a thread. There are no protections preventing you from *trying* to access and change these game objects so sometimes it will seem to work, especially for servers with few players such as your test server. However rest assured you’ll get the dreaded  “ConcurrentModificationException” or worse just random crashes eventually.

For Minecraft servers, by far their most precious resource is how much time is spent during a Tick. By adding additional synchronous tasks to Minecraft we increase the delay between ticks and reduce our server’s TPS. To help combat this, I’ve tried to move as many tasks to asynchronous tasks as possible.

The textbook solution would be to establish locks on data that needs to be accessed by multiple threads and only allow one thread to work on it at a time. However in the case of our Minecraft server plugin, we simply do not have access to the parts of the code that we need in order to add locks. Too many sections of the code are public and we cannot simply modify the Minecraft server’s code. So are we doomed to run everything in a synchronous task? Nearly, but not quite.

In CivCraft the following tasks are completed using asynchronous timers and tasks:

• Building Structures
• Trommel Processing
• Farm Growth Processing
• Cottage/Granary Consumption

If you’re familiar with CivCraft, you’ll know that each of these tasks need to both obtain data from the world and set data in the world. Doing so directly is not possible since the main world is not thread safe, so how is it done? Consider the following pattern:

 

In the diagram above, the main thread launches a asynchronous task with all of the data it needs to complete the task. As the asynchronous task completes parts of it’s task it Queues those bits of data into a thread-safe queue where the data is consumed by a synchronous task.

For example when a new structure is being built, from the main thread CivCraft launches a new BuildAsyncTask by providing the Town, Buildable object, and template that’s being built. The BuildAsyncTask performs the calculations for how long it should sleep in between building each block and waits the proper amount of time. When the BuildAsyncTask is ready to build a block it sends a “Block update” request into a queue where the SyncBuildTask will dequeue it and perform the build operation synchronously. Another example is the Farm Growth task. The main thread will take a snapshot of an entire chunk, and send that data over to the asynchronous thread which will then perform a search for blocks that could grow. Once the async thread determines which blocks are going to grow, it sends back growth requests to the main thread so that they can be performed synchronously.

This is all well and good for when you have all the data you need to start a task. But what if you need to retrieve data from an async task while it’s running? This can also be accomplished by using thread-safe queues to “request” data. Consider the following diagram:

When an asynchronous task requires data, it can request that data from the synchronous task and wait for the reply. This works, but has some obvious downsides. The first being that the Asynchronous task has to wait for the sync task and is blocked in the meantime. However as you may recall time in the synchronous thread is our most precious resource, so blocking an asynchronous thread is a small price to pay. A more serious problem exists with data integrity. Since data can change in the synchronous thread while it’s being worked on in the asynchronous thread, oblivious to the changes. This creates a race condition between the sync and async threads. In practice though on our Minecraft server data could only get out of sync if the async task took longer to complete than sync ticks and since our async tasks were much faster than that I ran into no race conditions. But be warned that they are there. To completely avoid a race condition you need to validate that the data being used to derive a update has not changed since the last tick and if it has, rollback the async task with new data and try again.

In conclusion, there are some tricks you can pull off if you’re stuck in a non-threadsafe environment to gain a bit of threading. Minecraft server plugins are a bit of a special case in that we’re simply unable to follow the standard advice of actually making code thread-safe in the first place. But if you’re stuck in a situation where you cannot modify a bit of data to be thread-safe (such as making a Minecraft plugin) hopefully this post will help you out a little.

For those who have been following things related to CivCraft, you’ll already know that I’ve released the source code to the CivCraft project and now consider the project completed. More or less, so I’d like to take the opportunity to do a postmortem on the entire project and give an overview of what went right, what went wrong, and lessons learned for the future. First a quick overview of what CivCraft is when it started and what it’s now become.

Initially, CivCraft was nothing more than a simple Minecraft server that ran a few slightly customized mods in order to bring more meaning in to the game. Simple things like converting ores in to currency and then using that currency to purchase land, pay upkeep, and buy upgrades for your town. As time ran on we wanted to find more uses for the currency to keep players interested in gathering it, so we added functional structures to the game. Once the plugin started to get big enough we did a major rework and created the CivCraft plugin as it exists today. Today CivCraft has over 500 active users and is running on about 20 or so servers. There has been more players online in the past, but we’ll get to that later. You can find the current server list and player count for CivCraft at civcraft.net. The project has been quite a roller coaster and the source of much stress in my life since it’s gotten popular but it’s also been very rewarding in terms of lessons learned and knowledge gained.

Lets start with what went wrong.

What Went Wrong?

Not Enough Planning

A great many things went wrong during the course of this project, too many to count. Most of which however were either directly related to or greatly exacerbated by a lack of planning on my part. I can’t beat myself over the head too much for this, since the original goal of the project was to just run a fun Minecraft server. Which we did, quite successfully, but since the project and it’s additions were added slowly over time it wasn’t until much later in the project did we sit down and actually design any of the features we were adding to the game. Up until that point it was mostly a Hodge-Podge of things we thought would be fun to add or needed at the time.

A great example of this is our city building mechanics before beta5. Take a look at this diagram which maps how the different city mechanics interacted with each other. (Open the image in a tab to more clearly read the text).

 

At the time, culture did almost nothing for you except maybe bring in trade goodies in to range, but building another town was a much better way to obtain those goodies anyway. Structures were primarily used to generate coins and culture but had little effect on science. The asymmetric interactions you see here are a direct consequence of implementing each of these features one at a time in isolation rather than sitting down and coming up with a coherent strategy for how city mechanics should interact with each other.

There was also a significant amount of wasted effort due to not sticking to our goals in the face of shiny new toys. A constant wildcard throughout the development was changes coming down from Mojang, and nothing hit us harder than the Minecraft horse update. When we first heard about the horse update we were very excited as adding horses to CivCraft seemed natural and would mesh well with the gameplay. We also had to update the servers live without resetting them which meant we had to be on the ball when the horse update came out and prevent players from obtaining horses so we could hijack them and make them work inside CivCraft’s paradigm. We spent a lot of effort making stables, working on horse code, testing horses, and locking the feature down only for a few bugs to slip through and negate a lot of our work. On a large TPS strapped server with a smaller view distance, horses did not perform as well as we had hoped they would. We also priced horses outside the range of what they were worth, so in the end they became quite useless and represent a lot of wasted effort for us. Why did we price them so high? That brings me to my next big issue with what went wrong…

No Resident Content

Resident content is the term we used for content that would be available to average, non-leader and non-mayor players of the game. Average citizens needed more to do than standard vanilla Minecraft survival if the game was to remain interesting for them. Many of the costs and balances in CivCraft are based around needing to lead a group of residents, but who wants to be a resident if it means being bored? Having spent a lot of time working on city management, civ management, and town management in the pre-beta phase, we seriously underestimated how bored residents would become in comparison to the mayors and leaders who ran towns. Vanilla Minecraft was not enough to keep them interested any longer.

While we always recognized that this was a problem, we didn’t treat it with enough respect until it was almost too late. The reason why horses were priced so high was because we wanted to give residents something to strive for that they could then show off. If horses were expensive, then they’d at least have a goal they could obtain. The problem with this approach however was that horses cost coins, and the best way to get coins is to generate them in a town, so horses were pretty much just play things for the rich mayors and leaders. Not resident content.

We again tried to patch this problem by adding the global market. This was a lot more successful than we thought it would be however it still wasn’t enough. At beta5 we spent a lot of time reworking the crafting system to give residents something to do. This turned out to be a controversial decision of sorts because it certainly changed the meta-game for how people obtained gear. Gear was harder to obtain and would benefit individuals, and that worked, but because of the global market rich mayors and leaders could just purchase the materials with coins. And again the best way to get coins was to own a town in a civ so again gear became more exclusive to the rich and powerful. The global market was, in theory, supposed to become more and more expensive until gathering became a viable alternative. However we never reached that point due to a serve lack of supply.

Since prices were so inflated in the global market due to a lack of supply, we needed to make it easier to gather the materials rather than purchase them from the global market. So beta7 added powerful custom mobs to both increase the supply and to add resident content. After a bit of balancing  this seems to work ok and strikes a fair balance between buying and gathering materials, however due to not having the proper tools in Minecraft the custom mobs are quite glitchy and the experience is not as great as it could be.

All of this could have been avoided if resident content was more thought out and planned out a bit. However since I’ve reached a point where my tools are fighting me more than anything (Minecraft doesnt like to be hacked at this much). I feel like the amount of effort required to fix this problem is beyond what I’m willing to spend At this point I feel like more drastic changes are required, such as removing some key materials from the global market, removing the civs ability to generate coins, or making coins generated by civs a difference currency from the coins spent by residents. Civilizations should rely on residents not residents relying on civs.

Competitive Players vs Causal Players

It turns out that CivCraft appeals to two different types of players. Casual Players want to build a custom civilization and make it look nice and visually impressive. They essentially want to play Minecraft in survival mode but with the extra addition of civilization building. The other type of player is competitive and wants to create a civilization with the main goal of “winning” and besting out other civilizations. This conflict is inherent to CivCraft’s overall design and while we attempted to strike a balance between the two, I think we landed too heavily on the competitive side rather than the casual side.

The ability to capture cities and civilizations instead of vassalling them really takes a psychological blow against the losers of the battle. We misrepresented the amount of dismay this would cause players and rather than work on and keep playing most players resigned themselves to defeat and quit playing or waited for a reset to try again.

Another slap to the casual players virtual face was victory conditions. The competitive players wanted a way to “win” the game, and I also wanted a way to reset the map so that bugs could be easily fixed and large scale changes implemented at set times. This had the terrible side effect of erasing the casual players’ work which gave them little reason to play on a competitive version of CivCraft.

We addressed these issues by adding casual mode, which personally I think, in retrospect, should have been the primary focus of CivCraft from the beginning. By trying to make competitive players happy we neglected our casual players and causal players are the foundation upon which competitive games must rely.

 

What Went Right?

Now that we’ve got the Captain Hindsighting out of the way, lets talk about the things that went right in this project.

CivCraft Is Popular

Sure more people could be playing, but when I started this project never in my wildest dreams would hundreds of players be actively playing the game at any one time, nor would I have imagined running in to people in real life who have played the game and are suddenly star-struck when they realize they’re talking to the creator. As a game designer, you always wonder if your ideas are really going to have any appeal to other people and it’s nice to validate that yes, there is demand for the kind of game that I want to make. There is still a lot of work on the implementation of concept and I’m happy to see that server owners are experimenting with new ideas and trying to come up with solutions to some of the design problems we encountered.

I think something that’s often overlooked is that CivCraft doesn’t have another game to copy it’s design from. If we were making another MMO, we could look to Lineage 2 and World Of Warcraft to determine how they solved problems. However CivCraft’s design problems are unique since the players have so much more power and control than they do in other games. And I think for charting unexplored territory we’ve managed to come out ok. We’ve got tons of ideas to improve the game, but doing it Minecraft is counter-productive at this point. Hence why we’ll be incorporating the lessons learned in to our standalone.

CivCraft War is Really Fun

Like almost too fun. It only happens once per week for logistical reasons but we’ve heard tons of requests to allow war to happen twice per week since it’s by far the most interesting and fun part of the game. For many, the day to day playing of the game is all a lead up to the cataclysmic war and the drama that ensues in it’s wake. Making the day to day gameplay of CivCraft more fun is of course a goal, but it’s important to take a step back and realize that it’s overshadowed by just how fun war is. A lot of the momentum for catering to competitive players rather than causal was based around how fun war is, and other than some balancing issues I think that CivCraft’s war mechanic is one of the best reasons to play it. For making it better, if we had the time and resources it might be nice to try and find ways to have wars scheduled on a per-civ basis so that they don’t all have to occur on a single weekend and so that players can get some action in during the week day. Additionally other skirmish like activity would be nice if it could occur during the weekdays so that the weekdays are more interesting.

CivCraft’s Anti-Cheat

While maintaining the anti-cheat is going to be a pain, while CivCraft was on the ShotBow network it’s custom anti-cheat client made Civcraft the most hacker free Minecraft server in the world. Barring of course small time servers where everyone just trusts each other, no other Minecraft server has ever implemented a custom anti-cheat. And to be fair, there is a good reason for that. Forcing your players to download and install a custom mod to play prevents many players from entering and it’s counter productive to the server’s overall health. However I feel the way in which we implemented the anti-cheat was a perfect balance of the costs vs the benefits. Players who didn’t want to install the anti-cheat could play on the casual server, and on the PvP server. The only difference was they could not participate in WarTime on the PvP server if their civilization was at war. So at the times and places were it really mattered, CivCraft’s Anti-cheat made it very difficult to play with hacks. Thanks to projects like Forge the mod is very easy for players to install and having client side detection was certainly the way to go.

If I were to continue working on the project, adding additional incentives to the client side mod would be something I’d like to do. Adding visualizations for culture borders, menu driven GUIs instead of commands, and other conveniences to entice players to install it so that it didn’t feel like legit players were being punished by having to install the mod. Paradoxically though, by having to install the anti-cheat all players increased their confidence that the game was being played fairly. So the anti-cheat was a win-win in my book.

Casual Mode

As mentioned before, casual mode was a great idea since it appeals to the more longer term players. I wish that I’d implemented it sooner and focused more on casual mode, however this will be something we’ll do in the future.

Global Market

While it caused some problems with the resident/leader power dynamic, it really added a whole new element of strategy to the game and was a great addition. With the global market residents could earn money quickly early on by farming things like sugarcane in mass and selling it at the market. While the market didn’t become the full economy we’d hoped it certainly gave us a lot of interesting gameplay and information on how digital economies function.

Floating Structure Validation

This one had a rocky start, and there are still some UI stuff that Minecraft can’t easily solve for us but overall I think that the floating structure validation was a huge success. We went from needing admins to police every structure (and sometimes not seeing the problems because they were hidden or changed after a structure was OK’d) to zero floating structure complaints after the bugs were fixed. There was at least one controversial phase in which the floating validation was not working right and we chose not to intervene. But afterwards things have settled down quite a bit.

Having the floating structure validation did indeed bring forth an interesting construction restriction on basements, although this was not as important as we had hoped due to the tunneling meta-game strategies in war. Placing structures was still a PITA though. In the future and given full access to the client side I would have made the visualization of conflicting caves in the ground more apparent and probably added an option to start building the structure while it was not validated or an option to “fill in” the cave at an extra cost. Just to prevent the annoying structure placement problems that exist.

Custom Material System

Gameplay wise, this had only luke-warm effects due to many different issues. However from a technical standpoint the custom material system was marvelous. By using components we were able to create many different items quite easily and admins today can add new items with new effects at very little cost. If an admin wanted to, they could create an entirely new tier of weapons and armor without having to touch a single line of code! Only YAML manipulation. Since I made the storage of custom information generic enough I was able to use it to store many different types of data, not only custom tags for item id’s but also custom enchantments and tags for things like arena items.

Asynchronous Tasks

Another technical success was the use of asynchronous tasks in a non-thread-safe environment. Everything in the world must be accessed and set in a synchronous thread in Minecraft which can significantly slow down the game and drop TPS. I needed a way to run slower tasks asynchronously but call synchronous functions when I needed to. The internal framework I created had a rocky start, but has stood the test of time quite well. I’ll explain it in more detail in a later post.

Lessons Learned

• Just because something sounds fun, doesn’t mean it will be.
• Running a live server and making live updates to the code is very hard. It can double or triple the amount of effort you need to put in.
• A bug causing problems on a live server which can’t be reset is way harder to fix than a bug that can be reset. Cleaning up the problems caused by a bug is often more work than fixing the bug in the first place. Having to do it all over again I would certainly have a testing server and find a way to get people playing on it to find bugs faster.
• Component systems are worth their weight in gold. Use them.
• Administration and community management are a lot harder than it looks.
• Players will give you suggestions and criticisms which must be viewed as raw data, not requests. Players don’t really know what they want in most cases and you have to interpret them.
• Don’t underestimate the negative effects of petty politics.
• Design gameplay elements from the start and focus on the ability to reuse mechanics as much as possible.

And that concludes my postmortem analysis of the CivCraft project. There is a lot more I could say about it, but these are the key things that stick out in my mind as being the most important. The standalone version is going to take the failures, successes, and lessons learned in to account and will be a much better game for it. I can foresee many changes coming to it, you might not even recognize it by the time it’s finished. 🙂

 

 

I’ve been spending some time checking out these new fangled design methodologies that throw out typical object oriented programming and replace it with an “entity component system” or ECS (http://en.wikipedia.org/wiki/Entity_component_system)

TL;DR , an ECS system creates uses components to compose objects rather than using elaborate “is-a” relationships. This allows programmers to more easily mix and match components which makes your game more flexible.

The holy grail is the end point, where you’ve got such a wide breadth of components that you can let your game designers simply mix and match them to create new content. Each game object’s component composition is stored as data which can be manipulated outside of the program. And each component can contain knobs that allow the game designers to change things on a per component or per object basis. Quite powerful.

It turns out that my head has been in the sand and this trend has completely passed me by, its been vetted first by Dungeon Siege (http://scottbilas.com/games/dungeon-siege/) and now large scale frameworks such as Unity embrace this model. (knowing the motivation behind the model would have helped my adventures in Unity) =P

It’s currently ‘too-late’ to incorporate much of this into the civcraft project, but for my next project, this will be fun to play with!

What started as a very small mod to a mod in Minecraft has grown into something more. In May of 2012 I started on a simple modification to the Towny plugin to allow a couple of small structures to be built using in-game commands. The idea was that I’d like players to be able to convert the gold they mined into currency which they can use to trade with each other and purchase upgrades for their town. We started with a simple bank structure that would exchange iron, gold and diamonds into coins, and a store structure where you could purchase different kinds of blocks. Instead of getting more blocks for your town by adding people, we decided to award blocks for purchasing the level of your town.

Now it has evolved into a full fledged Civilization inspired mod for Minecraft. It still piggy backs on top of Towny for block permissions, but I’m working at chipping it away as I replace and optimize it for my needs.

I’m currently in the progress of implementing wonders, culture, diplomacy and war.

Please check it out at http://avrgaming.com

I plan to release the source code to the mod when its closer to being finished, for now though you can play the beta at the website.

EDIT: 6/20/2013: CivCraft does not contain any Towny code. The “author” of Towny, ElgarL has been linking to this post(Sept 2012) claiming that it means that the current version of CivCraft running on the ShotBow network uses stolen Towny code. This is a demonstrability false claim, in which I go over the details here. At the time of this post, avrgaming was hosting a minecraft server which used Towny to handle block permissions.

Throughout the lifetime of a project, there inevitably comes a point where what you’re doing is no longer intrinsically fun. The easy/fun parts have been finished and now you’re working on the nitty gritty. Such as working out the bugs in a pathfinding algorithm, writing networking code, or even simply researching how do accomplish the next task you’ve got on the drawing board. At this point its very easy to get distracted especially with new games coming out all the time combined with having non developer friends wanting you to join in. So how can you overcome these temptations ? How can you continue to work towards your goal of finishing? The truth is that nobody knows the answer to that question, its something you have to discover for yourself. However what has worked for others has also worked for me.

Here are a couple of tricks and pitfalls that have I found  in my productivity. Hopefully they will help you.

Pitfall: Falling Down the Rabbit Hole

This one is a big struggle for me. Often times when I see a problem I’m tempted as an engineer to solve to problem in “the best way possible”.  This post about how engineers and project managers prioritize work was a real eye opener for me. The TL;DR on the article is that engineers look for the “best” solution, while project managers look for “good enough”. The article goes into great detail why both parties are completely justified in their priorities based on the way in which each of them is punished and rewarded.

Bringing this back to gamedev. What this means is that I as an engineer have a tendency to over-engineer and over-prefect areas of the project that don’t necessarily  need it. But on an indie project, I am also the project manager and fail to look for solutions that are “good enough”. The result being spending hours upon hours perfecting and optimizing a single part of the code leaving the rest to suffer.

While on the face of it this may not seem so bad. Because after all when you’re done you’ll have something perfect and you’ll never have to work on it again right? Wrong. Since you don’t know what the final implementation of the game will be, there is a very, very, strong chance that you’ll have to update this code later on to make it compatible with your new features. Not only does this prevent you from doing any real work it also saps your energy, motivation, and the visual progress of your game.

The Solution: Attempt to build what is called a vertical slice of your project. This translates into getting a simplified or rudimentary solution for each piece of your project. While there are some downsides to using a vertical slice, the advantages you get are enormous. By having a vertical slice in place, it allows you to see the full implementation of your game more clearly and allows you to make informed decisions about what parts should be generalized and optimized, and what parts are ok with being “ugly”. Additionally, having a full vertical slice gives your project a sense of visual progress which you can use to convince others to join your project and to convince yourself that you’re making progress allowing you and everyone on the project to keep their morale high.

Pitfall: Premature Optimization

One of my idols, Johnathan Blow (creator of Braid), opened my eyes to one of the pits that I had been falling into for years, that of premature optimization. From his presentation (which you can view here at his blog) he talks about the ways in which premature optimization can hurt a project. In a lot of ways its similar to the rabbit hole problem mentioned above except on a smaller scale. While you can usually guess which parts of your code are going to run faster or slower than others, its difficult to tell how much  difference a particular optimization will have on the final implementation.  Additionally, optimizations usually rely on a set of assumptions which, while valid at the time of writing the optimization, may later turn out to be false. These subtle assumptions then later cause very strange/irrational bugs which can steal days worth of your time away from you. Your time is a precious resource and you need to treat it as such.

The Solution: Today’s computers are reasonably fast enough and compilers are reasonably smart enough that you can safely ignore most optimizations until the end of the project. Its perfectly valid to do little optimizations (like writing a real findMax function to find the maximum value in an array instead of using Sort/Reverse ) but optimizations that rely on implicit assumptions should be avoided until the final implementation is clear. Additionally, waiting until the end of your project gives you the added benefit of spending your optimization efforts where it counts the most, and leaving the less important optimizations to be fixed as time allows.

Pitfall: Boredom

In every project there are sets of tasks that are fun or boring and we have a tendency as human beings to want to work on the fun parts while ignoring the boring parts. Assuming that 50% of the project is fun and 50% of the project is boring (a very generous assumption), you wind up very quickly with a distribution of tasks in which the majority of the ones left to do are boring. Unfortunately there is not a lot you can do to avoid this pitfall but there are a few tips you can use to stave off boredom and prevent it from reaching levels high enough to make you quit the project.

When you start to stagnate, switch tasks

This is a bit counter-initiative to us engineering types whose instinct is to double down and focus on a problem until its solved since breaking your concentration on it will cost you effort getting yourself back up to speed later on. This approach would be fine provided you only had that one task to preform, but its important to remember that the real enemy here is fatigue and boredom. Switching tasks and getting some victories in other places will refresh your confidence and motivation and while finally solving the difficult problem may do the same, its usually too little too late.

Take breaks and reward yourself with success

Just finish a major feature or fix a major bug? Reward yourself by doing something different for a little while. Play a mindless game, go out with friends for the evening, browse Reddit, or cook yourself a nice dinner (as opposed to yet another microwaved pizza that you’ve been eating the past two weeks). Even little things like going for a walk or taking a shower will do wonders for your morale and mental state and sometimes may even open your eyes to the solution that had been staring you in the face the whole time.

Balance the fun with the boring

While most projects are going to have far more boring parts than fun parts, be sure to ration your fun parts sparingly to allow yourself some “easy” or “relaxing” work to reward yourself with after slogging through the boring parts. It may help to finish of the day or week with a fun part so the proverbial “taste in your mouth” is that of a good one. When I was a kid I’d often employ this strategy by eating all of the things I didn’t like first, and saving the good stuff for last since that’s the taste that will linger afterwards. Similarly by ending on fun tasks you can help reenforce your last experience working on the project as enjoyable, making you more likely to do it again.

Remove distractions

While this might seem like a no brain-er in practice its incredibly hard to do. Today we are constantly surrounded by easy access to entertainment through our computers and through our phones. The internet itself can be a large source of distraction, especially sites like Reddit which feature nearly endless streams of content for your viewing displeasure. It seems like an ideal solution to simply unplug and let those distractions fade away, but the reality is that as a developer you need access to the internet to look at reference manuals, ask questions, and look up known solutions to problems you encounter. Your game itself may require internet access in order to function correctly. So what can you do? Well, what I’ve done is create a new user account on my PC called ‘dev’ in which I do all of my development work. He is a full administrator, has all the permissions as my other account and there is in essence nothing stopping this account from procrastinating like my main account. But it turns out that little things, like not having your bookmarks, not being logged into Reddit or email, having no game shortcuts on your desktop, having all your gamedev files on in this user so you “have” to be there in order to do development, does wonders for my productivity. Any time I’m tempted to look at Reddit, I’m reminded that I shouldn’t be by virtue of it not showing up in my address bar when I type “re”. I’m reminded that I shouldn’t be playing games when I have to hunt for the shortcut button to open it up etc, etc. And at that point I have to make a conscious decision to stop development and switch to my main account. It doesn’t always stop me from procrastinating, but in my experience it helps more than it could possibly hurt.

That’s it for my list of pitfalls and tips for now. Perhaps more to come in a part two. Thanks for reading 🙂

The year was 2005, and having just finished high school and started my computer engineering degree I decided I was ready to start writing my own engine. I wont say it was a big mistake or a waste of time, as attempting to write your own game engine is almost a right of passage for aspiring indie developers, but I will say when I started that I had very lofty expectations and vastly underestimated the total amount of work involved. All things considered I am still proud of what I accomplished on the project and so I thought I’d share the fruits of my labors here. May I present my engine, appropriately named “Alpha”.

The engine uses an OpenGL fixed function pipeline and generates a heightmap and texture map from two .bmp files. Most of the information I needed to build this engine came from the wonderful NeHe tutorials, which are now fairly outdated since the adoption of shader languages. One of the more involved features was the introduction of texture blending when transitioning between two different heightmap textures, pictured below.

In order for texture blending to work properly, the triangles for the heightmap had to be drawn in a logical and predictable order to allow the alpha weights to be set properly. This resulted in long tedious hours in front of a whiteboard planning out how each triangle in a square will map its texture and while the end result was very satisfying and rewarding, the small graphical improvement vs effort required to attain it sapped my motivation. I slowly came to the realization of how incomplete this engine really is. It still needs collision detection, a simulation system (update/ticks), a way to load in models and animate them, and networking just for starters. It was at this point I began looking at other engines.

What went right. While being a far cry from a complete engine this project helped me appreciate the vast amount of effort involved in writing an engine and help alleviate my fears about using engines written by others. I like a lot of indie developers start with a naive sense pride that needs to be smashed down at some point before the real work can begin.
It also didn’t hurt to learn about the OpenGL pipeline, gain some experience with heightmaps and graphics programming, as well as much needed C/C++ experience. Over all I believe this project was a success despite its unrealized and unrealistic goals.

Here is the source code and executable for Alpha if you’re curious and wish to play around with it. I provide it here no strings attached for education purposes. Feel free to extend it or even use it if you’re so bold.

 

Happy Coding 🙂

Every time I see post on /r/gamedev linking to yet another game development blog I ask myself, why do I care what this person has to say?”. How do I know this person knows anything more than I do? Well this post is mainly here to admit that I know absolutely nothing. So why am I making a game dev blog? Well, I have come to the realization that sometimes the blog posts are not intended for anybody other than the author as a means of cataloging their development experience and perhaps giving them an opportunity to share what they’ve learned. In essence while I hope someday to impart some knowledge that inspires you as this post did for me, I currently reserve this space for myself as a development journal.