Stop, Think, Don't delete your stuff.

When I travel I get the most of my coding done. You sit in a train and you just know you've got a half-hour to waste. Add the laptop, subtract the internet, and you've got a pretty good motivation to do coding. Ofcourse, I also code at home so before I work on my code at home I copy the code from my laptop over here. When I leave the house for more then a day, I copy my code from my PC to my laptop.

Bulletproof system? Think again! Apparently somewhere after an unscheduled travel, in which I did a bunch of work on my code, I forgot to copy my code to my PC. So I get ready for the weekend, copy my code from my PC to my laptop and... "Hmm I thought I did a lot more work already" Very stupid indeed. Guess I'll check timestamps in the future.

In any event, I finished the error handling routine and I'm now replacing old error code with the new, much more efficient, way of error handling. I'm also implementing the log entries throughout the program. It's not that much work but it tends to get a little tedious every now and then. I should probably have everything moved and upgraded by the end of this week, or by Monday.

Additionally, my vacation has officially started, so the next 6 weeks may be light on code. Not to worry though, I'll get back to it afterwards. I will try to update bi-weekly to 'keep the habit' so to speak.

Peeking under the hood

Unlike what you might think by now I've been quite busy, both with real life and to a (surprisingly good) degree with my code.

I've got the Arena loading pretty much nailed, save a few finishing touches, and I'm almost ready to move on to the next bit. I have decided that this will be error handling. Currently I'm just pasting crap to the error log that SDL generates automatically, but I keep finding this approach inappropriate and very unprofessional... not to mention it's making my code look all cluttered.


"A code snippet of what will soon be a memory of bad error handling"

So I've decided to write a procedure dedicated to error handling. Not only will this save this considerable amounts of code but it will also allow me to easily output everything uniformly so it's easier to browse through the error log. I've also decided to output a general program log that keeps track of routine stuff, non-routine stuff and debug information for errors. Although I may just report the error in the program log and stuff the debug information in the error log... I haven't decided yet... though, now that I think about it, I think I prefer the latter approach.

Also, I'm changing my update day to monday as that's more convenient and increases the odds I will actually post an update. (...like I should! Bad demotivated Rider! Bad!!!)

Zap-a-Bug!

So I've been zapping bugs the past week(end) and I've finally finished up the monster database loading routine. I'm now writing documentation on the usage of the monster file as I already did the same for the level format. I'm hoping this will aid in getting people motivated to make their own content one day. If something's easy... that just means less standing in between an end-user and their potential new mod/total conversion/whatever!!

But I'm glad that's over with... freaking bugs where driving me bonkers... apparently I wrote a format that's pretty picky about the 'end of line' character... I'll have to include that in the readme somewhere.

The next thing I'm going to do is create the 'attack file format' which will hold all the AI usable attacks. After that's done, I'll find out a way to generate an arena which will be used for combat and once that is done... I can actually generate a monster when an 'encounter' happens, place him and you in the battle zone and start the battle procedures!

I'm so close I can taste it!

See you next weekend then :)

Your mom's an inner workings!

Not a great deal of progress since the last post here. The whole encounter thing works like a charm now and I started the next required component for combat encounters... the monsters! So far the data structure is in place that will hold the monster prototypes (from which the actual monsters are to be generated) and I'm nearly done with the part where they're loaded from a separate file.

Which reminds me...

I was thinking about how the game's root folder was getting sort of full and starting sorting stuff, dumping it neatly in folders like "bmp" and "levels" when I figured that it would be SO easy to just create an alternate version of these folders and thus allowing users to easily mod the game to include new levels, different monsters and new tilesets. So I dumped all those neat folders in a base folder and decided to include full-on mod support. It should just be a matter of making the parameters, the one indicating where to find the files, slighly more dynamic by adding a 'base folder name' part which can be changed to any value thus changing from which "mod" folder the contents are being loaded.

A brilliantly simple solution.

So I just got to figure out how the player will swap between mods (menu, command prompt) and how the program logic will fit in that picture (will it preread the folders content and offer each folder as a possible mod?) and we've got mod support!

The whole monster/encounter bit is still main priority, but when I get enough of boring procedure writing I can always alternate between that and exciting new feature coding! Woo!