Tuesday, September 19, 2006

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).


Thursday, April 27, 2006

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

Thursday, March 16, 2006

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

Saturday, March 11, 2006

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

Thursday, February 16, 2006

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

Thursday, February 02, 2006

Scene Query

So I now have my units performing a scene query to determine where they should stand on the terrain. It works pretty well so far. I haven't bounded the edges of the map yet so the units could fall off (I haven't let them run that far yet) once they hit the edges but this is a simple bounds check that I can place in later. Also, the path finding should prevent units from moving off the edges of the map once it's in place.

I am not sure which method is going to be faster of keeping the units at the right terrain height. I am currently using the SceneQuery but I may just need to grab the terrain information, cache it, and then use interpolation along the triangles u and v directions which may end up being faster. If it becomes a problem, or if I have time, this will get implemented. As for now, it works so that's what I'm working with for now.

Screenshot: 1280x768x32 - No AA - Default ATI Settings

Tuesday, January 31, 2006

Milestone 2: Reached

So I am well ahead of schedule. I didn't plan on starting this project until February 1st but I had a few days so I got started early. I've been making modest progress as I've already reached Feb 11th's milestone. I'm about 2 weeks ahead of schedule which is great news. I know that I put some of the easier milestones early so that I could feel like things were moving forward but this is still a good sign. I've noticed that if I have a determined goal, I work a lot better. I'm not sitting here wondering what I should be doing or how I should be going about it. I just sit down and think about what needs to be done.

Some of my later goals are very tight such as the path finding but I'm hoping that with me getting all these little goals out of the way, I'll have more time for those. I've also got 2 weeks at the end of my schedule for bug finding as well as finishing any missed features/putting in extra features. I think this may go well. It won't be the cleanest, best designed system out there but it'll get done.

This milestone was to get a mouse on screen as well as have it move the camera around on a plane above the playing field. It's exactly like other RTS games where the edges move the camera. I have the ability to pitch the camera while still having it move on the plane above the playing field. This can be used to test out various angles until it feels right. It is currently disabled because it was hooked to the mouse and that was obviously not going to work with mouse scrolling.

The screenshot shows the new location that has been reached with only using the mouse. It's not the greatest of screenshot features but it's a very important feature that I needed. As you can see in both pictures, I already have a robot mesh loaded which I may end up using if I can't get any other mesh inside of OGRE. This was milestone 3 which is currently done in terms of loading a mesh. I will continue to try and convert other game formats to .mesh but that can be done at any time. I am going to work on a TeamUnits class which will manage all the units for a team. It will start off by being able to create and remove units from a team. That's pretty much it for milestone 3 so expect an update on that soon.

Screenshot: 1280x1024x32 - No AA - Default ATI settings

Saturday, January 28, 2006

Milestone 1: Reached

After waking up and getting myself stocked up on groceries, I sat down and read some OGRE tutorials. I wanted to approach this project with the right mind set and that was to know exactly what I'm doing before I try anything. I read through about 4 beginner tutorials which was a refresher since I've used OGRE before.

After reading those, I explored my options with a terrain configuration file and thought about how I would create the terrain. I used a heightmap with a base texture as well as a detail texture. These are not mine. I will replace them with more appropriate textures when I get a chance to do the artwork for this project. But, I do have a custom material that has 3 layers on it (base, detail, grid) which you can see in the picture. That wasn't terribly painful what so ever. I haven't figured out how to get access to the geometric data which I will require for path planning but I will look into this. Worst case scenario is I manually load the heightmap myself and create auxilary storage.

I also wanted to know what my card is capable of in terms of pure polygons and, as you can see from the shot, there are 200 models plus the detailed terrain. The LOD on the terrain is high because it's using large tiles so they won't go down in detail for a while. It is very easy to load up meshes through OGRE which is a nice feature. I have to look into converting a Quake 2 model into OGREs native '.mesh' format which may or may not require me writing it. If it does, I will release it to the public if it's actually usuable.

This was the first thing I wanted to get done. I wanted to be able to load terrain and move around and because OGRE is very user friendly, this took me about 30 minutes of reading and coding. Off to a good start.

Screenshot Details: 1280*1024 - 32bit - Default ATI driver settings (fairly high texture quality)

A Simple RTS

I am starting development on a demo that I will attach to my resume for job applications. I have been thinking about what to create for a while and have finalized my decision on an RTS game. It will not be the next Age of Empires by any stretch but it will be a good demonstration of my capabilites.

I want to take the right approach for this so I have been writing out a design before I start programming. I have described the game play in detail as well as layed out a list of milestones that I will need to reach. There is one milestone for every feature I need to implement. This way, I know upfront where I am in development. I think I have gotten everything I need on this list.

This is going to be a very tightly schedule program as I am allocating 5 months to do it. Not only is 5 months a small amount of time for a sole developer, I am also enrolled in my 3rd year in an Honours Computer Science degree at the University of Waterloo. This means that on top of class, I also have assignments which are long. I also have midterms and finals to study for which are hard. This is going to be a true test of what I can accomplish with a very limited amount of time.

This blog will be my development diary.