An Update after a long time

It has been a long time since my last update.

I haven’t not been working on the game engine… but I have been working quite slow.  A lot of it has to do with refactoring nasty code and adding some lower level functionality like finalizing my packaging system and getting a separate program up and running to do all the packaging.  Along the way I’ve taken a look at a few libraries and stuff.  I’m using boost right now, a library I never wanted to include, but it has become necessary for loading resources from their proper location (the root directory of the program) which is stupid to do apparently, without using it.

At any rate, except more updates soon.  I’ve had to completely redo my configurations because of boost.  I’ve NEVER required Debug builds but boost won’t build at all if I don’t have the correct runtimes with the build/debug build options.  I hate it, but I guess it’ll go nicer in the long run.

He said “Hey! You’re not writing code fast enough.”

It has been a decent amount of time since my last post.  I’ve been wanting to post, but I’ve put it off.  What have I been doing?  Well, not working on my game or engine for that matter.  I poked a bit at doing GUI prototypes in Processing and recently started writing a simple Documentation processor that will read my code files and generate formatted HTML pages for them (yes, I know a plethora of them exist, but so what?) but other than that I haven’t really touched any actual game or engine code.  The reason?  Well, its mostly that I had run out of gas.  It had become about “man you really gotta finish that” rather than enjoying myself while finishing it.  And yeah, in the real world it is very important to get things done in time for dead lines… but I have no deadlines.  This project isn’t really a show off project, it is all about crossing off something from my list.

Since… March (maybe?) I shut my programming mind down and focussed purely on the entertainment/creative side.  That is right kids, I got my GAMING on, and in a big way.  I’ll summarize.  Minecraft.  Minecraft.  Minecraft.  Counter-Strike.  And now I’m well into Rift.  It really is a great game.

I put together a server as well.  The intent was to host the private Minecraft server on it, rather than on my main computer.  The problem is now, that none of my friends ever play it so I’m kind of stuck.  The server would be great for other projects though.

I’ll discuss my current projects that relate to the game engine later.

Game Engine: Cameras!

I finally put the final touches on a basic editor camera… finally.  The only real hold up was getting the mouse look working correctly and then being able to strafe the camera.  The next step is to work out exactly how the editor will function.  It is a 2D/3D hybrid engine currently, so when the level editor goes in close to the collision geoemetry, scalling is everything.  Perhaps a button to zoom out to the in-game camera location while the button is being pressed?

I plan on reimplementing the grid system but I won’t have multiple views like last time around.  I want to keep it simple and a single 3D view is enough for now IMO.  Some features like binding the camera to the in-game distance from the world and locking rotation will help with level creation though.  And speaking of level creation I think I still need to write the Level saving method in my package system.  Shouldn’t take too long but little tiny problems keep popping up and impeding my glorious work!  Muhahaha!

At any rate, the basic editor is almost done.  No real GUI as of yet, but I might work out a system where I won’t need one.  The tools behind Love use all custom tools with a custom GUI system… its very nice.  I might mimic something like it… or die trying.

Game Engine: Level Editor

Since I my last rewrote, I’ve been focusing mainly on background engine stuff that wasn’t quite where I wanted it to be.  At some point I started working on game-specific stuff as well, although most of it is simply in place to test engine functions.  Well, I wanted to get more focused on game-specific stuff but I realized I was missing some way to efficiently make test levels.  So I started working on a level editor… a few days ago I believe.  I don’t need anything fancy.  Just a basic editor that will let me edit the 2D collision geometry alongside the 3D visual aspects of levels.  I started working on collision geometry part.  All that it requires was being able to draw line segments.  Long story short, I ended up requiring to find a point along the ray created by the conversion from Screen to World coordinates.  The collision geometry is always at a z-value of 0 but this required me to find a point along the ray which had a z-value of 0 so the segments would properly line up with the mouse when you’re drawing them.

This gave me a headache.  I tried several solutions, going from seeing if I could form triangles to find the points I need (which, actually might have worked if I stayed with it) to  arbitrarily adding stuff to the slope formula.  I looked around the internet but couldn’t find something that screamed “This is what you need!”  Perhaps I wasn’t wording it quite right, but then again I wasn’t sure how I should be wording it anyways.

As I am partly hopeful for the future of the Internet (and the people who use it), I half jokingly asked on a Counter-strike server I frequent if anyone knew how to solve this problem.  Inititally, I was met with ridicule, so I let it be.  A short time later, another player started asking questions.  A little bit later, he was showing me parametric functions that I need.  So, I am very grateful for him showing me how to go about doing it.  In doing so I have gained two things:

1. Calculus I != Calculus III and it is something I should read up on as I will be doing crazy stuff like this in the future.
2. A new, very useful function to add to the utilities library.

I figured I needed to UnProject so currently I’m using glut’s implementation of Unproject but I will hopefully be creating my own implementation in soon.

Bottom line – the new editor will definitely be more feature complete and in less time than the previous iteration.  Now, I need to find a good GUI Library where I can simply add a toolbar or new windows without having to use a special framing class.

Game Engine: Yet MORE Lessons

I currently don’t have an animation system in the engine.  This means that I can only rotate a single object (group of one or more models) about.  So now I’m curious as to what I should do. 

1. Take the time to implement a decent Skeletal Animation system.  This can be considered overkill at this point, I think.
2. Implement a custom animation system.  I will be developing custom tools at some point to leverage the custom content/formats I need so it makes sense to a certain point.  I don’t need something complex, just something really simple.

I’ve only started to think about this but the reason I cannot rotate individual models is the way I’ve architectured the engine, and I think I’ve done it right.  A Model, a set of meshes/vertices/triangles/normals/etc. has no concept of rotation or location…  it only has knowledge of the local location space, the offset of each mesh in the model, etc.  An object is a collection of Models and the only interface that can be used to render a model onto the screen is the DrawAll method in the RenderingManager (a component of every drawable object).

The RenderingManager only has one Location and Rotation variable.  Because I don’t have great modeling skills, putting a whole bunch of meshes together to form a single model is really annoying to me, and the fact that I have no animation system in place means I’ll have characters with arms and legs stretched out “running” all over the place.  The temporary (or permanent) solution was to add a collection of model offset vectors to the RenderingManager that would correspond to each loaded Model.  DrawAll will iterate through the list of models and call the Draw method with the newly added Location Offset argument and it will render a given model at an offset from a fixed location (for example, the origin of the object.  The interface to set these parameters isn’t very nice (you have to push stuff onto vectors from within the objects init function) but that can get better.  What I’m wondering now is if I should also add a Rotation offset, that is, a rotation variable that will affect the model around its local origin rather than the objects origin, or should I come up with some better strategy.

The benefits I see are that I can directly write an animation system that takes advantage of the location and rotation offsets.  The only downside I can think of right now is the amount of time it’ll take to create animations without a tool (which I guess is true with a skeletal animation system as well) and the pre-processing/speed and beauty of the final implementation.  Skeletal Animation has been around for awhile, and its tested and well supported now.

A key frame system has been around longer, is somewhat easier to produce I think, but more than one animation for a given model(s) can be monotonous as you don’t have that basic skeleton template to work with.  I shall have to do some more thinking.

Edit:  On another note, the model rendering system makes building a Particle generator as a single entity a lot more difficult if I plan on having the ability to add “distict” particle generators in a single entity.  IE.  Flames and smoke coming from a single object rather than two seperate emitters.  I will have to plan it all out so I don’t shoot myself in the foot…  again.

Boolean Logic and States

I’ve been fighting with an issue with the Physics Engine.  Not really an issue with it persay, but perhaps I how I am using it.  Basically, if you apply an amount of force on the X-axis while you jump and you hit a wall, you will effectively be stopped.  Likewise if falling, you can stop falling by applying a force on the X-axis and you will stop on the wall.  Now, in games like Super Meat Boy, you can wall slide, that is, apply a force against the wall and you will slowly slide down it however;  You cannot completely stop while doing this.  You can however jump off the wall.

This functionality, while fun in many games that take advantage of it, doesn’t currently have a place in my game concept.  It just doesn’t feel good and actually looks more like a bug the way it was anyways.  So I tried to fix it.  I’ve messed with the friction, gravity, amount of force applied and none of it fixed the problem.  Just now I considered a solution that I haven’t really used for a long time, in this fashion anyways.  I use Booleans all the time for keeping track of things/states, but I rarely have a triangle relationship between three booleans.

I was already keeping track of when the player landed with bLanded.  A player lands when their velocity is between 0 and 0.3.  This is due to the accuracy of floats.  Using a velocity of just 0 does work 99% of the time however, but when the game gets more intense, I’m sure that accuracy will drop.  Now, my player input system uses the regular input system to create two outputs that range from -1 to 1.  These outputs are called fLeft and fUp (there is also fForward but since the engine is using 2D physics, it is useless ATM).  If fLeft is negative, the player is supposed to go left, if fLeft is 1 the player is going right.  fUp is 1 for up and -1 for down.  Yes, they should probably be renamed to something that represents more clearly what each value is called, but for now it works.

When the players velocity is within the range of 0.0 to 0.3 and bJump false, bLanded is set to true.  Following that a check is made to see if Force.y is greater than 0 (Force.y is calculated by fJumpAmount*fUp, so Force.y will be a positive force in the Y direction and -Force.y will be a negative force in the Y direction).  If Force.y is greater than 0.0, an impulse is applied on the Y-axis with a force of Force.y.  In this case, the jump amount is 6000 because only Impulses will be used to work with thY-axis.  In the grand scheme of things, the Velocity gets limited though, so I could probably just use a really high force value as well and apply a force instead.  If an impulse is applied, bLanded is immediately set to false and bJump is set to true.  This isn’t entirely true though, as for the time being, bJump is set to true whenever the velocity in the Y-direction is greater than 0 and bLanded is false.

Note: Eventually, I want to implement a function that will accept an offset location and calculate the force required to reach that offset.  This way, I can use variables like “fJumpHeight” and “fGroundSpeed” to describe how the objects will move.

bFalling is set when the velocity is less than 0.0 and bJump is true, at which point bJump is set to false and bFalling is set to true, otherwise it is false.

So, bLanded is only true if bFalling is false and bJump is false.  bFalling can only be true if bJump (but will set to to false after, so basically only if bJump is false – both of them can never be true at the same time). bJump can only be true if bFalling is false and bLanding is false.  States.  Simple, boolean logic at its best.

Now… one slight problem remains and that is air control.  Games have had air control for ages and it is annoying when a game doesn’t have it.  I disable forces in the X-axis until landing so…

Game Engine: Particlezzz

I’ ve been thinking a teeny tiny bit about the effects in the engine.  I don’t need something eye popping or mind blowing, just a simple system to develop special effects with.  To this end I’ve decided to create my own particle engine instead of finding yet another library.  I think it will be easy to implement if I do the initial planning correctly.  I was already thinking of using Amateura, the currently bugged scripting engine that I wrote for the game engine itself.  Last time I checked the only problem was parameter passing for nested functions, and I will essentially be using scripts as configuration files with a little bit of dynamics if needed (i.e. custom functionality in a function that will be called from C++)  Because the renderer is already static, I don’t have to do very much work.

The physics is getting to a point that I’m happy with.  Dynamic objects (ie. a Crate you can move) aren’t quite right yet so I will use them sparingly.  There are other physics quirks with the way I’m detecting when a player lands, as well, but the correct solution is going to be somewhat tricky and often annoying to work with, so it has been suggested that I just turn it into a feature, but after thinking about it, I might do.  The desired game I want to make is dark/moody though, so I’m I don’t know how basically mid-air jumping is going to work.  Its more like wall-climbing as you can only jump infinitely if you’re against a wall, but it still looks funny.  The other solution I can use is to simply not have large cliffs/hills.

Game Engine: Architecture Update

After struggling with “ownership” architectures, I finally decided on an “ownership of responsibilities” layout that I think will work now and in the future when the game engine gets more feature complete.  I did some more research on the topic of global vs singleton vs non-global approach.  The general idea is that most people never use singletons correctly and globals should never be used anyways.  I do agree with this for the most part but I think it is a little overkill to say that all global-type variables/classes are evil.

In the case of the renderer, it almost has to be global (or be a singleton) because 1.  It needs to be accessed by SOMETHING and 2. You should only ever have one (or you’ll run into two+ renderers fighting for control and reintializing windows).  A singleton would work for this I guess but for the time being I’ve taken another approach.  Some time ago, I somewhat implemented a component-based system object system.  It isn’t 100% component, but it gives me enough freedom to do what I want and to seperate responsibilities if needed.  It isn’t used very much in the way component-based systems are supposed to be, but it has organized object creation a lot.

Currently I only have three components that can be added to a class.  Here, objects aren’t created dynamically (something a true component-based system would allow) because while I like genericity sometimes, objects just seemed to be a collection of objects that had no connection to eachother other than that they occasionally pass messages back and fourth.  Another reason why I didn’t want to go full component-based is the messaging system itself would be a great pain in my side.  So, to define an object, you simply declare variables of each component you want in the class schema.  The three components are RenderingManager, PhysicsManager and InputManager.

The InputManager deals with all input.  The only game object I have, the player, doesn’t actually use this component directly.  Another component PlayerInputManager, uses the InputManager to create a mangeable interface between player input and actions.  For example, pressing Escape sets the bExit boolean to true in the PlayerInputManager (which is a variable in the Player object).  This will also allow me to create a Key Binding system easier.

The PhysicsManager handles all of the physics properties/objects of a given game object.  Currently, I don’t have an wrappers for the actual classes contained in Chipmunk Physics (the physics engine I am using) but the PhysicsManager acts as a wrapper to the functions of Chipmunk.  This component is responsible for creating rigid bodies and adding collision shapes to that body.  Later on, the Level object cycles through all of the game objects in the world and adds each rigid body and shape to its physics space.  The handling of the creation of the rigid body and collision shapes is handled through each parent objects constructor. 

The RenderingManager used to simply hold the rendering location/rotation/scale and a couple of other properties and methods but now this component is responsible for everything to do with the Renderer.  It holds a list of models, model names and model offsets as well as functions to draw the models.  This means that the Main method is no longer responsible for dealing with rendering at all.  The Renderer is -still- global however, and currently I see no problem with that.  Later on, I may move to a singleton system.  It is only a problem if I start access the Renderer again from outside the Rendering Manager, and I will only do that if I want to test some rendering stuff.

Currently, Main still holds a reference to the PackageManager, which isn’t a component that can be used by game objects.  Since I’ve moved total control of the game world to the Level entity, I will be moving the package manager reference over there I believe as the Level will have to preload all content and what not.  I am unsure about this decision though as I will need a seperate Menu entity for authoritative control over rendering menu items.  I may leave the Package Manager in Main and keep a list of content that needs preloading in the Level entity.  Then I will go through the list and preload each asset from Main.

At any rate, the engine is FINALLY shaping up into a workable state.  I can soon start doing less behind the scenes work and more game work.

Game Engine: Packages

I did some basic work on the packaging system tonight. I don’t know what I talked about last post with regards to it, but I’ll go over it now.

Every game asset will exist inside a package. A package is simply a container file that holds the resources needed for the game. Until the engine gets more polished, I won’t be incorporating zlib, but that is on the agenda for “some point” in the future. So currently, a package is simply an uncompressed file with a number of resources held inside of it. At the beginning of a package is its name (for simplicity, its name should equal its filename minus the extension anyways) followed by the “Table of Contents” which is then followed by all the art assets.

The table of contents is a list of the assets in the package and their locations in the file. They also describe the type of asset as well as the name of the asset in question. Ex: “model fireball 0 52″ describes a model called “fireball” who’s file starts at line 0 and goes to line 52. Nothing fancy here, for now.

Textures, sounds, music, etc. will be stored in these packages and they can be stored in a variety of different ways. Because the table of content describes what content is stored in the package, you have the option of storing all of your game assets in one place or distinguishing models from sounds in case you have two different people working on the project who’s specialties are modelling and sound respectively. I probably won’t be seperating the files.

All games on the Unreal Engine put their assets in packages so its pretty much like that although last time I checked all assets have the ability to be placed into one package but editor/engine limitations force you to keep these seperate. I believe Guild Software also bundles Vendetta Online together into one package and compresses it with zlib (and probably encrypts it *shrug*)

I have yet to decide whether to include level files into the packages, but it can be done very easily.

When a package is loaded, its table of contents are stored as well as the file itself. Using the table of contents, a Package object is created that is filled with all initialized assets that belong to the package. In the future, this will cause severe issues because of memory usage so a “load as needed” approach will have to be implemented. I will have to write a seek wrapper for the ifstream to allow seeking to line numbers to load specific assets or instead of storing line numbers, store byte numbers so I can use seekg. I’m not a fan of either approach however.

The package object is held in memory until it is no longer needed. The basic resources will probably always be needed but specific map packages likely won’t need to be held around. Because I’ll be storing all assets in one package, a pre-loader handler will be needed too and I will definitely have to implement random access file input based on line numbers.

To get a model asset, you need to call GetModel for example. I want to implement a simpler way to get at things though. Packages will be organized based on what type the asset is, so I want to be able to do something like the following to load any asset I want:

GetAsset(“myPackage.myTestAsset”) and depending on the context, have it figure out what type I need. I could settle for specific get methods like “GetModel” or “GetTexture” as well. I’ll see how long it’ll take to get it to where I want it to be.

Game Engine: Level Format

I have a basic level format down. It is seperated into three sections, Collision Geometry, Visual Geometry and Scripted Assets. There is of course going to have to be a section about basic level information as well… name, max players, etc.

Collision Geometry will be all the geometry that will be used with collision detection. For the time being I won’t be using the collision hull of models because it will usually be a 3D collision hull which is not something I can even use. The collision geometry will mostly be line segments but won’t ever see the actual geometry. It will be positioned with the Visual Geometry so when you walk, you’re actualling walking on the collision geometry but you look like you’re walking on the visual geometry.

This is… slightly imperfect as wrong positioning of the model and it’ll look weird, so a nice approach will be needed… prehaps a terrain generator that expands outwards in the Z direction from a single line, so your model base would always be touching it. And it would look cool. I’ll look into that. Moving on…

Visual geometry isn’t restricted to 2D space like Collision Geometry is so it can be placed anywhere. It will also provide the bulk of the look and feel of the game world. I’m thinking of 3d backdrops, mountains moving, making some boulders that weave in and out of players view, all while the player is restricted to a 2D space. Those flash games are all pretty addictive though.

I’m too tired to write more… I’ll continue this later.