August GarageGames Update

My monthly GarageGames update is available here.

Progression

Work on Templar Skies has slowed now, due to other (good) factors. I’m still in the fix-check-repeat loop, and the game gets better for it every day. Finally fixed a couple of GUI-ability interaction issues also. Adding in the final data and assets has been slowed; final data has mostly been implemented, but I’ve put a hold on final assets for now. This is pending more gameplay assessments, where text data is cheap to change, and art & sound are expensive. Level tweaking is on hold pending the construction of a bigger level to explore more gameplay options. Yes, this project is dragging on, but hopefully all this extra time in the oven makes for a decent game.

So not much more to say than work is slow, always being bug-fixed, tweaked and improved, and this game will be released someday.

Meteors & More

Been doing more on Templar Skies this week, quite an iterative process of play the game, list what’s broken, attempt a fix, and repeat. I’ve also added in some more specific temp art (models that look more like what they are meant to be, rather than checkered cubes). I’ve tweaked the rules a bit, now when each wave of monsters spawns, some powerups spawn as well, rather than having powerup spawns on their own timers. It makes balancing easier, tying a set of powerups to a stream of monsters. Lots of bugs have been smished, and some new ones created, as is always the case. The build tower ability has been broken and fixed about 20 times now, driving me crazy. It should work for good now, and final spells have started their fix cycle. First to be done was Meteor, where a giant meteor falls from the sky onto the target. Characters and towers can both cast this now. It still has an interesting bug however; for some reason the towers are targeting me, rather than the invading monsters. At least it works.

This last one is the meteor hitting the player character. There won’t be any pics of meteors falling until I fix the player targeting bug

TS Production Update

This is an update for Templar Skies production for the past week.

Making this game has been an incredible learning experience for myself. I do have a habit of  dreaming too big, and fiddling around with tech and features instead of implementing content, which is the game itself. Before I take what I’ve learnt to make my next (smaller and more realistic) game, I need to suppress the designer in me to get Templar Skies completed. It’s now in a boring and frustrating part of it’s development cycle – testing, balancing and bug fixing.

So this past week I did a few things. Put together a final asset list, something that should have been done months ago. Due to my iterative development process, and my continual cuts to the game, assets have remained in a state of flux during the whole development cycle. I’ve started re-branding my promotional stuff towards this game, instead of the whole Inspire project. The new product page for TS can be found here.

I’ve also built a solid alpha of TS from the ashes of Inspire. I took some basic design elements, code sections I knew worked very well, and some simpler features, and rolled them into a new version. I removed some of the old resources, and added these 2. Dynamic Gravity Modification for 1.5.2, so that I could have flying/hovering monsters, standard in TD games. I also added Damage/Text Popup on Objects for some additional feedback on combat. A lot of the data entry for game objects has been done also. Imagining awesome items is always much more fun than doing the data entry for them

And I still have to finalize level design, I’m just not happy with it. Constructor is an awesome tool, but level design, and the patience it requires, is not one of my strong points. The design doc also needs to be updated with these changes, a tedious but necessary task.

This next week:

• level tweaking
• start adding in final data and assets
• bug smishin
• polishing
• playtesting

Cue Dramatic Music

I’ve had to make a tough decision this week. The way my business, and this project, are going, something has to give. In this case, it’s my precious ‘design babies’, and dreams of an innovative, deep game. So I’ve decided to produce a budget game / publisher demo based on some of the technology I have built so far. It won’t be as deep or complex as I’ve been advertising, and no where near my original design. I’m taking an axe to my current design doc and code base to have something I can finish in the next couple of months.

The game will still be called Templar Skies. The premise is the same, you play a Keeble Templar defending sky platforms, in an avatar based tower defense game. The persistent layer has been removed, now it plays more like Quake with creeps. But with melee weapons and in 3rd person.

You run around picking up weapons, armor, powerups and resources. Monsters can still pick up resources, and drop them when they die. Powerups replace feats. You can only have so many on at a time, and they drop when you pick up another one. Resources are still used to build towers, only now you directly build the tower rather than dropping a toolbox first.

The game will only have 1 or 2 levels, and will play like Desktop Tower Defense, with many many waves of creeps to survive. Some creeps will attack you and the towers, while others will keep plodding on. Each time a creep reaches the gates you are protecting, you lose points. You gain points for actions, like picking up items, killing creeps, building towers etc.

The reasoning for this is, I need to *complete* a game, and I need to have something I can sell, or demo to publishers. More information coming soon.

Demo Screenshot

The past week I’ve been putting a demo together. I now have one, however it’s not fit for public consumption so a screenshot will have to do.

demo.jpg

July Update

I’ve posted my Garage Games July update here. It’s a good summary of the game, go and read it.

All Quiet on the Development Front

Actual development has pretty much stopped this week as I have been cutting sleep out of my schedule (more than usual) in order to get some business stuff in order. I still haven’t done a GarageGames update this month, I’ll throw something together over the next couple of days. I am hoping to have a demo available by then, fingers crossed (and eyes propped open).

Misc for the Week

In between the AI stuff this week, I had a few smaller things to deal with.

Scott sent me the completed character animations, so I was exporting those, and getting them into the game correctly. I’ve had to write some c++ to dynamically switch between 1 hand and 2 handed attacks depending on what weapon is equipped. There’s also a well known problem with death animations in Torque, that I didn’t know about until the game crashed when it tried to play the death animation. After all the problems I had with using TGA textures, I found out that you can’t use textures with *any* transparency on models with the Skin modifier, due to Z-sorting being too complex. I found this out after I had some wierd transparency issues on the Male Keeble model, due to transparency being used to show the eyebrows. It’s things like this not being documented that let TGE down, I’m quite frustrated to be running into problems like this all the time. So next week I have to find a solution to the transparency, and if I can’t, the eyebrow polys will be attached to the hair model, which is mounted separately.

I also made a tutorial level with a tips system rather than a hand-holding system. I’m going to use this for the first public demo release, which should be available very soon for a small number of people, and a bit later for others. I need some more time to get it ready for a more widespread audience. I also made an animation test level, with a ability for each animation. The ability only plays the animation, and nothing more. It’s another example of how flexible AFX is, can be used for so many things, quickly and easily.

That’s about it for the past week, aside from a heap of little fixes each day. Slowly getting closer to being an actual game.

Zombie Brains

It seems like only yesterday I was writing an update for the Dream Game competition, when it was a whole week ago. I’ve been really busy this week, and I think I didn’t notice the time go because I was working long and hard on one problem – zombie brains.

I was updating the AI and pathfinding for the monsters in Inspire all this week. I say zombie brains because that’s about the level of intelligence they were at, and aren’t much better now. I’m not that great at maths, vectors and algorithms, but I’m getting by, and continuously learning.

So the old AI system had them scanning around them, if they spotted an enemy they would walk straight towards it and try and kill it, simple as that. If there was no enemy, they would try to capture the player’s spawn point, ending the game. That’s ok, but I wanted them to be a bit smarter. There’s other objects of interest, like their friends, enemies, powerups, items etc around that they need to decide how to deal with. There’s also the problem that each monster is solid with a collision box, so they can’t just pass through each other to get to these objects.

So this week I had to add decent pathfinding to their brain, so they would navigate their way to their target. This is all done in script, without prebuilt nodes on the map as well. It’s more of a best fit system – monsters get a target, and try to walk straight there. If there’s an obstruction closer than 5m then they will scan the locations around themselves in a 3×3 virtual grid, in an attempt to navigate around it. There’s more to it than that, but that’s the basic principle, and the system still needs a lot of work.

The other AI system is the threat system. Individual monsters decide what action to take personally by their own threat list. When they scan around themselves, they build up a list of enemies with their personal threat levels. They can then attack the player or tower who tops that list. That’s normally the entity which is doing the most harm to it. There is a second, meta layer to the AI. When an event happens to a monster, they ‘yell’. This yell is something only other monsters can hear, and it tells a global manager about the event. If a monster is down to 50% health, he may send out a ‘heal me’ yell. Each scan cycle, other monsters will check the global threat list. If one has the ability to heal, he will accept that yell, and his next goal will be to try and heal the hurt monster. This works for as many situations I add. There is 2 components to a situation – the specifics of an event, and if another monster has the feat to deal with those specifics.

So the system is working so far, but still needs polishing and testing, to make sure nothing odd happens, as is the case with procedural functionality.