Priority shift - Asset Management and Environment Physics

So, getting ready to dive back into things again, I realized there is still a large amount of framework to lay down before a full prototype is feasible. Particularly, with dynamic asset management. I've just completed a functional asset manager class, that is used to optimize loading and unloading of assets, to allow both preloading, and dynamic loading of texture and mesh files. Lastly, I've set up a series of easily editable data files, containing lists of ship parts and other useful data. This will become more useful in the next few weeks, when I will be saving out level data into these files.

On the subject of level data, I've decided to shift my focus a bit. I was going to work on the projectiles, but I realized before that, I need something for them to collide with. So, first things first, I'll be adding some simple physics to the planets including orbiting other celestial bodies. I would like the physics to play out some what realistically, so the planets gravity should affect certain projectiles, and deployed weapons as well.

This of course sent my imagination on a complete tangent, thinking about surrounding planets with an orbiting mine fields, or sling-shotting homing missiles. Then of course, the part of me with some semblance of scope kicked in and ruined my daydreaming. For now, I'm setting up a specific environment, (rather than the randomly populated one I've been using) with basic physics. Sh

Move to LA - Finally Settled In

It's been a while since my last status update. Packing up, driving across the country, and getting settled in, hasn't left me much time to work on things. Now that I'm all settled in, and have a steady source of income, I'll be picking up where I left off.

Although there are a ton of optimizations that need handled, I'd like to have a playable prototype sometime this millennium, so I'm going to work on adding a projectile based weapon to the player's ship.

Finally Finalized Rotations

Yet another good news/bad news update. The good news, is that I've got proper rotations, and parenting all locked in. Previously, gimbal locking was preventing my fingers from bending properly. Given how many iterations of different rotation calculations I've been through, I'm pretty excited to be done with them for a while.

Unfortunately, the bad news is that my camera smoothing has completely broken. The problem stems from this: The ship, rotates between -180 and 180 degrees. So, if the ship goes below -180, or above 180, the smoothing detects a change of 300+ degrees from the last state detected, to the current one.

I've got a few ideas for workarounds, but I'm putting the camera smoothing to the side for now. It makes the movement look nicer, but isn't really a priority task at the moment. I've got enough missing functionality, to be caught up reworking what is already functional.

Also, I threw in a 'sky' dome, and some asteroids that sort of look like cookies. The environment is still randomly populated and is just there so I can actually tell where the ship is moving.

Quaternions and SLERP

Well, the transition to quaternions was pretty painless. They aren't quite as complex as I was expecting, and GLM makes them very simple. That's the good news. Unfortunately, this caused my camera smoothing to go haywire, since it was relying on the older method of rotation. Not to big of an issue though, since I've been needing to rewrite the camera smoothing function for some time. The old method would cause some wobbling if the ship were to turn too fast. The next step is reading up on SLERP.

The Engine Overview

Seeing as how I finally have some visible progress to show, I thought I might create a development log for my engine, tracking it's progress. I doubt I'll be posting much code here, but if you are interested in seeing it, or just have a question, feel free to shoot me an email. You can find my email on my site here: http://www.GamesByMike.com

The Team:
Mike McCollum - Programming
Derek Hetrick - Artist

The Project Goal:
I'm building a 3d game, within a custom engine for PC. Although I would love to someday publish the game itself, the biggest goal of the project, is to breakdown, and gain a more thorough understanding of engine development.

Since my team consists of just 2 people at this point, we decided to take a simplified, slightly stylistic approach. We are supporting flat lighting with diffuse maps only, since getting tangled up in lighting and shaders, could amount up to a very large addition to an already massive project size. It seems best to choose an artistic style that fits within our current scope/skill constraints.

The game is a 6 axis shooter, with a strong physics and grappling component. The core mechanic consists, using your robot, to grab hold of, throw, crush, or otherwise tear apart your enemies, and assimilate their parts onto yourself. We are aiming for an Einhander (for ps1) like mechanic, mixed with Katamari, where as you battle on, your robot grows and grows. As you assimilate more enemy ships, you gain more power and thus assimilate larger parts.

Built using OpenGL 4, SDL 2.0, and GLEW.

History
Some background: The engine started as just an attempt to delve into basic 3d rendering, using openGL and c++. Once there was an artist on board, we decided to make it into a full 3d game engine. It's been my first attempt at creating a 3d engine from scratch, so much of the core programming had to be learned on the fly.

Progress
The first several months of development consisted of laying out the basic framework for the engine, as well as creating a series of proof-of-concepts. After each stable build, I collected feedback, updated my existing code, and repeated the process.

In the beginning, I was following some tutorials from http://www.3dbuzz.com/. If you are familiar with them, you may recognize a bit of the content. While functional, and very helpful at first, they are severely outdated. (Or at least the ones I used)

The first worthy screenshot of progress. It’s more here for nostalgia than anything, since it is just a simple demonstration of openGL rendering, a loaded texture, and applying it to a cube. At this point, I was still using SDL 1.2, and openGL 1.

A Loaded 3D model from an OBJ, I had created some time ago, with an applied texture (Diffuse Only). Without normal maps, he looks a bit odd, but that’s alright, since he was a simple proof of concept, and will not actually be featured in game.

This was a demonstration of parenting hierarchy, and application of transforms. The parenting hierarchy is crucial, since grappling will be a large part of the game, and the parent/child trees can shift rather dramatically.

Flash forward a few months. It was very much like stepping through 20 years or so of technological advancement in a few months. Moving from manual openGL draw commands, to vertex arrays, upgrading to openGL 4.0, delving into shaders, ect. Basically, I had to rewrite a large chunk of my old code. At that point, this was not a bad thing, since the engine was a gruesome mismatch of various tutorials, integrated into one. With each upgrade, a new interface would need to be added, sometimes stacking two or 3 on top of each other. It was my Franken-engine, and it was indeed a monster. Shortly after the rioting villagers destroyed it, I built the current engine to be far cleaner. Since I had already slogged through getting it wired up the first time, the second build took far less time.

 At long last, things are up to date, (or at least as up to date as is practical at this time) and I've moved forward into setting up the engine for game play.

Current Progress

Here is a screenshot of the current WIP, with a demo environment. It takes a planet and randomly populates the scene with them. This helps while testing things like player movement, and physics. The ship also only has a single arm. That will be explained below.

The controls are in place, and the player can move around the world, albeit without collisions. I have systems in place for dynamic object creation, but they will still need optimized, since they are not yet sharing redundant data, and there is a ton of it.

I've just finished implementing the camera system, which allows me to define several cameras within the scene, and switch to them dynamically. Additionally, cameras can be given a target, which they will 'follow.' There is a bit of tweaking, to the camera smoothing, but for the most part, I like the effect it gives.

I'm still ironing out a few kinks, but I'm finalizing the transformations now. The parenting of the various mesh parts is working fine, but recently, I've encountered some gimbal locking while rotating some of the parts on the player's ship. I'm starting the switch to quaternions. I had of course heard of them prior to this, but until the Euler angles started giving me trouble, I had yet to dive into them.

The last major issue, is that our current importer is insufficient for our current needs. Specifically, the ships are made up of many parts, that need to be split into individual pieces, and attached in a parenting chain. For this first ship, I have set it up manually. The next update will feature a more robust importer that will take in parenting chains from 3Ds Max, as well as dividing objects into parts automatically.

And that's it. Everything for the engine thus far. Thanks for reading, if you made it this far. The rest of the updates will be considerably, shorter. This one ended up a novel because there is so much to summarize.