About

I'm developing my first game, Age of Goblins. I develop this part time, and work at a "real" (read: paying) job full time. Age of Goblins is a three dimensional goblin empire building game. Inspired by Dwarf Fortress and Minecraft. Age of Goblins gives a player control over a small band of goblins in a cube-based sandbox world. The player can instruct the goblins to add or remove different types of cubes, build various structures, make elaborate traps, and craft a multitude of items.

Sunday, February 16, 2014

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.

Tuesday, October 1, 2013

Overview of basic features in AoG: New Korbly

See my latest video here or watch below.

Showing some of the basic features now implemented in Age of Goblins: New Korbly. Ship construction, energy management, module destruction, module physics and the ship FTL.

Ship modules breaking off

See my latest video here or watch below.

An oddly configured ship, but it shows that you have to be a little careful not to blow yourself up and it shows modules breaking away from a ship then interacting with it.

Sunday, August 11, 2013

A tangent demo

About a month ago I wrote about a development tangent with a working title of AoG: New Korbly. Today I have a demo for you to try out. Starting from the fresh start at the refactor, this represents a little over a month of very part time work.

Multiplayer basics are in place, but it didn't get a lot of attention, so it's not quite ready to show off. We'll aim for that on the next demo. This demo has basic ship building, power management, radar and various other little features. We'll continue to improve on the game as long as it's of interest and as long as enough people are interested. Likely releasing a new demo when new features are introduced.

Without further ado, the demo

Tuesday, July 9, 2013

A development tangent

Confession: For the last month or so I haven't been working on Age of Goblins. But don't worry! It's not dead or anything like that. I'm just taking some time to explore some other technologies and prototype a different game I've been thinking about. I got into game development to learn about the technologies and create fun things. Plus, I've had this idea for a game I thought might be a little easier to make good progress on in a short amount of time. After a few years of AoG, I needed the rush of new development :)

I've been working on the prototype with another has-a-full-time-job-and-does-game-dev-on-the-side guy, Seth Battin (of PBAction fame). Seth and I are both learning Unity3D while developing this prototype. Since we dove into the project without much knowledge of Unity, we're currently doing a bit of a refactor to apply what we learned about how Unity works. Seth is a bit busier than me so he doesn't have as much time as I do, but it's been great just having someone else to bounce ideas off and check my work (I'm sure he'll check something in eventually). It's also nice experience for learning to work with someone remotely, which I haven't done much of in my career.

The game we're making is a top down space game (3D rendered on a 2D plane of play). Players can build their own ships by snapping components together. For example, adding a bridge component and putting control thrusters on either side is enough to complete a small ship. Player space stations can be built in the same way. Ship and station components can be salvaged by trade, construction from raw materials or salvage (of existing wrecks or ones the player creates). See the "user story" below to see what the gameplay may be like:


The numbered lists show different outcomes available.

It's also multiplayer. I've never attempted a multiplayer game before (except "local" multiplayer), so it'll be an interesting experience. It also sounds like a super fun game to play with other people. Further grand plans include seamless landing on planets for resource collection/trade (space elevator delivery), somewhere from arcade to real-ish physics (needs playtesting) and space factories (for making ship components, not space). How much of that will get done? Who knows. It depends on how interested people are, how interested Seth and I are and who wants to give us a million dollars to make it.

Interestingly, the game is actually set in the same universe as AoG. I don't have all the details yet, so I'll just leave it at that. Well, just one hint, the working title of the game is AoG: New Korbly. There will be a story for the game, but it'll likely be a loose story line, with open ended play.

One thing I can say about Unity, after spending a few years building almost everything myself for Age of Goblins, it's been exciting to actually get to focus on making a game. Even after so long working on AoG, I'm still working on the engine. Let that be a lesson to all of you wanting to start making a game: Use a premade engine! Yes, I've learned a great deal about engine development in the last few years, but I have a lot more fun making games than engines.

Within the next few weeks I'll post a demo up here of the prototype. (It's crazy easy to publish to the web with Unity). Feedback welcome.

Tuesday, May 14, 2013

The uphill physics push

I've been working on (and sometimes avoiding) physics improvements in AoG. I wanted to start turning on physics for more entities. I've had physics implemented for material blocks and the terrain for a while using the Bullet Physics library. Turning on physics for other entities showed me more issues with my physics that needed fixing and so the list of things to do grew.

Sunday, March 24, 2013

What's the gameplay like?

The back story of the game is described in a previous post, The Discovery. Essentially, you're in charge of saving the goblin race (no pressure).

Your goal is to settle a new colony on a strange and hostile land. Most of your resources and technology were lost in transit, so you're starting from almost nothing. You need to build a home for your goblins, defend it from the hostile creatures that inhabit this new land and create the infrastructure to produce the technology needed to return to space.

Saturday, March 9, 2013

Fight or flight? Threat analysis


A still very much in development system in AoG is the threat system. This system is primarily used in combat. It helps entities with their fight or flight decisions.

Basically, the system takes two entities as inputs. The subject and the potential threat. The entities have some facts about them compared and a value is output determining the threat that the potential threat poses to the subject. The facts compared depend on the entities, but some common ones are:

Thursday, February 14, 2013

From data files to entities

Data files are just the start for creating entities in Age of Goblins. Once the definitions are read into AoG, they're stored in a catalog of "blue prints" for generating entities and materials. Each blueprint holds information for each component that will be added to the entity.

When the game requests that an instance of entity X be added to the game world, it refers to the blueprint stored for that entity. As an example, lets look at some parts of the goblin data file. The following will describe some attributes that each goblin entity will be generated with when it's added to the game world.

[Model]{
meshname="Goblin"
texturename="GoblinTextures.png"
distantdrawtype="norender"
selectionType="DynamicBone"
}
[Motion]{
maxvelocity=1.5:1.9
locomotion=Walk,Swim
}
[Skills]{
ALL=0.01:0.05,Mine=8.3:8.8,Construction=8.3:8.8
}

Tuesday, February 5, 2013

Data Files: Entities

Following up on my last post about the data files used for materials. This post will tell you a bit about using data files for defining entities.

First off, it's important to know that Age of Goblins uses and entity/component framework for all the entities in game, similar to the one described here. The data files take advantage of that when defining entities. Basically, the data files for entities tells the entity component system which components to add and what values to give them.