What are you still doing here?

Head on over to http://exequor.com for all the latest news about "Tales of the USCA" and also "The Archangel Chapter".

This site will soon be recycled into something else. Please update your bookmarks. Thank you!

Day 396 : Lots of new stuff

A lot has happened with the project, so much so that I haven't found the time to post a lot on this blog. First and foremost, the official website is up and running at http://usca.exequor.com. I made it with drupal. Can't say I'm in love with drupal so far. The forums are an abomination compared to phpBB. Anyway, I'm staying the course for now. The reason why I wanted the website up is that I've made a teaser for the game, it's available on the site in either WMV or AVI.

I'm currently spending most of my time in blender designing. I've never been in love with Blender but it does the job. And Michael Reimpell's excellent exporter is doing a fine job. I'll start posting screenshots on the website as they become available.

Day 365 : One year already, and vacations status

It was a year ago today that I started the development of "The Archangel Chapter" using the "Dark Game SDK". One year later I unfortunately find myself with very little to show for in terms of playable demos and such.

These vacations have been the most trying and de-motivating of this project's lifespan. I entered them with the belief that the engine was ready to enter production and that I could concentrate on asset production and integration. Not so. The engine still had big missing or malfunctioning features. In the end I spend 75% of the time doing engine maintenance, feature additions and such, and 25% adding content. As a result, the originally planned milestone of having 1 complete production level with the different menus to lead the players to it not only remained unmet, but will be unmet for at least a few months.

2007 will see a drastic change of direction in the project. So far I've not hesitated to go back and redo things I felt weren't designed properly and with object-oriented optimization. The philosophy has always been to invest time now so that later things will fall in place more rapidly and such. There was also a constant thriving to put as many features in the game engine as possible.

But as a result of this approach there is no game here. No game to be shown and too many rewrites. The game's engine will soon enter a lock-down mode, and the game will be made with whatever features are in the engine (which is already way more than most, if not all, rail shooters I've seen in the independent circuit). Bug fixes only.

To that end I will spend the next few months intensely testing the engine and locking it down. The new milestone for the complete 1 level experience is pushed back 6 months. That's enormous I know, but so far every time I thought I was ready to do production, the truth has been far from it. So I'm playing it safe.

I wish I wasn't alone on the battlefield on this. I've had a few offers for help, but I'm waiting for concrete results before considering them official.

Happy new years to those of you who've followed this little journey. Lots more to come this year. Cheers!

Day 355 : Getting a grasp

Between family gatherings, playing with my christmas gifts, the worst cold I got for the past few years and what seems to be some unfortunate gastric problems that requires me to rush to the bathroom every now and then, I'm now managing to get the upper hand on the GUI and expect good results in the next few days. I don't think my original milestone for the christmas vacations is still feasible, but I'll give it a good shot for the 10 or so days I got left. I shall do my best to put aside my newly received videogames to concentrate on work. I can play once vacations are over. Now that I think about it, in 10 days will be the first year anniversary of the beginning of The Archangel Chapter. I think it's been a pretty productive years, the first few months anyway ;-). Going back to work.

Day 344 : Gooey Gui

I never thought something so trivial would end up being such a quicksand. Again it's great that something like CEGUI exists and that people took the time to build such a system and share it for free, but at the same time it's such a mess that, considering how trivial and limited the GUI requirements of my project are, it becomes legitimate to ask myself if it would have been faster to build my own GUI system from scratch.

I've spend the last weeks ping-ponging between the ideas of either taking TaharezLook and modifying it with the look of my game or create my own skin from scratch. I started with the latter and was faced with the mishmashy reality of the CEGUI system. Not the best design I've ever seen. Forums don't give a lot of answers either. XML files upon XML files of redundant data. For example, suppose I want to rename TaharezLook to SomethingElseLook, I'll have hundreds of occurrences of TaharezLook/ to search and replace with SomethingElseLook/. And a single mistake in one of the 4-5 XML files that constitute a skin will yield weird error messages that don't help pinpoint the problem that much. This just shouldn't be.

Anyway, after 2 weeks I give up. I'll just give a quick coat of paint on top of TaharezLook and be done with this. It's not critical enough to justify the extra delays. I'm entering a rather critical phase of development. The plan is to have something playable at the end of the Christmas vacations on the 14th. And not a prototype but something complete. GUI, mission/weapon selection etc. Let's see how this plan holds up.

Day 331 : Collisions and GUI

I think I'm pretty much done with my collision system. It doesn't hold a candle to any real collision system out there but for the needs of a rail shooter it will be enough. Roughly a combination of AABB bounding boxes in a tree. I needed it fast and simple. Trying to integrate OPCODE, even with OgreOpCode, wasn't smooth enough, so I skipped. Keeps the engine nice and light and avoids an extra dependency.

I'm switching road right now and moving on to doing GUI for menus and interface, as well as finalizing the adaptation of the Shmoulette engine with the game (there was still some splashovers on both sides, I'm now cutting them to be nicely and cleanly separated).

I'm using CEGUI for my GUI. So far I love it. It's a bit rough around the edge and the .XML structure could definitely use better hierarchy, but overall I'm impressed. The original plan was to cut as much as possible in the GUI and limit player options to a bare minimum. But since I'm getting a nice, clean GUI system free of charge I might actually put in all the options I want. I'll see.

The reason I moved to GUI design even though the game module itself isn't complete (I have no outstanding issues with it, but I know they're there, I just didn't find them yet) is because I was getting a bit tired of the loop I was caught in. Start to design a level, find a flaw in the engine, correct it, go back to design, find a flaw in the engine, rinse, repeat. So I'm taking a break from that and will work on GUI which is easier and thus more relaxing. Besides, learning GUI will help me turn the crappy editor I made into a slightly less crappy editor, which is always good.

I'm still on track for a somewhat complete 1 level gaming experience after the Christmas break. Should include main menu, profiles integration, in-between levels interface, and 1 complete level, art and all. With the exception of textures on models, for which I will accept placeholders for now.

What I'm getting the most fed up with now is compile-times. They get bigger and bigger. I feel I'm spending about 1/4 of my time finding bugs, fixing problems and implementing, and 3/4 of my time compiling. Not so good. Maybe I need a new PC...

Day 317 : Good ole Damocles

Just when I thought my collision system was going to work fine, it revealed a great big giant hole right into my XML parser code. Something you need to know about that XML parser code : It's one of the first thing I've coded when I started this project. It came after about a year of C++ break (I was doing actionscript 2.0). So it's probably the most crappy code you've ever seen. Ever. But I kept it because it would do the job. I knew a couple of things that wouldn't parse and I avoided them. But when I came up with my collision tree XML, it collapsed. Instead of patching this horrendous code I decided to trash it and pick up tinyxml to replace it. Still using my old XML and XMLIterator classes as wrapper. But then I found out that a lot of my classes unwillingly (unwittingly?) exploited a bug inside that crappy XML class. In other words, lots of stuff never should've worked but it did. That's the kind of pillar class that when it stops behaving like it used to, everything collapses. So it took a full day to rip the XML class apart and re-build most parts of it. So now the collision tree will work. My XML class still looks like crap, but at least now it points to something stable. I'll have some rewriting to do, especially in the editor, to make my XML loading and saving clean, but the hard part of this port is done.

The collision system I came up with is pretty adequate. I'm happy with it. A combination of AABB tree and spheres. No complex OOBB or collision meshes. For a rail shooter that'd be overkill I think.

Day 309 : Settling collisions

This has been one of the tough streaks of development. I once thought simple bounding-box collision detection would be enough for the game, but a few weeks back I ran into a slew of problems and realized it wouldn't be enough.

Problem is, when it comes to 3D programming, I'm like a blinded buffoon. I use Ogre, and I have a game that works with it. But I don't pretend to know how it works on the inside, nor do I have ambitions to. As far as I'm concerned, Ogre is a tool I use, if it works it works, if it doesn't then I'm screwed. But I trust its team to bring something to the table that's prod ready and rock-solid.

When it comes to collision detection, there is only lib out there that links to Ogre, it's OgreOpCode. I tried it but I didn't feel it had to robustness and level of finish that Ogre has. And if I have to modify it to work with my game, it means I have to understand it. And like I said, when it comes to understanding 3D engines, I'm a blinded buffoon. Can't risk it.

Other options for collision binding included full-blown physics engines. That is greatly overkill for a rail-shooter engine. At least for the first revision. So I've now decided to implement my own collision detection routines. It'll be simplistic, a list of boxes and spheres attached to bones. All defined in an XML file resting at the same place as the .mesh file. It should be enough.

I'm aiming to be able to spend Christmas vacations building content, and maybe deliver the first level with production models at the end of those vacations. Should be smooth sailing from there. Right? RIGHT?

Day 297 : Internet break downs production

5 days without internet isn't a good thing. You don't realize how much you need the damn network until it mysteriously disappears into the void. Well it's back now thank goodness, so I'll be able to look up all the things I couldn't these last few days.

I'm doing a lot of "final" prod things on Exequor. Final modeling, animations and levels. So far looking good. Textures will need some work, but that will come later. Of course, every final production step taken reveals failings in my almighty Shmoulette engine. So I fix those and strengthen it up.

Next big obstacle : collisions. I thought that standard bounding box collisions would be enough for this game. And it is for about 80% of the models. But something like sliding doors are more tricky. I now have to decide how deep I want to go in this. I don't want to get bogged down in some high-tech physics engine just to get slightly more precise collisions.

We'll see. We'll see. I hate to throw in a release date out of the blue, but I would say next fall appears reasonable. With an alpha going into QA near the end of June, during my bi-annual 3 weeks vacation. I have another 3 weeks vacation coming this Christmas, hopefully I will get a lot of things done then.

The scale is so much smaller than The Archangel Chapter, that I have hopes it'll get done soon. Stay tuned! Cheers!

Day 280 : Lib Shmoulette

Last weekend was pretty intense. Since I had to splinter the Archangel Chapter project into two project : itself and the new Exequor USCA game, I decided it would be the ideal time to implement a new DLL/plugin system that was lingering in my mind for a while. And so Lib Shmoulette was born.

Shmoulette stems from two root words : Shmup and Oulette. Shmup is a generic word used to describe shoot-em-up games. A few weeks before Challengemania VII, in April 2000, Kulka uttered the historic sentence "Oulette, kin, feuni!", which roughly translates to "Oulette, you're feunished!". And ever since, the word "Oulette" has been associated with "feuni", or "feunished". Although Oulette ended up winning the match against Kulka, and so it was Kulka who ended up "feunished", the association remained in the collective minds of everyone in attendance, and soon after everyone on the planet. And so the library is called "Shmoulette", because it helps you feunish your shoot em up game.

So Shmoulette creates a DLL that you put in the game's folder. This allows for the creation of Shmoulette-plugins that will end up defining specific content for your shmup. So not only can you customize your shmup using the XML files provided but you can also add codes in the form of DLL plugins.

I will probably release Lib Shmoulette soon after the release of the first Shmoulette game. Cheers!

Day 273 : Plan B

I haven't posted as much lately, but things still went forward. I fixed up the editor and I introduced a few behaviors for some of the models I previously posted about.

Today it struck me. When this project started I had 2 plans, Plan A and Plan B. Plan A is what you've come to know as "The Archangel Chapter". Plan A had a rather tight set of requirements to stay in the realms of feasibility. One of those requirements was that I needed to secure the talents of a character designer, and a good one to boot. Because I can code, and I can design mecha and architecture, but a character designer is something I'm not, and probably never will be. The problem with "The Archangel Chapter" is that it relies heavily on the plot, which relies heavily on the characters. If the character design is not top-notch, then the plot rests on nothing, thus the game rests on nothing.

As much as I tried to convince myself to the contrary, "The Archangel Chapter" has no art director, and no character designer. For the past 9 months the project has rested solely on my shoulders. Although I had high hopes that a friend of mine could hold the position of art director, for the past four months since he's been officially on-board, the results have been next to non-existent. And since I started to design assets for the game a few weeks ago, that lack of result has become a real hindrance to the game's progress.

If I have no characters, then Plan A is just not possible. So as of this moment, "The Archangel Chapter" is on hiatus until I have a character designer.

Plan B is something a lot simpler, a lot more straightforward. Same gameplay, same engine. Different theme, simpler story, no characters to speak of. Something I can manage alone.

It sure won't be as imaginative, it sure won't be as fun to build and to play, and it sure as hell won't be as rewarding, but it's better to put something good out there in the world, than to NOT put out something great.

I wish I could've stayed the course, but I can't. This will remain the production blog of the new game. About 90% of the efforts deployed so far will be brought over to the new project, so very little has been lost. Stay tuned for the next best rail schmupp out there : "Exequor : Tales of the U.S.C.A." (http://exequor.com)

Day 255 : Second production model

I'm starting the get the hang of Blender. I'm spat out my second production model, another fighter. With each new model I try a different methods of modeling, UV unwrapping and painting. So it's still not final. I went back to the code now.

Day 240 : First production model

At long last the very first production model is nearly complete. Considering it's my very first 3D model designed from scratch for use in a real-time environment, it's not so bad. Texturing is still very preliminary. I'll have to add some weathering. There's an off-chance that the model will be scrapped down the road as I get better and better with doing these 3D models. That sucks but it's part of the process. Anyway, enjoy the screenshot.

Day 235 : The Pipeline

Development is slowing crawling forward. Tons of real-life event have interfered, but the major reason for the slowdown is that my next step is the definition of the art pipeline, and I would have preferred to have found my lead 3D artist it was defined.

You see working with placeholder assets can only last you so long. I need to start integrating real assets. Naturally those need to be produced. To produce them, the pipeline needs to be defined. And so, here I am.

The biggest problem with game development now is that there is a de-facto standard in the 3D suite people use. That standard is 3D Studio Max.

Now 3D Studio Max isn't a bad program, although it carries a lot of legacy, giving it's interface a really dated, clumsy feel. Tried it. Hated it. Tried it some more. Now I like it. The problem with 3DS isn't the program itself, it's the price tag. 3500 US$ may be chump change if you're Electronic Arts, but for a guy doing this as a hobby project it's a fortune.

My 3D Suite of choice has always been Martin Hash's Animation Master. But there is no plugin for Ogre3D and I'm not moving into the plugin business. So that's out.

Maya's star appears to be on the rise. But it's still 2000$. Next.

Milkshape is ok. But really primitive. If I want fully rendered images for promos and such, I'm out of luck.

XSI is a tough cookie to judge. The plugin was created and is maintained by the Ogre God himself Sinbad. It's a 500$ program, which is reasonable. It's star also appears to be on the rise, after a few rocky years. But I tried the trial, and I hated it. Clumsy, weird interface. In fact, it's interface is pretty much as weird and clumsy as...

Blender. It seems the people behind blender had a theory : every user interface ever made sucked, let's make something completely alien that will revolutionize the concept of user interfaces. Not so, people. Leagues behind even 3D Studio Max and light years behind of Martin Hash's Animation Master, Blender's interface is a thing of nightmares. Every behaviour you expect, Blender will do something else. But the thing with Blender, it does everything from real-time to pre-rendered (it can render kickass images). Its Ogre exporter may not be as well supported as the Milkshape, XSI or 3DS one but it's still well-enough supported. But mostly, blender is free. That point and that point alone pulls it above XSI, and thus on top of the list.

I will spend the next weeks learning the intricacies of Blender. As horrible as the interface might be, it's all a matter of getting used to it. And get used to it I will. Expect a couple of production models to show up sometimes in October.

Day 212: Boring

Stopping such a big hobby project straight in it's track for several weeks is like slamming into a wall during a videogame car race. Sure you just pop back exactly where you left the road. But you're in first gear and it's gonna take a while to get back into full speed. I now consider myself in third gear, was in fifth when I crashed. It's especially tough when the tasks at hand are kind of boring. Stats system, scoring system, health system, shield, ammo, the works. It wouldn't be so boring if I actually had real assets to work with. But doing integration work with my crappy coder-art text boxes is pain, knowing it will all get replaced in the end anyway.

Anyway, half of that is behind. When the player gets hit, he loses shield, then health. When an enemy dies, score is added. When an entire wave of bad guy is killed, the special "wave" bonus is computed. It's pretty boring, but most of the programming challenges outside of final artwork integration are over. I just squash a few bugs here and there.

I'll need real assets. Soon.

Day 194 : Fantasia is over. Back to the game.

These last three weeks were the longest break I took from working on this project. 21 whole days. I did little bits of work here and there. Fixed a couple of bugs (disappearing clouds, and some adjustments to the drone architecture). Nothing major. But now it begins again.

A.D. Hoang Khan delivered his first sketch today. It kicks ass. I'll be working on HUD/overlay design for a bit. So I can move on to calculating damages, scores, special weapons ammo etc. This will wrap up the core programming nicely. After that I'll need to crank out final 3D assets. May the great Matriarch have mercy upon me.

Day 170 : No rest for the idiot

Not content with the progress I had made. I decided to work until the very last day of my vacation. I accomplished a lot, but it's starting to cost. Tomorrow is my last day of vacation and this time I'm not touching it. For real.

I've playing my first run through a multi-segmented level. Including the 2D cinematic system that I just developed and put in there. So, if I stretch the concept of "one complete playable level" as much as I can, then I can say mission accomplished.

It's not true though. Pretty much the only concept left to put in is the concept of dying. Right now you get hit but it doesn't do squat. But that'll wait.

Tomorrow is Silent Hill 4 marathon. This week the Fantasia Festival begins, which means I will have a lot less time to work on the game, for the next three weeks. Break will be a good thing I'm sure. Well, it's 2 am and I just wrapped up my work for this vacation. Now I can sleep.

Day 165 : I won't be meeting the deadline

As my vacations dwindle away it seems obvious the milestone I had set for myself, to have a complete 1 level working prototype by the end of the month, will not be met. To establish a quick post-mortem. Vacations always bring up unexpected events. My parents visited, take away 2 days. I cleaned up my apartment (a bit) take away 2 other days. Those are outside factors.

The single inside factor was the implementation of resource management inside the game. Up to now I had simply avoided resource management. I used the good old-fashioned "load when needed" that's built into Ogre. It meant tons of pauses with every first appearance of a bad guy. Not big deal I thought. Implementing resource management will be a breeze. It wasn't. I have to say, as much as I love Ogre, that it's resource manager is somewhat of an Achilles heel. Mainly because it has a tendency to crash inside without throwing an exception. If I could make two recommendations to the people out these using Ogre, it would be these:

- Start early. Don't do like me and wait until you have many groups containing many resources and world geometries all auto-loading and go "let's do a nice and proper progress bar in front of all of that". It's easier to implement if you have few resources and groups, and build from there.

- Ogre.log is your best friend. I had forgotten all about this one. I had so little problems with Ogre that I never really got to use it that much recently. When Ogre crashed repeatedly inside the resource manager, I didn't know where to look for answers. The debugger wasn't of much help, and (as it is often the case) when I tried smaller levels with fewer resources the crash never happened. Well, when I finally remembered that good ole file, I could pinpoint the crash times a lot quicker.

I'd like to point out that all the crashes within Ogre were created by my misuse of the resource manager (declaring resources that didn't have a path leading to it, and such and such) but it's true that I faced a lot of exceptionless crashes (mainly the dreaded "iterator cannot be dereferenced") that led to a lot of frustration.

I like to think that this is all behind me, but as with everything else. Time will tell. Tomorrow I will test everything out. Friday, Saturday and Sunday I plan on actually be on vacation from all of that. Maybe do a little Silent Hill 4 marathon. I still have reached two important milestones during these vacations : integration of the different level segments and integration of proper resource management. Not too bad.

Day 160: 2006 is the year of the exploding hard drive

It's pretty tough to keep coding and producing and such, without having hard drives burst into flames on your every other month. But this year beats all the odds. One of my 120gb drive has exploded, this one pretty much literally. It started to smell like burning plastic and then, obviously, died. It's tough to calculate the odds of having so many hard drive crashes in such a small time window. I feel like I'm spending more time backing up data than anything else. Nothing on that drive was related to the project, it was the receptacle for all my bittorrent and shareaza activity. So it's no huge loss. Still, it'll take weeks to recover, and there will always be a haunting feeling that there was something critical on there that I am forgetting about.

But this blog is about the project. Combination of the level segments is complete. It took several days but now the game can move seamlessly from segment to segment. That was the last huge step towards completing the prototype. Here's a small list of things to do before the prototype is complete :

- The 2D cinematic scripting language/segments.
- The loading screens/progress bar (which may be integrated with the 2D cinematic. Load while they read).
- Everything GUI (like the player's life left).
- Handling the life and death of the player.
- Scoring

The rest is mopping up the code, making sure everything is clean and tidy. Almost half of my vacation time is gone and I can't say I'm very confident in achieving my completed 1 level prototype before the end. If I can get rid of outside distractions, it is still feasible.

Day 149 : Art Director announced

Emotional blackmail, threats of physical violence and the application of those threats finally convinced Hoang Khanh Le of joining the team as Art Director and Lead 2D artist. I couldn't be happier. The man's a genius. You throw him a piece of paper and a pencil and give him 3 minutes and he'll throw something awesome back at you.

I've spend the last few weeks on forums trying to recruit people. I've also watched a lot (too much) of Battlestar Galactica. Those two things combined means I've begun to lost touch with the game's code. So today I'm getting back to it full force. There are a few nasty bugs to fix before my vacation starts next week. I want that vacation to be used to wrap up the prototype, so production can begin ASAP. Stay tuned!

Nobody would believe how messy my apartment is getting. Who's got time to clean?