Monday, October 9th
This weekend, I got a crude main menu put into the game. I really just wanted to make sure I could transistion from a menu to a game map and not have anything break horribly, and such is the case. I had to do a little tinkering to get the gui elements displaying properly (have to make sure the client is locked at 1024x768, I can either make that the requirement or look into ways of making the gui resizable). Most of the major features are now in game, a month to the day that I started the project. I'm both suprised and pleased to have made it this far along without burning out. There have definately been times where I feel like I might be wasting time making a game that few will play or enjoy, but the real goal is to complete a game, and if I can do just that i'll have achieved something great for myself.
There aren't many features or subsystems left to implement that don't directly involve content. One of them is a gameController class. Where the waveController handles the spawning and scoring of individual waves, the gameController will handle the creation of waves over the course of a game. The startGame function will be modified to take additional parameters containing the type of game and it's selected options, and these parameters will be passed to the gameController object to be enacted. Depending on the type of game selected, the gameController will begin playing out a hardcoded script of waves, and will detect when the player has lost all of their lives, and also when they have beaten the game.
Friday, October 6th
Soon enough, i'll have to start designing the content to end up in the game. First on that list is the towers. I started thinking about how to balance them, and how to measure their effectiveness, and came up with the following formula:
Damage potential = Damage * ( (Range * 2) / Rate of fire )
Friday, October 6th
Death animations are in! Phew. Easy enough task, just never seemed to have put the time into it. While getting them in, I figuerd out how I can streamline the animation selection process, so now my code will be a lot less messy. Originally, I was facing the ugly possibility of a switch block for selecting direction animations, based on the config of the mob. Now, I can construct the appropriate animation names using the config field of the mob plus the animation name. IE: %mob.config @ "Death" would become, say, zombieDeath, which would be the zombie death animation. Another example would be %mob.config @ "NorthEast"; zombieNorthEast, for the zombies north east walking animation. The only drag of getting death animations in is the manual labor part of it. I cant really use the html file method for constructing the sprite sheet because my desktop resolution isnt high enough to show it all on one screen. My monitor died a few months ago, and i've been using my older monitor, which can only do 1280x1024. What a drag. Currently, im having to load the animation sheet into photoshop, resize the canvas, reposition the existing sprites, then copy and paste each frame of the death animation into the sheet with a 96x96 grid as my guide. It's not terrible, but it's definately a pain in the arse. I really just have to figure out a way to display html full screen with no titlebars or toolbars along the top of the screen and i'll be in business. I'll have to investigate that when I have more time.
Thursday, October 5th
The goal methods of the waveController class have been mostly implemented. There is a setGoal function, a checkGoal function, and there is now an endWave function. Currently, I have a recurring schedule call in place to check every second wether the goal has been reached, but it occured to me on the drive to work this morning that I can get rid of the schedule call and instead run the checkGoal each time countDeath, another method I implemented to count up the deaths occured during the wave, is run. In addition, I dolled up the map quite a bit, adding animated trees and bushes, dirt patches underneath trees and rocks, and some additional fencing. Some of the more prominent objects, like the trees and fences, are even placed in the sorted layer, so that towers will appear in front of or behind them when built. Having the assets provided by the Adventure Kit is proving invaluable, as I have lots of lovely looking pre-made terrain that suits my theme and purpose very well. Also, I started investigating the loading options which my sprite sheets are using. My enabling 'Allow Unload', I can unload the largish (768x768) sprite sheets that are being used when moving from one wave to the next. Also, I can disable Preloading, so that the sprite sheets are not loaded until they are actually used. With these options combined, I should see that memory usage is dropped dramatically, as none of the character sprites are loaded until needed, and they are not kept loaded when unneeded.
Next on the agenda will have to be death animations. I've been debating wether to include the death animations for all 8 directions, or just one death animation from a southward direction. I could even get funky and use sequential frames from all 8 directions to do a wacky spinning death. The upside to doing animations for all 8 directions is that it might look a bit nicer, and will emulate 3d better. The downside would be that *another* 768x768 sprite sheet would need to be loaded to memory. By making a single death animation, the additional frames can be appended to the original sprite sheet, and will have all the same advatages afforded, like no preloading and allowed unloading.
Wednesday, October 4th
Tonight was productive. I got the waveController object just about fully implemented. The only thing left is to add functions for determining when a wave has been completed. In addition, I tackled many smaller features along the way. The waveController class now creates an alert box to tell the player when a wave begins and ends, and there are barriers in the roads which keep players from building there. Tommorow, i'll plan on getting the goal setting implemented in the waveController class, as well as the appropriate functions for detecting completed goals. I *still* need to get death animations put in, also. I keep pushing that back in lieu of more exciting features. Still to be done is transitioning between waves, a main menu (and subsequent level loading), and investigation of adding particle effects (wheee!).
Tuesday, October 3rd
The hover-over health display is now fully implemented. There were, of course, some minor fibbs and quibbles I had to work out in the process (mostly simple logic errors), but everything pretty much went as planned, and I had everything in working order in just under an hour. The great thing about this newest solution to the hover-selection problem is that it uses no schedule calls or expensive functions to get the job done. pretty much everything is handled by the stock t2dTrigger object, which takes care of all the "am I over the object, am I out of the object " questions. I'm going to leave death animations as an undertaking for tommorow and spend some time tonight researching. When your research consists of playing video games, you must be doing something right. :)
I think i'm going to begin recording my times in this journal along with my entries (where work has been done) so I can analyze time spent versus progress made; also to determien total time spent on the project.
Tuesday, October 3rd
I got the hover selection routines partially implemented this morning using onMouseMove callbacks on the mob objects themselves. This works well enough, though there appears to be no easy way of determining when the mouse has moved out of the object short of testing the mouse's position constantly after a hoverSelection is made. This, of course, can have quite negative performance implications. I was thinking about this problem while driving to work (my typical time to be pondering such things) and came up with a clever alternative which will not only allow me to detect when the mouse has entered and left a mob's perimeter, but which will also drastically reduce the performance hit. My solution is to create a trigger object upon loading of a level, size it to be very small, perhaps 1 by 1, and either mount it to the mouse cursor or have the trigger position itself to the position of the mouse using a sceneWindow onMouseMove callback. Trigger objects have onEnter and onLeave callbacks, and will allow me to test objects to see if they are mobs and act accordingly as they come in contact with the trigger.Just one more example of why it pays to leverage all avalilable tools at hand. My plan is to get this implemented tonight, and then hopefully move on to complete death animations as well. That way, work can begin on implemented wave logic and its appropriate controller functions.
Monday, October 2nd
Tonight I got the health bar displays implemented. When a unit is clicked, it pops up a display overhead displaying its current health percentage as a bar. The final step to completion of this feature is adding the ability to hover over a unit and have its health display. The dirty way of doing this would be to run a pickPoint in either the onMouseMove callback of the scenegraph or the scene update callback of the scenegraph and check if any mobs are underneath the cursor. This method could pose a powerful performance hit. Another possible option would be to use setEnableMouseEvents on the mobs and code up an onMouseMove callback for the mob class which in theory should trigger only when the mouse moves over the object. The object when then trigger its health display, and set a global toggle, something to the effect of hoverSelection. If the mouse hovers over an additional object, the obejct will first check to see if theres already a hoverSelection, and if there is, to disable it's health display. I will try and get this implemented tommorow morning, and if not, than tommorow night. I'd like to also get death animations implemented tommorow (as it should be a quickie), but we'll see how things go.
Monday, October 2nd
I spent some time yesterday and this morning working on mob health displays. The idea is to display a colored bar over the head of mobs which are either selected or being hovered over which depicts their current health. At first, I was implementing these as StaticSprites which would decrease in size and change in color as the mobs health went down. The problem is that making a static sprite shorter in length would not position the sprite as you would expect a progress type bar would. This could be corrected, but it would be somewhat messy, and probably not an ideal solution. What I started to do this morning was to fall back upon a previous lesson learned and leverage the tools that are already available to me. What I am doing now is creating a gui control on the fly which contains a simple GuiBitmap representing the mobs health. The gui control is created dynamically and mounted to the mob itself, just above its head. I didn't have enough time to get this fully implemented, but the bar is being created and mounted, and is displaying properly. All thats left to do is setup the appearance profile for the control, make the bar actually represnt the mobs health out of its max health, and write a method of the mob class which updates the bar. After that, I should have my mob health display fully implemented. Whats next after that?
- Wave logic
- Death animations
- Clean up/finish camera code
- Investigate/Test level changing
Of these items, death animations is likely to be the next feature implemented. It will be simple enough to add, and will add a lot to the presentation. After that will be wave logic, followed by the camera code and then level changing. Eventually, i'll have to implement a main menu, but this will likely rely on level changing code to ensure that the program can switch modes.
Sunday, October 1st
I added in a new mob type, a zombie. Rather appropriate seeing as how we're getting closer to Halloween. I really wanted to see how quickly an entirely new mob could be added into the game, and it only took me about 20 minutes. Most of the time spent was doing things like getting the html file in order (to lay out all of my animation frames into a single image), writing up the animation datablocks, and adding the appropriate checks into the directional animation choosing code. All in all it was rather painless. The next step will be displaying health bars over the heads of both selected and hovered mobs.
Saturday, September 30th
Today saw the implementation of the unit info box and the ability to select buildings and mobs. When a player clicks on a mob or building, a picture of the unit appears in the info box along with statistics, which includes name and life for mobs, and name, range and damage for buildings. Addition stats will be displayed as they are implemented. When a player clicks the ground, the current unit is deselected. If a mob is damaged, and is also the currently selected unit, the info box will change to reflect the mobs new amount of life. When a unit is selected, a fading/pulsating yellow selection circle is placed over it. Also, I upgraded the project to the newly released Torque game Builder 1.1.2. This new release is mostly bugfixes. There should be no specific effect on this particular game, other than perhaps increased stability in the base code. Today was very productive, and getting unit selection and the info display was a large step forward towards a prototype. There are a few things to work on next, in no particular order:
- Death animations
- Proper build menu (Self propagates based on current menu selected)
- Wave logic; split the gameplay into waves
- Game over conditions and displays
After adding these things, perhaps along with a few additional enemy and building types, I should soon have a fully working prototype. It feels good to have gotten as far as I have, and i'm still looking forward to road ahead.
Wednesday, September 28th
Tonight was very productive. I got mob animations in and working. I discovered that I wasn't able to implement it as cleanly as I would've wanted (apparantly you cant refference an animation datablock from within the config of a sceneObject datablock, though I bet I could assign the animations at creation time based on the config used.. hmm), but it's in and its working. And it appears to be bug-free, to boot (knock on wood). It's pretty nice to see the mobs as animated, colorful creatures instead of the single rock image I was using before. Watching them snake around the maze is pretty cool; I was worried about the mobs looking 'stiff' with only 8 directional animations (at 9 frames each), but it actually looks pretty decent. I have a feeling that, in the thick of the action, the player will be relatively unconcerned with the presentation and more concerned with keeping their heads above water; ideally, of course. Anyways, the next thing will likely be to implement death animations. Weeee!
Wednesday, September 28th
This morning, I noticed a strange behavior with the buildings. When switching targets, they seem to be giving prefference to mobs which have just entered or are actively entering their trigger box as opposed to the closest. I fixed this by having the projectiles created by a tower store a refference to their owning tower, and then using this refference to call changeTarget when their target has been killed. This eliminates the scenario of having an empty target in between shots and then targeting the next trigger entry. I think I have the targeting just about nailed down, as im starting to see the trickle patterns in the mob stream that i'm used to seeing in the tower defense maps that serve as my inspiration. This, of course, results from the consistant, predictable targeting and slaying of enemies based on positioning of and exposure to the towers. With most of the major bugs fixed up, I feel like i'm making pretty solid progress, and i'm ready to start implementing the next big feature (and with it, im sure, the next batch of bugs to solve ;P).
Tuesday, September 27th
I've fixed the bug with buildings failing to target mobs. It had to do firstly with an incorrectly refferenced distance check (was refferencing the wrong variable.. doh!), and secondly with mishandling of the scheduling of building attacks. Originally, I had the changeTarget function cancelling a pending fire event and then firing once again, which had the effect of giving the building a free shot. Fixing the aforementioned bug also remedied this potential imbalance.
I started to work on the dirty work of cleaning up images for the animations and realized that it would save me a lot of time if I had a way of strining all of my frames together into a single sprite sheet. Of course there are programs to do this, but the ones I was finding were all shareware and requried registration. I ended up simply typing up an html file which displayed all the images in a borderless table, and then simply print screened and pasted into photoshop. This was yet another instance where I was able to save myself *tons* of time by leveraging all the tools at my disposal.
Tuesday, September 26th
I've noticed a bug where a building placed within the vicinity of two other buildings will either not fire projectiles or stop firing projectiles after a short time. It most likely has to do with some sort of scenario which pushes the building into a state where fire() is no longer called. An easy fix would be to call a schedule periodically to check the last time the building fired and 'restart' the target aquisition process, but i'm trying to use as few schedules as possible. I think, in order to track down the bug, I will have to log the entire firing/targeting process for a particular building (most likely, the last building placed) and study the thought process. It could very well be a bum 'target' entry that never switches and also never gets fired at.
After I get the bug sorted out, it's on to more entertaining things. I can either begin persuing the automatic animation of enemies, or begin implementing the script/data interpreter i've been thinking about. Essentially, i'd like to hardcode as little as possible into the engine, instead relying on external data files for my building & enemy stats and information. This will allow users to modify the code if they so wish, and it will also allow me to make balance adjustments without recompiling the code. I'm invisioning the building and mob scripts looking something like XML, with tags defining and dividing the blocks of data. The data is read at the begining of the level or game and is loaded into the engine for use.
As a side note, I left the game up and running all night the other day, to see if I had any leaks or sources of slow down. After about 63,000 enemy spawns and subsequent kills, there was no slowdown or memory inflation. So far, so good.
Saturday, September 23rd
Today, i've gotten part of the camera code implemented. The player can now control the camera with W S A D (up, down, left, right). I will suplement this with screen-edge controls in the future. I did this in a pretty standard way, creating a SceneObject to which is mounted the SceneWindow. The camera will not move outside the tilemap/background, but currently the object will, so I will need to add some limiting code to keep it from moving too far off the edge. I also fixed a bug with the tower targeting where a building would target the trigger objects belonging to other buildings. I spent a half hour or so putting together a new test map and changing the path nodes accordingly, it looks a little nicer now. The next step will be to add the aforementioned camera object limiting (before I get too caught up with the fun stuff :P), and then to proceed with adding damage delivery to the projectiles. I should really start investigating and implementing the switch to superclasses before I get too deep in, but it can wait until after damage is implemented, I suppose.
Thursday, September 21st
I've owned Torque 2D/Torque Game Builder since the alpha was released, and yet as I look over the past two weeks, I feel like i've learned more about it in this short time span than I did in the course of over a year. I can compare to staring at one of those 'magic eye' puzzles; you stare and you stare, you cross your eyes a bit, and maybe back away and look at the big picture, and suddenly you start to see things a lot more clearly. A large part of my becoming more proficient has been due to becoming more acclimated with everything that TGB has to offer. Leveraging as many of the built-in subsystems and procedures as possible has not only saved me a lot of time, but I can be pretty sure that the code im utilizing is both fast and fully functional. There have been several problems that i've solved by being clever with what TGB already has to offer. In addition to leveraging the abilities of the engine, i've benefited greatly from changing the way I approach programming. I've said it before and i'll say it again; You code a program like you eat a sandwich, one bite at a time. By breaking down my project into smaller tasks, and then each task into several steps, i've managed to keep progress moving along and also keep myself from getting burned out (so far.. knock on wood). When your goals are smaller in scope, you find yourself reaching them more consistantly, and reaching any goal, big or small, is very satisfying. Hopefully tonight (so long as the significant other grants me the computer time :P) i'll get the targeting functions written in, and perhaps start on the mob health display. Step by step, climbing ever closer towards my prototype.
Thursday, September 21st
This morning, I implemented the projectile class, and I cleaned up some of the collision properties of the mobs and the building triggers. With projectiles working, the next step is to implement a proper targeting mechanism into the building class. The ground work for this is already laid out. Once a mob hits the trigger, if there is not already a target selected, the building selects this mob as the target and fires a shot. Before a shot is made by any building, the distance to the target is checked, and if the target exceeds our range, we call our changeTarget function. After firing, a schedule is placed on the building equal to the rate of fire. The schedule calls the firing function. When changeTarget is called, it performs a pickRadius using the range of the building and checks the distance of all mobs found in its radius. The mob with the shortest distance becomes the new target. If no valid targets are found, the building shoots and nothing, and sits idle.
Wednesday, September 20th
Tonight's progress was mostly behind the scenes work. The building creation routines have been streamlined, and a Buildings simset has been added. Buildings can now pick out a list of targets within their range, and triggers are created with buildings which fire off when an enemy enters, so the targeting should be easy to knock out. More in the morning..
Tuesday, September 19th
Much progress has been made tonight, as i've implemented both the building selection object and building placement. Work needs to be done in cleaning up the handling of the objects, however, and streamlining of the building creation routines would be desirable before further construction on them is continued, though it is very nice to see things coming together. Next up will likely be the targetting routines for the building objects.
Tuesday, September 19th
After many days of fiddling around, i've made some progress with the project. I had been grappling with TGB's built-in GUI system, at one point considering just writing my own GUI functions. I stuck to it, read through a few tutorials, did some tinkering, and I think I finally have things working smoothly. Im glad I didn't decide to write my own, because it would have added lots of undue grunt work that likely would have burned me out on the game completely. I've implemented both a 'global stats' panel (which displays the players current gold count and score) and a build menu with 6 buttons. While niether is hooked into any tangible values or functions yet, it feels good to get some semblance of a gui on screen and working. And it doesn't look half bad, if I do say so myself (though everything will be much nicer once I get to the polishing phase, of course).
The next thing to work on will be tower placement. This is one of a few pivotal steps that will ultimately lead to a functioning prototype. I have it worked out like this; Once the player selects a building type from the build menu, a buildSelection object is created. This objects job is to follow the mouse around, periodically (every 1/4 second or so) checking to see if its colliding with anything below it (towers, unbuildable terrain, etc). If the path is clear, the object is tinted green. If a collision is detected, the object is tinted red. If the player clicks the button with a buildSelection object present, a final check is made to see if the coast is clear, and then a building object is placed and the buildSelection object is deleted.
Saturday, September 9th
Mobs are now correctly traversing paths according to the path id inhereted from their parent spawners (that sounds slightly odd). As per last nights plan, the target path id is store on the spawner from within the level builder as a dynamic field, and this path id is passed onto the mob when spawned. While implementing this feature, it occured to me that the way in which enemy types are assigned to a spawn point will be inadequate for the goals of the project. Currently, a single enemy type is assigned to a spawn point, and the spawn point will continuously spawn enemies of that type in accordance to its spawn rate. The goal is to have each spawn point produce a variety of mobs, which increase in difficulty and variety as the levels increment. At this point, my idea is to store the spawn types and rates in a text file which is loaded and parsed as called for by the spawn points themselves.
Friday, September 8th (barely)
Tonight I got the mobSpawn (actually, now its just called spawner) class implemented. It felt nice to get it working, as a few errors had me banging my head on the keyboard this morning and subsequently slowed up what should have been some simple development. I'm finding that the roadblocks i've been hitting (speedbumps, really) are largely related to my being out of practice with TorqueScript. I'm having to relearn all the gotcha's and am slowly getting back into the swing of things. I had planned to move on to the building/tower construction code after getting the spawners added in, but now i'm thinking I should go ahead and add the ability for spawners to specify seperate paths to use now, before building up the rest of the prototype. It's much easier to change part of a house if you haven't built on top of it, after all.
1. Add a path_id field to pathPoints (really more of a practice to keep up with in the level builder)
2. Add a targetPath field to spawners, which will refference the path_id of the path which a spawner is to use
3. Modify populatePath to store the order count to an array contained within the path object, the array will be inline with the pointList and pointID arrays so that the same index can be used to pull all relevant info for a particular pathPoint
4. Add a getNextpoint function, which, given the path_id and current point number, returns the position of the next point
Friday, September 8th
I decided today that if i'm ever going to do anything with game design & development beyond tinkering and generally puttering around, I need to 'ship' a product, see it through beginning to end. This has always been my problem. I typically work solo (mostly due to not wanting to have to actively search out decent help), and so I usually end up getting burnt out; overwhelmed by the workload. While I mourn for the projects lost which could've been kinda fun (or really boring), I can see the value in a failure, as each has taught me something which help me now. One of the hardest learned lessons for me is: Keep the scope of your design within reason. Everyone wants to make the next Oblivion-killer, but the resources required for such a project puts it far outside the realm of reasonable expectations. Pick a concept/design with a reasonable scope, taking into consideration your resources and your manpower, and make it as enjoyable as possible; quantity does not always mean quality.
For this project, I decided to design a game in the likeness of a particular variety of scenario that has become popular in custom maps for a number of Real-Time Strategy games, called Tower Defense. The objective is to construct a variety of towers in order to destroy waves of critters as they march down a preset pathway before they reach the end, where they will tick down the number of 'lives' the player has. The specifics of these scenario vary greatly from game to game and map to map, and some have grown to be quite complex. Many of the latest incarnations include things like many selectible races (as many as a dozen), upgradable towers, mini-games inbetween rounds, up to 10 player multiplayer, and more. For the purposes of this project, it is neccesary to clamp down on a feature set, and to fight the inevitable feature-creep.
- Multiple pathways for creeps to walk and spawns points to spawn from
- A range of towers to build, approximately ___ (to be determined)
- 4 tower damage types:
Normal: Regular fire, shoots only at ground enemies
Combo: Shoots at ground & air, not as strong for either
Flak: Only shoots air, strong
Siege: Ground only, strong against Mechanical enemies, weak against elemental and normal
Magic: Ground only, strong against Elemental enemies, weak against mechanical and normal - 4 enemy types :
Normal
Flying
Mechanical
Elemental - Upgradable towers
- Experience / Levels for player to upgrade abilities (?)
We'll see how well this initial draft of the feature set holds up, but for the reasons already outlined, it will be ideal not to add anything that isn't already listed, and to reconsider various features that are.
With a clear idea on what to produce, the next step is deciding how to produce it. Another thing i've learned in my years of tinkering and not having made anything significant is: Treat game development like you would a ham sandwich, one bite at a time. You don't stuff an entire sandwich into your mouth at one time, or you'll choke. Set small goals for yourself each time you sit down to work on the project and youll find yourself progressing more consistantly, and feeling as though your getting more accomplished (and you probably are). With that, I put together a mini roadmap for the prototype.
1. Create mob class, to represent the critters to be destoryed (done)
2. Create path and pathPoint classes; Objects to be placed within the TGB level builder which will determine the path which the critters will walk (done)
3. Create mobSpawn class; Objects which will determine the location, type, and rate of mob spawns
4. Create building class, for the tower objects
5. Implement code which allows the construction of building objects on the map; Includes checking for collision with pathways and other buildings, making sure placement is valid
5. Implement targeting behavior in building objects
6. Implement firing behavior in building objects; Includes creation of projectile class (Though, there is no real collision involved, and the projectiles are purely aesthetic)
7. Implement life in mob objects; includes death behavior when life is reduced to zero
8. Implement player lives; After a certain number of mobs reach the end of the pathway (they have managed to slip through the players defenses), the game is over
Completion of these steps will see the end of the prototype process. At that point, the game will be playable, and major design decisions can be made before the real work begins. None of these steps represent major undertakings, and should not be difficult to implement, but will come together to represent an excellent base from which to move forward. With a gameplan laid out, the only thing to do now is proceed with the prototyping and hope for the best.