At the start of my epic stay-cation I had huge ambitions: I was going to have a basic playable demo of the game up and running by the end of my break for anybody to check out. Well, it didn't take to too long to realize that I was lying to myself on my time estimates when scheduling.
I simply neglected to double my time estimates when planning. Normally this is second nature for me at work when dealing with a high stress production environment. Even in that situation where we already have huge advantages like, I don't know, a game engine, or a decent pipeline, tools, and lots of talented people; Even with these advantages, sometimes those time estimates can be tight.
So throwing down into an environment where I'm staring at an empty C# project called "SeaBomb” (the name of my intended game engine) and a little voice in the back of my head telling me “What the hell are you doing, just go download Unreal?!?” I found that all my initial expectations and plans ran over by at least 3 times as what I initially predicted.
In the end, I looked over my initial post, and decided to re-prioritize. I wanted to make sure that I could get a lot of the heavy lifting and back end work done fairly well before going back to work. The kind of things that are demoralizing and difficult to do after a full day at work. Additionally, I reinforced the desire not to use a ready made game engine, this exercise was to primarily educate myself better in programing. Keeping that in mind, here's the break down on “The Plan 2”:
5 goals, in 5 weeks. That blank project file was looking better already. Still didn't stop me from procrastinating away on an engine start up screen though :P
I decided to keep the core engine code, the game project, and build pipeline in the same repository. Additionally, I set up a post build step to copy the game and the build tools into a folder outside the repository, and created links to them on my desktop. A .Gitignore file was set up to ignore any files that were built by Visual Studio, and any back up files produced by art programs. I know it all seems like simple things to do, but they achieve a couple of things I find important:
Ok, so sue me, I spent some time procrastinating on making icons for the build tool, and the game... Hey, it's the little things in life sometimes.
To start out with (and indeed for the majority of my holiday time), I wrote the asset classes. These are things like Image, Material, Shader, and Model, and the AssetManager. It's this work that XNA had already done for me on my last engine, and is where my time estimates fell apart. The asset manager deals with loading and caching of these items, and their dependencies, so they never get stored in memory twice. Requesting an asset looks like this:
Along side this I worked on my build pipeline. I really wanted to keep any external libraries that are not core parts of the game engine completely away from the game code.
The build pipeline at the moment is fairly simple. It works out a dependency tree, and then builds everything in the order needed. I don't currently cache any intermediate data, and I always build everything for now; All problems I can tackle later on when I'm building enough data to need it. As an aside, this morning I played around with Graphviz and the dot language in my build project to produce a nice graph of the dependencies. If you haven't seen this program, check it out, it's pretty neat!
As you can see from the graph, I've used Lua to describe a lot of data formats. There are a couple of reasons I've done this over using XML:
I'm not yet committed to using Lua in my game project, but converting this data into binary files in a build pipeline means I can put off that decision until later. An example of a material definition would look like this:
The pipeline is also driven by a Lua file. For example, to build the loading screen models, and a gun, my content file looks like this:
At any rate, after a tough couple of weeks of programming, I sat down to do some low poly 3D doodling for the main character ship idea. Yup, procrastinating again!
At a very basic overview, an Entity Component System (ECS) is a way of organizing data and functionality in a modular way, that allows for flexibility, and (hopefully) efficient processing of data for game systems.
The entity is effectively your game object. The components are effectively data that get added onto entities. The systems are the processes that run over that data defining how everything behaves. I won't go over this in detail, I read many great blog posts about this, and they'll explain it far better than I ever would:
I set about implementing a fairly basic ECS with 4 basic components:
This finally allows me to render something on the screen! So, coming up to the last weekend of my stay-cation I quickly jammed in a couple of game states:
Enjoy the vid :) I know it's not much, but hey, I've learnt so much over the last few weeks! Additionally, I feel like I've done enough heavy lifting that I'll be able to continue on with some interesting things in my own time after work.