Editor Stuff

I've gotten a bit more work on the editor done. I'm still trying to think about how exactly I want to hook the "gizmos" in. I want a customizable interface so plugins can add their own gizmos and they function like the built in ones. I am currently implementing the 3 basic gizmos (translate, rotate, scale) through my test plugin before I build them in to the editor so that I can get a good idea of how I'll implement other ones. I'd be great for a real-time UV mapper to be able to put a gizmo right in the editor for you. Hopefully that'll be easy to do.

In the included shot, you can see a few new things. I added a "resource browser" to test how easy it is to plug a 3D viewport onto another window. I don't have it hooked up to show what I want but the viewport is there for me to do what I want and it has full camera controls. The materials are listed as well as the currently registered entities at the bottom.

The gizmo currently visible is my attempt at a transform gizmo. I am going to obviously replace that with some arrows and what not later but for the most part, it functions correctly. You can left click it and rotate the object, middle click to translate, and right click to scale (I know.. ass backwards controls). I'm currently just using bounding boxes for hit detection so that'll have to be replaced eventually with polygon selection which I'll most likely use a 3rd party collision detection library for, like Bullet.

Editor Advances

I've been a little busy with my home life lately but I have managed to squeak in some time to work on the editor. So far, I'm very pleased with where it's going. The plugin system is very easy to create thanks to .NET. I'm trying to keep things as exposed in as generic of a way as I can. There are easy to use hooks on object selection as well as populating the scene graph which will allow for game specific plugins to add their own types as the graph is being built. I am designing everything with extensions in mind so that games can plug in various dll's and enhance the editor beyond it's base without having to touch the editors code. Any plugin can be loaded or unloaded without bring the rest of the system down. Don't want a feature? Simply delete the dll and it won't get loaded anymore. There is an options page in the editor to specify which plugins to load on startup.

I'm going to work on some property wrappers around scene nodes as well as introducing an axis widget that will be placed in the editor to allow for things to be dragged around hopefully.

I've also got a nice docking suite going on. Plugins can register a "ToolWindow" with the editor and it will dock it somewhere. The suite provides saving/loading functionality so the positions will be saved across sessions which is very awesome.

Editor and debugging

So I've started work on an editor. I'm using .NET and C++ to get the editor done. I'm using .NET because it seems to have a TON of features for UI development which are all very easy to use and are all garbage collected for me. I'm still going to try to maintain proper memory practices but if I miss something, it won't be as big of a deal as it would be in the game so I can let the GC worry about it. Also, having a designer in Visual Studio will come in damn handy when I'm making some of the manager windows. Right now, I have Ogre rendering into a form as well as a "viewport manager" which has a ton of customizable arrangements. I have every combination possible with a 2x2 grid. You can have one stretched across the top, and two in the bottom row. There are 8 different combinations that are possible and they all work.

I haven't hooked up buttons or anything to it yet so it's just a hard coded enumeration but I'm taking it slow and making sure each feature works and is cleaning done before I move on. The aspect ratio in the viewports isn't re-adjusted if the size changes so ignore the stretching in any shots until I implement this (which will be soon)

One feature that was needed for both in-game and the editor was a bounding box that had a transparent material over top of it so you could actually see the bounds that it enclosed. This isn't as big of a deal for small bounding boxes but the larger they are, the more useless a wire frame view of it becomes, especially when you're scene is littered with hundreds of them. In the editor, you'll be able to turn on/off certain volumes to keep speed reasonable since they are transparent but they'll show up in different colours so you can leave all the ones on that are relative to what you are doing and turn the others off. They look kind of nice actually. The colours are just in a script file so they can be changed (read: should be changed).

David Copperfield Styles

I suck at art. I suck at all things that require artistic ability. With that said, I created a magician unit. It's just a test unit for now but I am going to use him to develop the spell system. The first spell I've worked on is the magic missile spell. It sucks. It needs improvement but the logic of it works.

I think it is about time that I start to abstract the AI state machine into script files. It should be really easy to allow which AI states are supported by each unit type as well as the priority of them. I'll add per-state customizations to the script file eventually so you can change timer rates and other such things. For now, you should be able to create an entire machine in the script file that will support a hierarchy and priorities for states at the same level. All the states will be defined in code but they are easy to create. Hopefully this will allow rapid development of units when we get some art for the different units.

There are some other improvements in the UI like a population bar at the top. The map parser has had some improvements as well in that an entire map can be defined in script except for resource providers. I'll add those soon.

Yes, I know the minimap isn't visible. I am trying something with it right now.

I'm (almost) a real game now Geppetto

So. What's new. Well, lots of stuff. So let me try and give a list of all the things I've done since my last update (this is entirely incomplete but it's the most obviously, visible changes):

• Resource Harvesting -- Units walk back and forth from the "gold mine" to the closest building and you get 25 wood each time
  
  
• Building Placement -- Once you have 250 wood, you can place down a building. It will show up in red over areas that you can't place it and green in places where you can.
  
  
• Path smoothing -- The path finding generated pretty rough paths so they've been smoothed out to straight lines across the grid where possible (red lines are the new path, green lines are the original unsmoothed ones)
  
  
• Selection Area -- The selection area now has a nice translucent rectangle filling it in. I think it looks nice although I'll let Doug tweak the colors and such :)
  
  
• Fighting -- The units fight each other with their swords. They chase down units and instead of firing those awesome black squares that you see in previous shots, they swing their swords at each other. I'm going to add callbacks into the animation system to be fired off at certain times so we can assign damage at the correct time in the animation
  
  
• Minimap -- There's an almost fully functional minimap. I have to add code to handle when the user clicks and drags in there to move the actual camera to that location but other than that, it shows all units in the right team colors as well as showing your current selection in yellow
  
  
• Group Management -- You can bind various groups to hotkeys now. This works in the same way Ctrl-1 and similar do in other RTS games
  
  
• Awesomely clean code and design -- It's so damn easy to drop stuff in the game now. The design has worked out very well.
  
  
• Debugging Features -- We've got a few shapes that we can attach to the various actors in the system. Currently, there is support for cylinders, 2D circles, 3D rectangles, and text labels. The AI states are being printed out into the text label
  
  
• Pluggable AI System -- The AI was implemented using a heirarchical state machine with each state responsible for determining when it can activate. This has been amazing to use since we can drop new states in and not screw up existing states. Currently, I have the following states: Idle, Walk, Combat, Harvest, Construction, Search and Destroy
  
  
• Building Attacking -- You can attack buildings now and when they die, they will "rumble" into the floor. I'll replace this with a collapse animation once we have those from Doug but he's got a lot of work on his own to be doing so that might be a while off.
  
  
• Unit Avoidance -- I have started working on keeping Units from penetrating through each other and it's working out in very simple cases. I've got more work to do on it but they don't penetrate at all right now. I'll probably easy up on this later once I get into handling it better. For the most part, it's a good start.

I think once I get some computer AI in there, it'll almost feel like it's becoming a real game. I am not sure how I'm going to tackle that beast yet but hopefully I can get a very basic AI up within the next 6 months. I've got some friends back at school who are interested in creating some AI so maybe I'll let them have a good at it.

There have been a *ton* of under the hood changes and I support a lot more "features" like Actor Attachments which are very simple peices that can be put on an Actor itself. The shield, sword, and shoulder component of the lizard grunt are all Actor Attachments. It's an easy way to have custom pieces but still attach them to whatever in a very generic way.

There are still no memory leaks and only a few bugs which I know about but just haven't fixed. Other than those bugs, most of which are new, the game is pretty rock solid which I am happy about.

Anyways. I'm going to get back to work. I promise more updates more often but here are some currently pics until then. (I think I'll post a video or two soon as well)

Good Progress

So I know it's been a while since I've updated this blog but I have a lot to say about the game.

First of all, I don't know if I've said this before or not but we have a working title for the game and it is called Valors End. This was thought up by Reds so I get no credit for that. I've also gotten myself a job at a real game development company. I now work for Silicon Knights on a project I am not allowed to talk about. I think this will be a great experience for me and will also put some money back in my pocket.

In terms of the game, I've made some good progress. I have changed a lot of the code so it is all very generic now. The behaviour of the Lizard Grunt is actually about a 100 line source file. It will obviously grow as time goes on but to get a unit that can attack and move around is fairly easy. I have some work to do on the pathing to take into account the size of the object and that sort of thing. A lot of the work that I've been doing is behind the scenes code refactoring. I've abstracted out a TON of the code so there is a lot of reuse going on now and a very easy to work with hierarchy.

In terms of functional features, I've added a lot. And I mean a lot. The first thing that I added that is the most obvious would be a GUI. It's just a placeholder until Reds comes up with something better (after I explain how the GUI stuff works to him which I still haven't done..). On the bottom left side of it is a nice little minimap which has the terrain on it as well as the fog of war. Units show up in here as their respective team colours if they are visible. Hidden units don't show up here. So far it works perfectly which is great. I haven't added the ability to scroll around on it yet or a rectangular outline showing you what you can see in the main window but I'll get there.

The middle part of the UI shows portraits (again just place holders) of the units that you currently have selected. It'll display up to 12 icons but since the code was well done, it will be easy to change that to support stacks or whatever other organization we come up with.

The right side shows the "action sheet" of whatever you have selected. So if you have a Lizard Grunt selected, he'll have the Attack, Move, and Stop commands available to him (that's all I have right now but there will be more). These are basically the orders that you can issue to a Unit or a Building which could also be mapped to a hotkey.

And yes, I did say Buildings. I have a hatchery up and running which is still a work in progress as far as the texturing is concerned. You can select a building and it's action sheet will be displayed and you can queue up a lizard grunt which will get produced every 2 seconds. I don't have a progress bar yet for this but it's on my task list, along with 50 other things. Because of the way I've developed the code, it's really easy to actually "rig" up a new building type and get it's action sheet up and running. Hotkeys are also going to be really easy to map to specific functions as well. This should hopefully mean that in order to create a new building, once the modelling is done, it'll take me an hour or two to get it fully working and integrated into the game.

The Units themselves now have a proper range as well as some more advanced animation selection. The lizards run towards each other in their "chasing" animation and then once they are close enough, they play their attacking animations. I still have to abstract out how this is done as it's just a big switch statement right now based on the movement status of the unit. Once that's done, it'll simply be a matter of specifying which animation gets played when the attack sequence begins.

The code has been optimized a wee bit as well and now runs faster which is always great news. I have a lot of places where I know that I can easily optimize things fairly easily so I might work on some of that in my spare time.

The current thing I've been playing around with has been steering behaviours to keep the units from penetrating each other. At the very minimum side of the scale, I would like units to stop and let others move around them without contact. More advanced functionality would be for units to side step eachother if possible while continuing their motion. I think this would add a lot of visual appeal to the game. This is a long long term goal so it'll be something I'll be continuously tinkering with but will mostly leave disabled until it's at a reasonable state.

I reworked the Unit and Building classes and came up with a generic Actor class which as a lot of the properties that are common to things that will be in the levels. I am going to most likely abstract the combat related elements either into a CombatActor class or as a CombatProperties (or similar) class which will be contained by Actors. I think this is most likely the easiest solution since I can still query every Actor to determine if it has a CombatProperties class and then perform combat related stuff on that. This will allow me to work at a high level but I will only pay 4 bytes per Actor that doesn't have the CombatProperties (just a NULL pointer). This is ideal instead of building it all into the Actor class which would result in one hell of a bloated class.

I've reduced ALL of the memory leaks in the program (there were only a few.. I mean like 200 bytes or so) but I've tracked those down and am now leak free which is always nice.

In terms of how clean my code is and how easy it is to integrate new stuff with, I'd have to say that I am in an ideal solution. It's all *very* clean and easy to read, as Reds commented on when he saw it, as well as fairly consistently commented. One of my on going goals right now is to get all the functions and classes commented properly. I'd say I'm about 80% of the way there which is great. I am using a tool called Doxygen which automatically generates a set of API documentation pages in any format I want. They come in handy.

I also got a new laptop from Dell which is a powerhouse little machine. It's an Intel Core 2 Duo at 1.9Ghz each. It's got 1 gig of RAM with an nVidia GeForce 7400 Go with 256 dedicated RAM. I have a 100 Gb hard drive spinning at 7,200 RPM (regular desktop speed... normal laptop drives spin at either 4,200 or 5,400 RPM which is a lot slower). I have a built in DVD re-writer which does ALL available DVDs. Built in wireless, lan, video out, s-video out, 4 USB ports, dual headphone jacks, etc. I also have a built-in webcam which is probably one of the best webcams I've ever seen. The awesome thing about it all is that it's all in a tiny form factor. It's a 12" screen which means I can take it with me everywhere. I can open it up and push it all the way back when I'm on the bus which is amazing since I travel every weekend for about 8 hours. That's a lot of time to be coding.

I'm going to wrap up this mega-post right now. I'll post some more in a few days, after I talk with Reds. We are both in communication through MSN now which will allow us to talk on a regular basis. We were using IRC before and I had a habit of not opening it up. With MSN, we can chat at our leisure which is awesome.

I'm outta here to work on more code (there are more changes I want to write about in the next post).

Shawn

Major Updates

I haven't had a chance to post in a while while exams were on. They are over now and I have had a lot more time to work on the game. Reds [Doug as I now know him] has a great model that we have finally put in. He's worked on the Idle and the Run animations which look amazing in motion. He still has to do the Death and Attack animations but he's got a lot of time to do that. He's also going to attempt to create a random terrain generator which will be amazing if he can come up with anything that's usable.

I have been hard at work on the code and have a bunch of major features done. The first major feature was that I working on was fixing up group movement. It's in a usable state right now. I have had it crash one time in the few hundred times I've used it since then so that'll be a bugger to track down but I'll get there. Units now move in rows of 5 for now. I just wanted to keep them seperated so they didn't stack and this solution works. I'll update it later to add support for dynamic row sizes so that the formation tries to maintain an even balance between width and depth.

The second MAJOR feature that I implemented was fog of war. This isn't entirely done yet but I'm about 80-90% of the way done. The only thing I have left to do is create a static image of the buildings of enemies in areas that you have previously explored but that you currently can't see. This is typical in RTS games and shouldn't be too hard to implement. Whenever I determine that a currently visible building is no longer visible (which I have), is to add a "clone" to a list of "was visible" buildings and keep those visible. Whenever a building on this list becomes visible, we search the enemy building list and see if it's still there. If it isn't, we destroy our clone and don't show any building. If it is there, we leave our clone for later use, and then just show the live building. The FoW (fog of war) is very nice to see in motion since it fades out nicely to the half black color very smoothly. Enemy units are hidden if you can't see them.

The last MAJOR feature that I got working was team colors as well as accessories for units. Reds create a shield, a sword, and a shoulder pad for the lizardman unit and gave me a code snippet to attach them to the unit. We have colors all over the unit so it's easy to tell which team a unit belongs to.

Another feature that I have working is basic combat. The units just shoot little squares at each other when they are in range but they will fall over and die when they run out of hit points. I don't have anything else to use so it's white boxes. It's fun to watch them fight each other.

I also added a directional light and turned down the global light so it adds a nice soft touch to the scene. I turned on shadows as well so they are cast onto the terrain which looks really good.

I'm going to be working on adding some chasing so that units will run towards eachother and fight when they can see each other as well as a few clean up things. Reds is going to be working on more animations as well as some map media (trees, rocks, etc) so that will really spice up the visuals of the game a lot. I can't wait to see the units swinging their swords at each other.

Death of Units
Screenshot: 1280x768x32 - No AA - Default ATI Settings

Fog of War
Screenshot: 1280x768x32 - No AA - Default ATI Settings

Unit Shadows
Screenshot: 1280x768x32 - No AA - Default ATI Settings

Lizardman Model
Screenshot: 1280x768x32 - No AA - Default ATI Settings

Team Colors and Accessories
Screenshot: 1280x768x32 - No AA - Default ATI Settings

With a bit more time lately, I've accomplished some more features in the game. I have some what decent group movement. I only support the Line formation which currently is a static width of 5 but I will replace this with a 'Formation' class that will support dynamic formations. The ability is there, I just haven't had time to actually finish it. As it stands now, this drastically reduced the overlap of units. Two units in seperate groups however can still stand on top of each other and for right now, this is a fine feature that I don't mind since once they move again, they won't overlap, even if they end up in the same group.

The other feature, which is sort of shown in the screenshot, is units finding targets. Each unit now searchs for a unit that is within his sight radius and then engages the enemy. Currently, units fire white cubes at each other and have no hitpoints but the target acquiring is there. You still fire when you are moving but this is easily fixable with an enumerated state which is checked. If you move away from the unit, you will stop firing if they go out of your 'sight radius'. This looks really neat in motion as it is one of those 'visible' features of the game that make it more of a game. I am going to leave off changing the cube until we get a real unit in there from Reds. He's hard at work on the lizard man model which has come a very long way. I have seen a few screenshots lately and they are impressive. It'll be a huge day when we can finally switch over from the robot to one of those. He's on vacation now, being a bum, so I don't think there will be any progress towards that goal for a while.

I'm going to tidy this up a bit and then get back to work on the formation code. I want to have a few different formations ready to go which will be selectable through the GUI whenever I get to that stage. Either way, this is a big step towards the end goal and I am very excited about it.

Screenshot: 1280x768x32 - No AA - Default ATI Settings

Milestone 11: Reached

I haven't posted in a while since University life keeps me really busy. However, a lot has happened since the last post. The first and most important thing would be a new team member, bringing the grand total to two. Reds, as is his online nickname, has joined as an artist/would-be coder. I don't know where his coding skills are but I do know his art skills and I am more than thoroughly impressed. I was originally intending this to be a solo project since I didn't think it would interest anyone else but apparently it did. The art content was a major concern as I was basing the game on free content that I could find online which would not provide a consistent look and feel to the game. Reds has been hard at work on our first unit model which is a lizardman.

Which leads to the second development of the game and that is theme. I had no original theme for it, just two opposing sides, but Reds has come up with Lizards vs Beasts. He thinks he can pull the art off for it and from what I've seen, it'll be amazing so we've decided on that. I am really happy with that decision. He's animating the model right now and it's looking really good. He has seperated the weapon and shield as well as a shoulder pad so that we can use replacable items when you upgrade a unit (a long away feature) which is amazing. In total, I am thoroughly excited to have someone as talented as him join my little hobby project. I think this could be really something interesting.

Now for the milestone itself: Navigation. That's right. I have path finding around the map working. You can select a unit, right click somewhere, and he'll find his way there. Buildings mark themselves on the map as in-passable so any unit can weave in and out of buildings to find his way to the destination. As it stands now, units just walk through each other on their way to the destination which turns out not to be as bad as I thought it would originally be. I may leave this as is.

I'm using the A* algorithm which has many references online, beginning with a GamaSutra article. From google, many more resources can be found. The approach I took was to divide the map up into tiny little tiles, each about 1/4 the size of a unit. This will also allow me to use a mipmapping approach, when the time comes, to the pathfinding so that each "patch" in the terrain will have it's own higher resolution of tiles and I can use the patches as a low resolution test to begin with. This should give a huge speed increase when it's implemented, if we need it.

Each of the buildings automatically marks the tiles on the terrain that it covers so I can have buildings that can more (not sure what right now but the feature is there..) and they are padded a bit to prevent units getting too close. Over all, it works really well. I've eliminated any bugs that I know of but I'm sure Reds will be able to find at least more which is excellent. I have a lot of ideas about optimization for it but currently, its still fast and works great. We'll see how this goes when we have 100 units in the game.

Milestone 12 also has had some progress done towards it (which is actually shown in the screenshot). The milestone was to have formation movement. This turns out to be a lot harder than I initial expected but I've got a very solid base right now to build on. I have a few more features to put in, like various formations, and I think it will mostly be ready for prime time. Currently, I am just using a hard coded formation of the "line" formation with a width of 5 units. The actual formation class will allow the width to vary so that it doesn't create a small width with a huge number of rows but it also doesn't create a large width with only 1 or 2 rows. Somewhere in the middle is the desired option.

In the screenshot, I selected the units and told them to move towards the white box (it's a debug item to show where you click). The units were originally all spaced apart in an uneven manner but they moved into their intended formation when you right click. This keeps units off of one another to a large degree. Obviously, other groups can overlap any other group but this may prove not to be a problem for the most part, depending on how we decide to do unit creation (single units or predefined groups of units which stay in groups). Either way, this was a major feature and it's almost done so I'm happy considering how I haven't had any time what so ever to put into this. This has been through the work of many "I have 20 minutes before class" sessions but it's finally coming together.

Major eatures left in group movement are:
Various formations
Movement to the closest possible destination if desired isn't walkable
Orientation of a formation

Screenshot: 1280x768x32 - No AA - Default ATI Settings

Milestone 10: Reached

So I know it's a bit out of order but I just wanted to be able to select a group of units. It currently tests every unit on the map which can obviously be optimized but it doesn't seem to be draining much right now. It's a simple min/max test on each object so there's nothing complicated. It only happens when the user is dragging a selection region.

I am going to actually base it on which side of the 2D plane the unit is on since the rectangle you see on screen maps to a warped quad in 3D and some units are being selected that the user wouldn't expect. That's also a very simple change to make which is just testing the distance of the x of the unit in comparison to the plane definining the two sides of the selection rectangle. This will give the exact results that I want and is a very easy feature to implement which I will do sometime.

As you can see, each unit that is selected has it's bounding box turned on. I also add it to a list of currently selected objects which I can use later if need be. It'll be used in things like navigation for when the user right clicks to move a group somewhere, etc. I think I may start work on getting a unit to navigate around the terrain which will be a very important feature.

Progress has slowed a lot due to midterms but once they are over, I plan on getting 100% back into development. It's been steady progress when I've had time. I'm still on track with my goals as well so that's always a morale booster.

Screenshot: 1280x768x32 - No AA - Default ATI Settings