It's time to admit it

It's been a long time since I made any changes to Age of Goblins. The original Java code has gone untouched for three years. Code shouldn't be left in dark places too long. So I'm opening up the source for anyone to view. This is essentially the very beginning of a game with a custom engine that's not finished. Granted, this isn't something someone can just pick up and start using as-is, however, there are a lot of little and medium sized features that could be great for someone wanting to get started or learn how they don't want to code their features.

• Generating and manipulating a (cube) voxel terrain, built in chunks
• Voxel lighting system, with static shadows
• Entity component system
• Entities defined in data files
• 3D pathfinding
• Water ebb and flow simulation
• A job system
• Animation system that imports Blender animations with bone data
• UI system
• Camera system with in-world picking of objects
• A screwy physics system that I eventually gave up on
• And much more, it's been three years, I don't remember it all

So... Yes, this version of AOG is dead. I can't dedicate enough time or passion to writing my own engine in Java. I still have a faint hope that I'll continue work on the space game set in the same universe. Time will tell.

Find the source here:

https://bitbucket.org/byte56/age-of-goblins/

If you do end up using any of this, or find it useful, please let me know! I'd love to hear about it. If you have questions, I'll try to answer them as well.

Unity3D programming course

I created a course on Unity3D game programming! Check out the intro video:

Entity system differences

I was recently posed the question:

In your opinion, what are the biggest advantages of system-driven entity component system (as described in your answer here) as opposed to putting logic right into components themselves (similar to how Unity does things)?

The advantages depend on the requirements of the game. The two styles are pretty similar really, so the biggest advantages are going to derive from personal style preferences.

The main differences I can see are when and where things get processed. With the system approach, you know that processing will take place grouped by component type. With the Unity approach, processing will take place by entity. For example, a simple set of entities (E1 and E2) with their components:

E1: C:Movement, C:Pathfinding, C:Attack
E2: C:Movement, C:Pathfinding, C:Attack

With Unity the overall processing order might look like:

E1:C:Pathfinding
E1:C:Movement
E1:C:Attack
---
E2:C:Pathfinding
E2:C:Movement
E2:C:Attack

Notice everything grouped by the entity. With a system like the one described in my answer everything would run grouped by system:

E1:C:Pathfinding
E2:C:Pathfinding
---
E1:C:Movement
E2:C:Movement
---
E1:C:Attack
E2:C:Attack

So in the end, the same code gets run, but the order is different. While Unity does have some features to change the order, like using Update() vs LateUpdate(), it's not going to group things by components for all entities.

As I said, the advantages of changing the order really depend on the requirements of the game. In a lot of cases, the design of a game could easily be adapted to work with either system. So when designing your own system, it's important to keep these differences in mind and make the design work appropriately for your style.