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?

Day 141 : Development website opens

I've finally gotten around to finishing up and opening http://archangelchapter.com. I've also publicized the game in several development-related websites such as ogre3d.org, garagegames.com, deviantart.com and a slew of others. That's taken a lot of my time that was unfortunately taken away from actual game development. It doesn't matter how much progress you're making working alone on your prototype, if you don't have a professional-looking window to the world, nobody will take you seriously. It's the old chicken vs. Egg story : You need a good artist to make kickass visuals for your game and site, but to attract them you need kickass visuals for your game and site. Well, as a programmer I didn't do too bad a job I think. Well, you tell me :-D

Day 129 : Boss Battle Complete

Yesterday (day 128) marked an important milestone in the development of the Archangel Chapter prototype. The very first boss battle is now completely playable. As a playtest I let two of my friends play it and I liked their reaction. I'm still on track to complete the prototype and begin production by the end of my summer vacations.

Day 126 : Boss battle

After having completed the second part of the level I'm now at the third and final phase : Boss battle. Alot of game coding got delayed because I started to work on a website to recruit people. I also had some hard drives give up on me. Not the most productive month but all in all some progress. It sucks to have to do everything but hopefully that will change! Once the boss battle is complete, I'll go on to the "integration" thing I spoke in the last entry.

Day 106 : Second playable level almost ready

I have been through several nasty bugs these last few weeks. A lot of memory mismanagement on my part (a lot of the code was prototypal, it had to be brought up to production code standard). I'm happy to say that I have something that I consider close to production code across the board. Meaning my classes are clean, the original Ogre application I based my game on is now almost completely gone and everything is done in my code where it should.

I have designed a second level, which is actually the second part of the same level I had done before. This new segment features a new, different gameplay mode from the first segment. A third segment, the boss segment, will feature the third and final gameplay mode.

One huge thing that is up and coming is the seamless integrations between level segments. I want to be able to design and test level segments independently but the final result has to look seamless. That should keep me busy for a while. But I believe this is the last "unknown" in this project. That is, the last difficult step to cross before production can begin. I still haven't created one single asset for the game, so really I can't provide screenshots or anything. I can say that I'm up to 12000 lines of original code so far.

It'll be tough to recruit people to help out. It's the old chicken and egg story. I need an artist to make content to produce screenshots, and I need screenshots to attract contributors (including artists). Oh well, I'll cross that bridge when I reach it.

Christian out.

Day 92 : Slow on updates, not on progress

Just a quick note. Easter hasn't been as filled with progress as I had hoped. Thursday and Friday I was sick. Although it helped my relationship with the bathroom, it didn't help the project. Found an interesting bug today in my XML parser. Actually, I discovered something that made me think : "Holy crap that NEVER should've worked". And yet I had made rather good playable demo with it. Strange how sometimes stuff just "happens to work". Anyway it's fixed now.

I'm now working on part II of the playable level and I'm having a hard time making the tanks follow the ground. All these talks about normals and maths are giving me headaches so I'm punching out. The result I have so far is kind of satisfactory. But I'll tweak it some more later.

Also making the turret on the tank follow the player was also hard as the tank's orientation changes based on the terrain. But I got that part right on the money in not too long a time. Hurray for me. Now I need the cannon on the turret to also follow the player. Shouldn't be too hard but I got sidetracked by the XML bug. Will work on it later.

So good progress, but updates are slow because it kind of detracts away from making progress in the game itself. But I'll keep posting. Once in a while.

Day 79 : Milestone achieved

Sunday evening I managed to create the first-ever demo creating what the game will kind-of feel. What does that mean? It means the level started with an in-game cinematic made with the actual mission editor and XML file. It featured camera/dynamic object movements, "talking-head" styled character intervention/briefing and smooth transition to the game. The game itself featured the 40-60 first seconds of the missions. With actual bad-guy behaviours and special effects. Full collision implementation and such. Your own characters couldn't die (and still can't) but it register hits with the intended special effects. Limited sound effects and music were also integrated.

All in all for the first time I had something to show that went beyond tech-demos.

I don't post as much here as I used to. Fact is, I have subversion now to keep track of what I'm doing, so this blog I'll use only to publish milestones and also make deadline predictions. BTW the milestone I talked about, I had predicted I would reach that after Easter. Score one for the optimists.

Day 75 : I've been subverted

Actually, subverted is not the right term, it's more like subversioned. That's right. The Archangel Game now officially uses Subversion and the Tortoise SVN front-end to handle source control. Again, amazed at how something free and open-source could kick so much bottoms. It took me a couple of hours to completely integrate the project in a repository and all. My old automated batch-file that created dated .RAR files everyday will no longer be necessary. A system like Tortoise SVN is much better, and also lays the foundation to what hopefully will be collaborative work. Good job Tortoise!

Day 74 : Level design has begun

Two days ago (Day 72) I begun level designing the prototype's level (which should be level 3 of the final product). The editor (as mentioned before) was a real mess. But most of it is fixed now and yesterday and today was very productive. I also did alot of code cleanup. There were still traces of the old Dark Game SDK code that I needed to clean up. The opening cinematic for level 3 is half-done. I expect to have a playable segment of level 3 at the end of the easter break. Let's see how that prediction holds up!

Day 70 : Editor woes

Day 69 was my longest day on record. I was on the keyboard at 5h30am and got off at midnight. With about 1h30 hour break total during the day (grocery shopping and a 40 minutes nap) that was one hell of a day.

Although yesterday was long and productive, only the first half was true for today. I did work about 7-8 hours, most of it was debugging the editor, which, contrary to what I thought, was (and still is) far far from being ready to roll. I was hoping to start level-designing today, but after witnessing the state of the editor, I'd say I still have a solid week ahead of me before I get anything tangible done. Today was a frustrating day, it seemed every line I change I'd make a stupid mistake that ended in a compilation error. Spirit isn't here, so I'll punch out early.

Day 69 : Nothing sexual about it

Started coding at 5h30am. Those days I feel I get more done by 9am than for the rest of the day. Today was no different. Still, here are a few things that got done in the past few days:

- Main character movement. That was done during the 10 days of 3D software package exploration. The main character (at least a pretty good-looking dummy of it) moves on screen with animation overloading and such. This is the first integration of a new and more powerfull feature since the migration from DGSDK.

- Talking heads. The Talking Heads are back on-line and in a much more production-ready status than they used to be in DGSDK. This is the kind of code that's kind of a chore to do. Always seem to take too long for what it does.

- Cloud layer generator. Pretty cool cloud effects that (for now) seem to go very easy on the processor. It's a weird kind of zone-thing that can move around and yet can't. Everything about it is illusion, but it works. This marks the realisation of what created the wall with DGSDK : cool transparencies. I can say that Ogre handles it all flawlessly. Go Ogre!

- Editor (again) It seems everytime I touch the game I break the editor. Which is kind of normal since the file format and such is still being finalized. I should be done re-doing the editor tonight and hopefully I'll start actual level design tomorrow.

Day 66 : Back to programming

I spend the last 10 days checking out 3D software packages, evaluating and spitting out a few test-models for the prototype. The main focus was 3D Studio Max. I can't very well hide my contempt for this package, but forced to recognized it is the standard in 3D gaming asset production, I had to give it my full attention. Still, at this point in time, most roads seem to lead to Blender, as it is free and thus would not put undue financial stress on what is basically a hobby project.

I'm taking a break from 3D software evaluation and going back to programming. There were a few minor untied knots in my porting. Namely the window/text system. I should be done with them by the weekend.

Day 56 : Mission Accomplished

After 11 stressful and intense days I officially proclaim the migration of the Archangel game from Dark Game SDK to Ogre 3D and Audiere to be complete. That's right, this morning I integrated the open source audio library Audiere into the equation and it took less than 10 minutes to have it hooked up and working.

There are few minor things that are not yet in the new engine that were in the old. Minor things like text pop-ups that were half-assed in the old game anyway and needed a re-write. So they don't count.

I no longer have any anxiety about Ogre. I am sure that this engine will be with me until the project's end.

About half a week ago I made a prediction, that at the end of the migration, I would have had half as much lines of codes as before. My game had nearly 18,000 lines of code before the migration. Now, drum roll please, 7773 lines of code. That's more than 10,000 lines of code that I discarded from the old game code because Ogre does so much more than Dark Game SDK and has an API that is so much cleaner. Although it's a pain to see what basically amounts to a small novel being thrown away, there was just no point in keeping my prototypal, rushed-out code versus using the rock-solid foundation of Ogre.

I will take a break from programming now, and I'll move on to study exactly how the art pipeline will work in the production version of the game. So far I have used Milkshape, but that free license has now expired and I'll study other graphics packages before continuing the development. This means daily updates to this blog will stop for a while.

I can honestly say that moving to Ogre was probably the best move for the game. It is an awesome engine and I can't wait to see what it'll be able to do as the game develops.

Over and out.

Dot Net sucks ass

Here are my first official Visual Studio C++ 2005 Express (I'll refer to it as Dot Net from now on) definitions:

"Build Selection" : Throws a dice and builds whatever projects in your solution it feels like building. Will have a tendency to pick a project you haven't worked on for days.

"Faster" : Slower.

Day 55 : Quaternions can't do magic

After bringing the editor to what it was before the migration and testing the new track system from Ogre, I realised that Quaternions weren't the be-all-end-all solution to rotational glitches. In fact, twice in my path 2 quaternion keyframes with the object heading in a similar direction produced very erratic "detour"-like interpolations, even with the "use shortest rotation" setting. This Quaternion problem is turning out to be major. Even small rotations may end up causing major interpolation problems. I thought I'd be shielded from these problems I faced in DGSDK. Bleh, I might have to move back to my old workarounds using targets and hard-rotations. This is a pain.

Day 54 : Furthering the Editor

Exactly one week into the migration and things are going according to my original optimistic predictions of 2 weeks, rather than either my original pessimistic predictions of 45 days and my later optimistic predictions of less than 2 weeks.

Worked on the editor tonight. I'm back at being able to save and load levels (w00t). Format had to change because of the use of Quaternion and the new World Class. Will go to bed a little early. Sources of (negative) stress outside the project have been added to the already high sources of (positive) stress from the project. It's starting to take it's toll. The weekend should yield great results, but tonight. Sleep.

Day 53: Worlds and Water

Yesterday I took a break to go see Ultraviolet. That had to be some of the worst CG this side of 1986. Still a cool movie though, lots of action and fun. Totally pointless and plotless.

Tonight wasn't so much about porting my "Terrain" class from the old DGSDK game as it was about creating a new class called "World". Since Ogre handles terrain differently than DGSDK, the same rules don't apply and so a new, different class was required.

This new one will kick more asses than the old Terrain class. It'll use Ogre's advanced rendering techniques for bodies of water in the terrain and such. I'm still experimenting, but I should be done with by the weekend.

Day 51 : The Editor

Up to now I ported code that served in both the game and the level editor. Tonight I moved towards getting my level editor back. I have many unknowns as far as changing the way I store rotation (since DGSDK, and my old code, worked mostly in Euler and Ogre in Quaternions) so I want to be able to design a few camera paths and see which solution is better.

About halfway done with that. Should be done tomorrow.

Day 50 : A Squarey kind of Wheel

My game code now looks more like an empty shell of it's former self than anything else. As much as I'd like to think the game should be isolated from the engine to make future such migrations (always a possibility) as painless as possible, in reality it's just not practical.

Alot of my game's former code were workarounds and tweaks adapted to the engine. For example, my former game code worked in "frames" as a time unit. Ogre on the other hand uses "seconds" as time units, a more practical solution in my view. Should I just stick to frames just so my old code would still work? Or should I move on to time-based animations and make everything better?

At the beginning of this blog I mentioned that I had coded some 18,000 lines of code since the start of the project 45 days before. At this rate I make a prediction that at least half of those will be gone by the time the migration is complete. I am effectively shedding my squarey wheels for, I hope, round ones.

Day 49 Evening : Mopping up is 90% of the job

Studying the art pipeline and converting my 3-4 assets to Ogre's .mesh format was a breeze. So all of that took a huge hour of my time (including re-boning a character, something I meant to do a while back).

It hasn't gone as fast from then on unfortunately. I thought I could #ifdef a version of the game that would support both Dark Game SDK and Ogre. I gave up on the idea. Both engines have such diametrically opposed design mentality that it just would've required too much work. So I began to completely mop out DGSDK code and clean up the rest. I did alot of maintenance on the code, stuff I was putting off doing in the old prototype. A few other classes work. A couple, like Font, Text and Terrain, will have to be started over. Unfortunately I work tomorrow, which means progress will slow down for the next five days. Still, considering the progress I made I would be surprised if it took longer than the originally planned optimistic 2 weeks to wrap up the conversion.

Day 49 Morning : Statics and Dynamics

Woke up at 6am. For a sunday that's unusual. Two of my internal classes : StaticObj and DynamicObj are now back on-line and using Ogre instead of DGSDK. Again, I am amazed at Ogre's completely logical API and the ease with which I've managed to port these two classes. I did run into what I believed to be a bug in Ogre. But instead of prematurely mouthing off on the forums (which I did with previous engines) and looking like a idiot (again) I investigated it fully and it was in my scripts. Bad programmer. Bad.

I'm pondering what to do next : either convert "playership" and "drone" classes or switch to testing out the art production pipeline. On one hand I'd like to keep going programming-wise because I'm on a roll, but on the other hand all the level scripts I have load and play models that have not yet been converted to Ogre, so I'd have to change all of those to load like "ogrehead" and then switch back once I get the real model exported into .mesh. Oh well, I guess that answers the question, now where are those export plugins?

Day 48 Night : We have visual

After juggling with the internal structure of the game, plugging and unplugging different classes and such, I'm happy to report that the game's camera class is back on-line and if I run the game the camera is back following it's good old spline from the level's XML file exactly as it used to with DGSDK. It's the only component back on-line so far, but doing the camera work itself didn't take very long at all (an hour or so at most). Dealing with the rest of the architecture to prep this work is what took the longest. I'm starting to think my estimate of 2 weeks - 1 month 1/2 was way too pessimistic. But I'm sure there are many walls in front of me. My GameObject class will be the hardest, I'll take a look at it tomorrow. As this was my milestone of the day I'm going to go watch some anime, and maybe get some decent sleep. Decent sleep. Right.

Day 48 Morning : Crying

I finally plugged in Ogre into my code, and after a giant namespace clash (actually, stuff clashed because MY code didn't use namespace as it should, and still used defines such as #define PI 3.14something) and Ogre didn't like that. But it was pretty much all my fault :-)

But then something made me cry. In the prototype I made with Dark Game SDK I took great pride in the design I made of a spline interpolation algorythm to create smooth camera and object movement. I took alot of time designing a cool API to add and delete keyframe and then have it calculate a spline based on the keyframes. Well, as it turns out, Ogre already has that built-in. I didn't look at it in depth (looked at the Camera Track example) but it does look like had I started with Ogre from the beginnning I wouldn't have had to code that at all. Damn me. Well, I'll probably keep using mine because the prototype is already coded and it works. Still. Damn me.

Day 47 : Migration

This is the first post of the Archangel Game's development blog. But it is actually day 47 of the project. The project was started on January 15th, 2006 but I have decided just now to start a development journal. I will document here the different milestones and main events that will happen during the development. I do it mainly for myself, to keep track of how long different steps in the process have taken, and help me to better my abilities to evaluate future time-budgets on game development.

This is how the project started:

I had spend more than a year trying to make a game with the Torque Game Engine, but it would always seem I couldn't go anywhere with it unless I went exactly the way the engine wanted me to go. After giving it one last frustrating shot over the christmas holidays, I decided to give up on it and move on. As long as I was switching engine, I decided to also create a new game concept. And so the Archangel Game started. The Archangel Game is just the name of this blog, the game has a working title which is not yet public (because it could hold on to the end).

The first month and a half of the projects were created using the freeware edition of the Dark Game SDK. And although I can readily recommend it for novice programmers and prototypers, at the end of those 45 days I stumbled upon many limitations and some nasty bugs that prevented me from carrying on with it. And so yesterday, on day 46, after some 18,000 lines of code, I decided to start migrating from the Dark Game SDK to the Object-Oriented Graphics Rendering Engine, better known in the community as OGRE. That is the story so far...

I am now 24 hours into the porting and things are, I think, running smoothly. After 6 or so hours of work, I've completely "unplugged" the Dark Game SDK from the game. I also, at the same time, ported the game from VC6 to Visual C++ 2005 Express, which created another slew of compiler errors. I'm happy to report that things are now back to compiling as they were. But now I have a game with no engine. Nothing's visible, I didn't even dare to run it. Tomorrow, I start plugging in the OGRE engine. I have an E.T.A. of between 2 weeks and 1 months 1/2. That because I've never done such a thing and I don't know yet how OGRE works.

I've spend a few hours with the OGRE docs and so far I'm in love. Let's see how all this holds up.