Pre-Alpha demo 6: Age of Goblins - World Generation and Animation

A new video!

The GUI used in the video is ByteGUI. I'll be releasing it as a stand alone library for other developers. It uses Slick2D and is written in Java. I'm sure it'll be prettier in the hands of someone more artistic. It has various effects, some of which are shown in the video with panels sliding in and out. More details on that when it's closer to release. Thanks for your interest!

The Blender connection (part 2)

I previously introduced loading models and rendering them in-game. Now I'll go over implementing animation for Blender models.

First we have to add bones to the model. If you know pretty much anything about skeletons, this is fairly simple. Your mesh is the flesh. You want to add bones in places where you want the flesh to move. If you want this bit of the flesh to be able to move independently of that bit of flesh, you need to add multiple bones. Take, for example, the simple AutoCannon T230:

The Blender connection (part 1)

I use Blender for all my modeling and animations. I chose it because it was free, ubiquitous and appeared to produce good results. This post will describe exporting that information from Blender and importing it into AoG. This information will not only help those wishing to duplicate this in their own games, but also help future modders of AoG make their own models.

I'll start with the most basic application, a static mesh.

Step one: Make a model! I won't go into the details of making models here, as that's a process I haven't even mastered myself. We'll use a tree:

 

Clear proof I have not mastered model creation.

The latest changes

Animation System - After getting animation working, I needed to implement a system for displaying animations. That's now in place. The animation system simply uses an event system to pass messages for animation changes. The animations have a few parameters defined, like delayed start amount, maximum play time and whether they should loop or not. It also includes an idle animation pool for each model. When defining animations in the data file I can add "IDLE_ANIMATION" to the name and it will be added to the idle pool. Additionally I define a weighted chance value for that animation. Then, when a entity is idle, it will choose randomly from the idle pool, the animations with a higher weighted chance will be chosen more often. These animation pools can be used for other animation types too! So any animation can have a animation pool. This makes it possible to have multiple animations per action. This way, things don't look so robotic, allowing for subtle changes for the same action. Animation really brings the game to life. It makes the goblins walking around and performing tasks look so much better. I'll show it off in the next video. Along with a few animations (so far I have walking, mining, picking up and dropping. Plus five idle animations).

Implementing animation was like pulling my own teeth

These are the latest things to be checked off my to-do list:

• Model Animation - This one took a while and had me pulling my hair out. Most of this went quickly and easily. Turning each bone's translation, rotation and scale into a transform matrix for the bone's vertices took a while. I just kept running into problems. I'd just look at the mangled mess of triangles that was a goblin just a moment ago before I applied the animation. Was my order of operations wrong? It's so close now, but the rotations are backwards. It's nearly working now but the rotations are around where it was before it translated. This is all wrong, redo. Redo, redo, redo. Finally, a clean working implementation. In the end it was just a collection of small issues that had to be solved in the correct order. But that's no matter now, it's working. Now that it's out of the way, it opens up some other tasks on the to-do list:
• Creating animations: Yes, I need to get all artsy and make animations for my models.
• Animation system: Creating a system that decides which animation to apply and when. I have the framework for this already in place from implementing the model animation, I just need to flesh it out.

Moved

You may have noticed that my blog is no longer hosted at Tumblr. Well, Tumblr has issues sometimes that are annoying. Since I'm already using Google for everything else, I guess I might as well use them here too. Sorry for those of you that were following me at Tumblr. I'll post links on Tumblr so you can continue to get updates.

Additionally, I'll have an update on my progress soon.

How do you do it?

Someone asked me:

How do you find the time/energy to work on your game and be so active on GDSE AND hold down a ‘real’ job? I love coding, but when I come home from work, I’m beat.

It’s just a passion I have. I enjoy contributing to the game development community and making my game. I love to learn. I love to create. I hope that doing this will someday lead to game development being my ‘real’ job.

Energy is an attitude. If you give yourself the easy option of browsing the internet reddit or watching TV, you’re going to do that instead. Don’t let yourself be lazy. Sometimes the effective strategy is to remove the alternatives (unplug your network), sometimes it’s just pure willpower or even changing your desktop wallpaper. If you do this long enough, it’ll become habit. Let yourself feel bad for being lazy and feel good for being productive.

I’ve done it long enough that productivity is a requirement. If I’m not productive I feel it. That has it’s own pros and cons. It’s important to find a balance that you and the people in your life can be happy with. All of it is easily under your power to do, just make the decision and stick with it.

Exercise regularly. I cycle 8 miles a day, 5 days a week (rain or shine) and I play ultimate frisbee twice a week (read run around a lot for an hour). Cut out soda. Eat healthy food. Mind over body. It’s all about attitude. Healthy body, healthy mind.

Anyway, that’s enough preaching from me. How do I do it? I just decide to do it, then I do it. It’s really as simple as that. Once you learn to do that, you can apply it to many aspects of your life.

How to go from theory to practice?

I was recently posed a question:

I’ve seen your post on gamedevse about the entity component system, I had my share of trying to make one by myself, and though your description is beautiful, I fail to see how to code that. Can you give some example on how to go from theory to practice?

There’s an excellent example of an entity component framework with Artemis. Download and study the source code. It may be confusing at first, but stick with it. Artemis really helped me understand how EC systems worked and I’m sure it’ll help you as well.

By saying it is you first game. Do you mean that you have never programmed anything before? not even like a pong game?

I do plenty of programming. As for games, I’ve made simple little things before, but they were simple enough to be contained to one or a few files. This is the first real game I’ve made. I’ve never done anything in 3D or anything so complex. This is orders of magnitude larger than any programming project I’ve done, game or otherwise. Thanks for the question.

Role of systems in entity systems architecture


In lieu of a blog post, a long winded answer about systems in entity/systems architectures. Age of goblins implements a entity systems architecture.

New goblin jobs video. Also showing off some changes in cubes and touching on the scripting work I’ve been doing.

Time circles

How does Age of Goblins track time? First some terminology.

The goblins use a different system than ours for tracking to progress of time. They use a base 10 system. Each cycle of the star around the little flat world the goblins have settled on is called a dak. For those trying to keep track, basically a dak is the equivalent of a day, that is, the entire day/night cycle that we’re so used to here on earth. Each dak is broken up into 10 adrs. Each adr has 10 decadrs, and each decadr has 10 centadrs. Still following? It I were to compare it to standard earth time it would be something like:

Dak = day
Adr (10 per dak) = hour (24 per day)
Decadr (10 per adr) = minute (60 per hour)
Centadr (10 per decadr) = second (60 per second)

Then of course there’s the longer spans, like a decadak (week/month) and centadak (year). And just like our days of the week they have daks of the decadak and weeks of the year are decadaks of the centadak. It all rolls of the tongue pretty nicely, at least the goblin tongue and that’s all their really worried about.

The system was actually adopted only 143 centadaks ago when the paper crisis of centadak 0 nearly drove the goblin economy into the ground (what exactly caused the paper crisis is unclear as the the goblins didn’t have anything to write on to record the events). The goblins decided on this system because it produced nice square calendars. Thus paper waste was reduced nearly 23%. But I digress.

This star that’s circling has some interesting properties. First off, it orbits in such a way that the days are longer than the nights. That’s pretty good for these goblins, since they adopted diurnal activity long ago. Additionally, the star grows and shrinks with perfect regularity, as if a sine wave were controlling its size. The entire cycle of grow->shrink lasts exactly 100 daks. Or one Centadak. How convenient. The produces some nice seasonal changes across the surface of the flat world.

Things I’ve been working on lately:

• Entity definitions using scripts. This means that you and I can easily create entities using an external data file. The script defines everything from the layout the the entity’s body (organic or mechanical OR BOTH), to what items it produces for harvesting, to how it gets rendered. Pretty neat. It’s been fun working on that because I’ve been generating content for the game and it’s been sparking a bunch of ideas for improvements and additions.
• The time system. The system as described above has been semi in place for a while. A few weeks ago my wife and I sat down and made up names for all the daks in a decadak, for the decadaks in a centadak and the seasons. I implemented those changes and tied everything in to the various update loops. So now all the update logic uses in game time and the various aspects of entities from production times to movement speeds are defined using AoG time units. Currently the real world time of a single dak is 10 minutes. That means an entire centadak takes about 17 straight hours of game play to get through. I don’t know of any other games that take that long to get through an in-game year, so I don’t know how it’ll work yet. It’s something I’ll have to tweak as I go. But I think it could make for some pretty epic games. Surviving your first year would be a significant achievement. But then again with 4 hours per season, it may get dismal in the coldest months. I may implement a fast forward if I see the need for that.
• Harvest producing entities. I posted an image a while back of a tree producing way too many apples. While that was a funny mistake, it was the beginning of some really fun coding for harvest producing entities. Now using the entity scripts I can define a good number of aspects about production. So items can have production restrictions such as: time of dak, season of the centadak, minimum condition of the producer and a maximum per centadak. In addition to the expected required time to produce there’s also output options like dropping or storing in inventory to be collected by another entity later.
• The Lexicon.This is used to store all the parsed entities from the scripts into a one stop shop for producing entities. I can ask the lexicon to give me a goblin and it will produce a goblin that has it’s properties randomized and weighted based on the ranges defined in the script. The randomization ranges from body size to gender to what skills the goblin is proficient with.

Well that’s all from me for now. Thanks for your interest!

1 year on

Hard to believe that it’s been a year since I announced the development of Age of Goblins or Byte56Game0 as it was known then :). While I’d like to be further along in the development, I’m pretty happy with where I’m at. There is plenty of little things I would have done differently, but there’s also no way I would have known. Now I do! Thus experience is gained. Only a few major things I’d do differently if I were doing it over again:

• Use a pre-made engine. I have spent so much time building the engine for AoG that I’ve spent far more time making the engine than I’ve spent on game play code. I started AoG with a goal to make the game I wanted and to learn along the way. Yes, it’s been interesting to learn the ins and outs of game engines, and I’m glad I have that experience. But I do prefer to be doing game development, not engine development.
• Use an entity/component system from the beginning. Going with this from the start would have simplified things quite a bit. The entity/component system is fantastic, and I wish I would have tried it out sooner. It took about three weeks to rebuild most of the functionality I had before into the entity/component system.
• Started with something simpler. AoG is a very complex game. For my first game I should have made something medium difficult in 2D. But I went full out with very in depth, 3D game. It probably would have been quicker to learn the mistakes I did if I was learning them with a simpler game :).

Of course the plan is to still continue development of AoG, that hasn’t changed. I just wanted to share some of my experience with those that may just be starting. The plan is to have a public alpha sometime this year. I only work on AoG part time, so the going is slow, but it’s going. I appreciate the feedback I get from fans, so let me know if there’s anything about the game you’d like to know. Thanks for reading.

Gettin' around (a look at AoG path finding)

At the root of it all, the path finding for Age of Goblins isn’t that unique. The base algorithm is A*. However, it has some pretty nifty additions.

The Path Layer

Like most of Age of Goblins at the moment, all the cool stuff is hidden from view. The path finding layer is no exception. This is an invisible layer that sits on top of the terrain. It holds some pretty useful information:

• Zone: Zones define connectivity. This makes for a quick check to see if a goblin can reach another part of the world. If two points are not in the same zone it means one can not reach the other (don’t waste your time searching). However, if they are in the same zone, that means we can find a path so start the search for the optimal one.
• Score: The score is kind of a mixing pot for a lot of information about a location in the world. This score is taken into account when finding an optimal path. The higher the score the more likely it will be used in a path.
• Reasons a location may have its score increased: it was part of a successful path, it’s close to home, it’s in the shade, it’s near automated defenses, or a goblin found a penny there once.
• Reasons a location may have its score reduced: it was part of a failed path, it’s out in the sun, a goblin was attacked here, enemies sometimes hangout near by, it’s far from safety or a goblin once lost a penny there.

Pathing Tokens

When paths are generated they are a good deal better than just a list of points to travel to. All the entities in Age of Goblins get around using Pathing Tokens. These tokens all contain a position, a token type and a pointer to the next token. The tokens not only tell the entities where to go they tell them how to get there. For example, the most basic token type is ‘Move’. This simply tells the entity to move towards the position contained in the token. The type of moving is governed by the entity, be it: walk, run, slither, crawl or ooze. More interesting types of tokens are a few like: ‘ClimbUp’, ‘ClimbDown’, ‘Stop’, and more. Climb up and down are obviously very useful for changing the animation, speed of movement and direction of movement. Stop is useful for knowing when the path is ending or when we’re about to get to a cube we need to climb. There are others like ‘TakeFlight’ and ‘Land’ that’ll tell flying creatures/gadgets which part of their paths require them to go airborne and when to land to scuttle along on the ground.

Finally here’s a little debug screen shot. The two vertical lines, red and yellow, represent the next and current (respectively) pathing tokens. The red being a ClimbUp token and the yellow being a Stop token. The red line under the goblin represents his acceleration, and as you can see he’s slowing down to the Stop token. He’ll then stop at the base of the wall, and proceed to climb up to the top. It doesn't look fantastic without animation, but I’m no animator so those come later :)

A fairly rushed video, just showing a few of the additions to Age of Goblins recently. Now, back to coding!

What resources (books, websites) are you finding helpful while creating this game?

As always Google is a programmers best friend. Honestly I find most of my answers through a Google search. Other than that, I’m active over at the GameDev StackExchange answering questions and asking a few of my own. It’s a good community and answering questions there keeps me in good mental shape for thinking about how to solve my own programming challenges. 

Most recently I’ve found some useful information at these sites:

• http://www.red3d.com/cwr/steer/ For implementing smoother path finding and obstacle avoidance.
• http://gamadu.com/artemis/ Really helped to look how they implemented some of the aspects of a entity/component system
• http://www.gamasutra.com/ Has some pretty good articles for all sorts of things, from path finding to interviews with other developers about their games.
• http://www-cs-students.stanford.edu/~amitp/gameprog.html Amit Patel has put together some great resources for a lot of different aspects of game development. His map generation work is pretty interesting.
• http://roguebasin.roguelikedevelopment.org/ Has been a good resource as well and I’ll likely use that even more as I get into the combat system.
• WorkFlowy I use for tracking my to-dos, ideas and all kinds of other stuff.

Thanks for your interest and thanks for the question!

Entities, attributes and behaviors... oh my.

This weekend I’ve been switching over to a entity/component based architecture for managing units. So far, I like it. Perhaps it’s just because I’m re-writing portions of the code, but the entity/component system is so much cleaner than the inheritance system. This should make units in game far more expandable and end user customizable. My system is pretty similar to the some other entity/component systems out there, it’s broken up into:

Entities: 

    Pretty much just the containers that get passed around. These have unique IDs that distinguish them from other entities.

Attributes: 

   The data parts of entities. Things like Health, Position, Motion, Model,Inventory and much more. These are added to the Entity containers to create a unique class of unit. Typically these attributes don’t do much in the way of functionality, beyond just basic logic. Using Health as an example, it has two ints: currentHealth and maxHealth. Some basic logic would be checking to see if health is below a critical level or zero. As an example of how these are used to create entities, something like a spore plant would get Health, Position, Model and Attack attributes. While a goblin would get all those plus Inventory, Motion and more. This allows for so much flexibility when it comes to creating units. With the inheritance system I’d have to either find some common unit for both spore plant and goblin to inherit from, or one of them would have portions of themselves that would never be used.

Behaviors: 

    These are entity processing centers. Behaviors cycle over all the entities looking to see if they have the attributes required for a particular behavior. For example, the path following behavior. An entity has to have Position, Motionand Path attributes in order to follow a path. If an entity has all those attributes then the path following behavior can act on that entity. It’ll take the entity’s Path attribute to see where the next way-point in the path is, then update the entity’s Motion attribute to have it moving in the direction of the next way-point. Later another behavior handles updating the entity’s position based on the movement attribute.

I got it to the point where it’s taken over unit rendering and path following. Having a nice clean system like this make it much simpler to add new functionality. So when I add in combat I just have to create an attribute and behavior for it. Then add the attribute to the entities that engage in combat, and everything else is taken care of. Really nice.

While implementing this entity/component system, I threw in a system for loading brand new entities from text files. This means that end users can take existing attributes and mix them to create a new type of unit. Even allowing you to define the model, texture and animation! Obviously this makes things easier for me too, so Win-Win.

Unit rendering using the new entity system, with no visible difference from before!

Hand down, productivity down

Unfortunately, it’s been an unproductive week. Here’s the reason:

That’s my bicycle. It’s how I ride (rode) to work 5 days a week, 8 miles a day. Last Thursday evening on my way home from work, an on-coming car turned left directly in front of me. That caused me to hit them and break my bike in two. I didn’t get away unharmed either, the doctors say I have a fractured left wrist. I’ve been in a splint for a week and today got upgraded to a cast. The splint was super restrictive and limited my typing to right hand only. Luckily the cast starts just below the knuckles of my fingers, I can type again! More good news came when I learned that the other insurance company was accepting full liability (rightfully so). That means the replacement bike will be paid for, sweet.

I was able to do a little one handed programming however and I got some things done before the accident. World maps are now tied into the “colony” play areas, meaning I can generate new colonies and load existing ones from the world map. I’ve also started working on expanding the unit AI processor. Finally updated the control flow for adding and removing cubes. They complement each other a lot better now. Adding cubes also show up as cubes that can be interacted with as well, this makes it a lot easier to create more complex structures in the planning phase. It’s something I’ll have to demo in the next video to get full appreciation.

Unit improvements, inside and out

Inside

I’ve been working on stuff that’s hard to see. Because it’s on the inside. Goblins (and all the other creatures in the world of AoG) now have a system for defining their insides. This means that location based damage can have specific detrimental effects. For example, slicing into the upper arm of a Goblin has the chance of nerve damage, therefore disabling the use of that arm and hand. Or if a goblin cuts off that vibrating appendage from the right side of a gavartick, it dies (that’s where it’s heart is) (note: the gavartick is not a real creature yet, but I guess I’ll have to make it one now, who wants to draw a gavartick concept?).

The system also allows for dynamic dismemberment. Battles can result in arms, legs and hands being strewn over the battle field. The internals system is tied to the animation system and task system to restrict or disallow certain actions based on the limbs remaining. But the Goblins are clever gadgeteers, I’m sure they’ll be able to make some pretty nifty replacements ;)

Finally this system is useful for some material gathering purposes. Knowing what the internals of a creature are allow you to gather specific materials from it. Materials gathering is not currently in place, but here are some examples:

• Bones can be used in place of wooden sticks for construction. 
• Eye balls can be used in movement sensing gadgets. 
• Brains can be re-purposed to process gadget logic. 

Most of this new system is not visible yet, so I don’t really have anything to show off. But I’m working on that.

And out

I rewrote the model importer to use the DirectX model format (Thanks Mr. Shaw!). This allows me to know which parts of a mesh belong to which bones and (along with a special naming scheme for the bones in Blender) I can use that information to define limbs for dynamic dismemberment. Additionally the .x format gives me all my skeletal animations. I’m in the learning stage of animation. It’s fairly complex with lots of different methodologies. I imagine I’ll implement a LOD system for the animations based on the units on screen and their distance from the camera. Perhaps with some limited total number of bones being animated at any given time, I’ll have to test to find out what that’ll be. However, I’m holding off on animations for now, so I can improve some other aspects of units and think/learn more about it (plus I’d have to be all artsy and create animations to test it out).

The new importer and subsequent drawing code is working pretty well. I posted on twitter a few days ago my success with drawing a good number of goblins with little performance loss.

There are 100 goblins in that image with a medium to large size world and I’m getting great performance. The way I managed that was pretty neat. All the goblins are drawn from the same VBO. Each unit has it’s own transform matrix for rotation and translation. The transform matrices are put on the graphics card in an array and get updated when unit positions change. Then when drawing each one of these units, I send its transform index to the video card, then the video card uses the matrix at that index to rotate and translate the vertices associated with that unit. Pretty neat.

I’m currently improving the way units find paths and move around the world. I’m integrating physics into their movements and more realistic paths. For physics, I’ve started with the Bullet physics libraries (unless someone has a better alternative?). It’ll be fairly simple physics stuff to start with. Just stuff like falling down if the block below them is removed. For path finding I found a nice article from Gamasutra for creating better path finding. The current system uses A*, with a few modifications and cubic splines to smooth the paths. The new system will take into account unit width and height, so I can have units larger than a cube (the current system is based on the assumption that all units are no wider or taller than a cube).

I’m still really enjoying my game development. I’m starting to focus more on getting some core features put in so I can start alpha testing sometime this year (I’m just one developer here, I have to set easy goals). Thanks for reading!