Yesterday was spent tidying up the sewer puzzle. Still a few details to be ironed out, things that don't look right, etc., but over all I'm pleased with it. This evening I may use a new sewer pic as the weekly screen shot.


The more I look at the web site, the more I think it needs improving. But I'll leave that until much later. The best web sites are minimalist, hiding tons of awesome content. When I have the content (i.e. the screenshots get closer to the final view) then I think I'll remove the fading screenshot things from the home page. My original vision was for a blank page that simply contained a book, inviting people to open it. I might still go back to that.

Just added 830 new scenes! OK, it's not as spectacular as it sounds. This is for the sewer quagmire puzzle, and the same backgrounds are used again and again and again, with very minor changes. But I'm very pleased with the art. I think it's among the best stuff I've done. Nothing dramatic, but it gives a good feeling of depth. Today I'll write the code for the [SPOILER DELETED] which provides the solution to the puzzle.

At present, I think the sewer puzzle will be the hardest of them all. This is the one I expect people to get stuck on, which seems very appropriate since in the story you are wading through mud in endless tunnels. Getting stuck just feels right. Of course, in testing it may be that experienced gamers breeze through the whole game in an hour. or maybe I'll get emails saying the puzzles are repetitive or illogical, or just right, who knows? Only time will tell.

While working through the dialog, I'm fixing and adding little parts as I go, like writing a little function for displaying writing on paper. Les Miserables contains a surprisingly high number of notes written on on pieces of paper found lying around. Hugo seemed to like that method, and used it do reveal what the bishop was like, what the revolutionaries were like, saving Valjean from Jondrette, and so on. It's one of those little touches that is just perfect for adapting into the adventure game format.

Along the way I'm also working on the sewers puzzle. It's one of those things (like crowd scenes and the barricade animation) that I was expecting to do later in the summer, so it's nice to get it out of the way now. I've tidied up the manhole code. Every fourth street now has a manhole, so you can now navigate Paris both above and below ground.

And finally, I'm adding a new scene for the close-ups in Montreuil (raising the cart, renting the buggy, that sort of thing).

All in all, a busy day!

This first game is such a learning experience!

I've decided to add the generic dialog before the puzzles. This will take a couple of weeks. I had originally planned to create all the puzzles first, but I kept stopping to create dialog (some puzzles don't make sense without any dialog at all) and this slowed things down. It also made it impossible to plan. I know that the game has 29 parts, and each part takes about a day to code and a day to test, but adding dialog then means each part is a day or two or three behind schedule, and that becomes discouraging. To be motivated I need to see real progress each hour. By separating the dialog and puzzle parts of development I regain control of the schedule, and can see pleasing results every time I sit down to type.

Judging from comments by other independent developers and authors, this is a common problem. I think it's because being independent requires more thought, and thinking is hard work. It's different when you work for an employer. In most jobs your requirements are well defined, you go to work, follow the prescribed pattern, and if you don't feel motivated one day you just run on autopilot. But being an author or developer is different. There is nobody to say "now do this, now do that" and no reliable path to follow (if there was a reliable path then everyone would give up their job and become an author or developer!). So the uncertainty is real and this can easily translate into a lack of motivation or, in extreme cases, writer's block.

It seems to me that the solution is to break the tasks down into easy steps where you can see real results from every session of work, thus being reassured that everything will be OK in the end. In my case, this means separating one big and unpredictable task (making a scene involving dialog and puzzles) into two smaller and more predictable tasks (one for dialog and another for puzzles).

Yesterday I added more conversation choices regarding the bishop. Today I'm adding more detail to the plans for the remaining parts of the game. Then it's on to part 4 of 29. (How many times have I said that? :) But don't worry, the work is still on schedule. It's just that the schedule is constantly being rearranged.

FInally got the new crowds working, relatively smoothly, without poeple wlakingthrough walls, floating in the sky, or jumping random distances then disappearing. :) I just posted a full size screenshot (the first ever!!) on the weekly screenshots page. The actual scene is larger than this and scrolls, and of course the poople move.

Thinking aloud, when I do the Dante's Infeno part I may extend it to include the entire Divine Comedy, just so I can have endless lines of angels ascending to and descending from heaven, as in all those old medieval paintings. I think that would be cool. But maybe not this year. :)

The crowd scenes are looking good (to me anyway). They were all finished by yesterday afternoon as planned, but they took far too long to load, so I spent the rest of the evening (and continue this morning) finding ways to make them load faster.

Today's hot software is AutoHotKey. I mentioned before that adding 4,000 frames of animation by hand is no fun, and adding it twice (due to finding the inevitable bug) is worse. So this morning I'm brushing up by AHK skills. AHK is a free utility that automates just about anything. As you might guess it's made by hackers (not to be confused with crackers - see the Hackers Dictionary for the distinction) so it's not entirely user friendly, but it's free and vastly powerful, and when all else fails it can be a lifesaver. I'm fairly confident that I'll have a genuine screenshot of Paris-with-hundreds-of-people online by the end of today.

I'm very pleased with the crowd scenes. This week's weekly screenshot may be a little late, since I want to show off the finished result. If I have any fingers or sanity left - one of the final stages is to add over four thousand frames to the game engine, one at a time. And if anyone tests the game and asks me to change them, there will be a simple answer, and it rhymes with "mo."

The screenshot may even be (gasp!) full size, since the animated characters are so tiny. OK, it's not exactly Assassin's Creed, so don't get your expecttaions TOO high, but imagine Monkey Island 1, where the town has little people wandering around, except there are a LOT more people. Most adventure games have three or four characters on the screen at one time. In this one scene there will be about a thousand people, plus more entering and leaving every second. Whatever else they say about my game, it will certainly be different. :)

I love Bink and Smacker! For those who don't know, it's a set of video editing tools that are free to use, but they ask for donations. And despite my tight budget (I have literally 73p in the bank and 3p in my wallet until I get paid next Thursday), I will definitely be donating something. Here's why:

I want to have hundreds of people walking around Paris, but I can't use the normal sprites for this, as that scene would slow down to a crawl, there would be memory leaks (meaning everything after would slow down as well), and with anything that complex you just KNOW there will be bugs. Plus I would have to seriously re-write the code, and you know how I hate doing that. So instead I'm creating an animation (actually several animations, to allow for the character to walk behind some and in front of others). Which to cut a long story short involves hundreds of tedious stages and thousands of frames that must be added to the engine one at a time. If I was a rich man (da-da-DA-da-da-da-DA-da-da-da-DA-da-da-da-daaa) I would have not only stairs going up and stairs going down, I would also have a super powerful workstation and Adobe Premier. But I am not and I don't. And most tools simply cannot cope with what I am trying to do. And if they do, they tend to make everything fuzzy, but I need pixel accuracy. Anyway, after trying numerous cheap and free alternatives, nothing worked... until I tried Bink and Smacker.

I still have to do most of the work in Animator (an old DOS based program that is still the best for the non-millionaire) so I don't think it will be finished in tie for tomorrow;'s Saturday screen shot (I'm working all day today and tomorrow at my day job) but Bink and Smacker saved me a ton of the REALLY tedious work in converting video. And, joy of joys, late last night I discovered something amazing! It even outputs direct to FLC format!!! I'm sure that means absolutely nothing to anyone reading this, but that alone is enough to make me want to donate to their cause. What a great program!

The crowd scenes were finished by 4 pm yesterday, then I made a discovery: they looked rubbish! I forgot that most of my city scenes have people at a very small scale, and the crowd characters (since they are mostly very minor characters) have not been smoothed and polished. So when they were scaled down you just saw a mess of pixels and it's very hard to see what they were supposed to be. So I spent the rest of the evening recreating them using antialiasing so they are at least recognizable as people now!

I originally planned for ten days for the crowd scenes, and this has only taken four, so I can afford another couple of days for the icing on the cake. You know those 'sim' games where you build a park or hospital or railway and all those little people are constantly walking around? That's the effect I want in the middle of Paris: busy with endless streams of people. For technical reasons, this is harder in an adventure than in a sim (e.g. for scaling and talking: building games don't expect you to interact with the public, there is a very limited range of movement, and there is usually no perspective). Also, the wandering crowds are a high priority for a sim, so they can afford to spend longer on that part of the code. So I won't be able to do it exactly as I want (and don't even ask me about memory leaks and collision detection!)
. But it will look close enough to be very nice.

In short, the Notre Dame scene will have crowds of people who stand around and twitch, and the Paris city center scene will have endless streams of people walking in all directions. The endless city streets already have interesting people just standing around at random. These are all little touches that I think will go a long way to adding depth and immersiveness to the game, and make it stand out from other adventures. I hope!

I've created the sixty crowd scenes (actually 56 groups of between 2 and 7 people) and I'm in the process of writing the code to place them at random points in Paris and elsewhere. Then by this afternoon (or this evening) I'll get back to part 4 of the story code.

I had originally planned to add the crowd code in the summer, along with the barricade animations. I think now I'll probably do the barricade animations when I get to that part, in late May. The late alpha test version will probably have just the story up to the barricades, then I'll add those parts in June. The sewer code will need a little extra time anyway.

So the next testable version will be the whole story up the first part of the barricades and will ship in the last week of May. With the usual caveats that everything (especially the dialog) is unpolished.

I've created about sixty "crowd scene" characters, including some that nobody will see unless they come back to the park a lot of times. That wasn't intentional, but in early tests, some of the characters only look right in the park. I may have to make use of them in one of the puzzles. This morning I animate them, this afternoon I add them into the game engine, and then (after swimming) start on writing the code to make them actually appear in the game. Hopefully they won't ALL look stupid. :)

I'm selling this game partly on the technicality that, at 5,000 scenes, it's the biggest adventure game ever. However, I just found out that Anacapri (the soon-to-be released sequel to the previous biggest adventure game, a Quiet Weekend on Capri) has 8,000 photos. Drat. :)

The next version will have a couple of hundred extra "main" scenes and at some point in the future I will add more randomized outer space scenes and underwater scenes, so the total will exceed 8,000 eventually, but by then who knows, maybe Capri 3 will double the number again? Oh the arms race! I suppose I have to fall back on the other two definitions of biggest: biggest in scope (covering serious topics) and biggest game world (covering more countries, worlds, galaxies, etc.). I'd better edit the web site some time to reflect this.

I've had a bit of chest pain for the past 36 hours. It probably isn't related to anything computer related - more likely because of sleeping badly thanks to a cat who refused to get off the bed! But just in case I'm taking a day off the regular coding (which involves sitting in the same position and concentrating) and I'll work on crowd scenes instead, which involves a completely working position, more movement (to the scanner and back!) and less concentration. Back to normal tomorrow.

Finally completed part 3 (Jean Valjean's redemption). When I come home tonight I'll see how far I get with part 4 (getting him the factory job).

I'm thinking more and more about adding crowd scenes in the next few weeks, rather than wait until June as originally planned. I spent some time yesterday looking for old French paintings of the time. The crowd scenes are too low resolution to be any use for direct scanning and editing, so I'll draw them instead. But I shall probably wait until I have a few more parts of the game complete first.

I'm embarrassed to report that I'm still on part 3. Only one small change to make, so it really should be finished by tonight. Yesterday was chaotic and today is fully booked with other activities, but I have three days off work over the next seven, and a full week off at the end of the month so should catch up and be up to part 9 or 10 (of 29) by the end of the month.

My day job is working at the post office, and yesterday was a real motivator for getting the game finished. Our sales manager was in and we had to spend the whole day annoying people trying to make them sign up for credit cards. I pride myself in doing my best at work, and I produced more leads than anyone else, but I absolutely hate doing it. I dreaded the day for a week beforehand, and spent most of the evening wasting time on the Internet, and eating far too much, trying to unwind. Where I live there are very few jobs, and nearly everything involves sales targets. The post office is the best there is for someone in my position. We are not the only company claiming to have the best credit card, and ours like others have hidden costs that the customer does not notice until it is too late. Besides the misery that debt can cause if handled badly. High pressure selling in an already saturated market is not an efficient way to run an economy, even apart for the stress it causes people. Though I am probably unusual in the amount of stress it causes - most people just get used to it and go with the flow. I have always swum against the tide.

I really REALLY hate hard selling things. I don't mind gently offering people something that is genuinely different, if those people already show a vague interest. For example, people who visit game oriented web sites or search for "Les Miserables" might be interested in this game, and I intend to tell them as much as possible. They don't have to read if they don't want to. And if they don't like it, that is a sign that I need to improve the product, not that I should sell harder.

I hate accosting customers in the post office. They come to buy stamps, not to get a sales pitch. They feel awkward and pressured and annoyed and for every sale we make we probably persuade two people to never come back. But the sales manager only comes once every couple of months so he does not have to see the long term consequences. It really, really grates with me. I don't know how long it will be before I can make a living as a games developer (I will need to sell a hundred copies a month to leave the post office job). If the game doesn't sell then I will change it and improve it and continue to improve it until it does. Maybe it will take six months, maybe six years, but however long it takes for me to escape the post office will not be a minute too soon.

End of rant!

Two posts in one day? What kind of crazy and unpredictable thing will he do next? :)

I've been experimenting with ways to improve the dialog. I welcome any suggestions at this early stage, because it's easier to make major changes now than later. I spent the evening seeing if it was possible to make the game using ONLY dialog from the book itself. Let us call it plan A.

Plan A: A game using only words from the book. That would be the ideal solution, as it would give the game unimpeachable quality, and another unique selling point. It would also save me the trouble or rewriting dialog. However... It would add AT LEAST three days to developing each part of the game, i.e. three months to the total development schedule, which would prevent other tasks being completed. Also, it would bring a new set of problems, mainly the difficulty of taking long nineteenth century prose and turning it into interesting puzzles without changing any words.

It would be a wonderful way to approach the project, if only I could justify the extra time. It would force me to have an extremely deep understanding of every page of the book (in order to twist it around into a new form without destroying its sense and flow), and would result in something very special indeed. So can it be justified in terms of either sales or my long term goals? Sadly I think the answer is no. There are many millions of fans of the musical, but probably a much, much smaller number would want or appreciate a game that was so close to the book's own dialog. And my own personal goal is to create a game that deals in serious topics, nt one that simply presents classic books, The books are only a vehicle, an excuse for the themes.

Plan B: The obvious solution then is to create dialog that is very close to the original but not slavishly so. But this again requires a deep understanding that I do not claim to have, and an investment in time that, while less than plan A, is still considerable. Les Miserables deals witrh universal themes (poverty, justice, redemption, etc.) so I am confident that I have a reasonable grasp of these already, but to imitate the style of the dialog would require skill I have not yet acquired. While this would certainly be a little faster than plan A, it would also lack its purity and selling point.

Plan C is to do as the cartoons and movies do (or at least, most of them). Use modern language, but still treat the subject with respect. If I aim at the mass market then this is the obvious choice, and it is certaily the easiest to do. Though my own dialog talents may be lacking, anyone can improve it simply by listening and saying "that does not sound right." This seems the fastest and easiest method.

Until tonight I had planned to do something between B and C. That is, something with a hint of nineteen century style, but with the freedom to use a modern approach when I wanted. But I now think I need a clearer policy. The B/C approach could simply add to the time needed, and make the dialog sound anachonistic and awkward. I need to make a decision, and recognize that whatever I do will have its costs.

So, upon reflection, I have decided. Option C. Ultimately, for my purposes, only the ideas matter. The language used is secondary.

The language will be deicded by the ideas and the audience (modern). For example, take the ideas that Fantine cannot do a man's work, or that she is evil for having a child out of wedlock. Those are old fashioned ideas (to most people), and reflect certain ideas of status, decorum and morality. So whoever espouses those ideas would speak accordingly. They would be polite, and not speak disrespectfully or use slang. On the other hand, modern slang and disrespect might be appropriate for the street urchins.

Finally, because the ideas matter, I will tend to make the characters more broad minded and more willing to debate than is perhaps realistic. In real life most people do not like having their core beliefs challenged, and digging too deep is considered impolite. But for the sake of exploring ideas, the characters in my game will be remarkably patient and objective. In the early versions the dialog will inevitably seem awkward and sometimes hard to follow. But by the time the final version, the ideas should flow reasonably well, and the motivations at any point should be clear. If I can achieve all that by December then I shall be happy.

So much dialog! Dialog is the big unknown. (OK, one of the 325 big unknowns when making your first time game!) I had less time than expected last night, so spent three hours adding dialog. "Three hours" you say? "It must have been a lot of dialog, or something really polished!" Well sort of yes and no. Writing dialog means going back to the original book, re-writing whole chunks, adding other dialog that seems to fit in, working out how to turn it into choices, and testing.

It's really a big unknown. Does it result in a rich and deep experience where you feel you are talking to a real person? Or does it result in disjointed and repetitive nonsense where the user gets frustrated because there is no direction and any dialog-based puzzles appear to be random? We shall find out when it comes time for testing! Ideally I would have tone more time to play through it, change it, recompile, play it again, change it again, and so on. But even if I could do that without my eyes glazing over, playing one part without playing the rest can give a misleading impression.

So I think on balance, the most time effective solution is to just throw the dialog in at this stage, then do a "once through" test and revision at each stage, another "once through" test of the whole game, then rely on testers to give a truly objective view. The dialog won't be beautiful in May (late May = first full play through) but by November it should be up to the task. It better be! :)

This morning I add the "final" dialog to the emotional heart of the game: where Valjean changes his life. It includes probably the longest "cut scene" in the game: where the gendarmes bring in Valjean and the bishop says he gave Jean the silverware. That said, it's not particularly long, and the user can speed through most of it by right clicking. Cut scenes are necessary at crucial times (there is another one when Eponine dies), but I make them as short as possible since I don't like taking control away from the user. This is not to say the event itself is short, but I rework as much as possible into part of the puzzle, and only have the climax pre-scripted.

Now we're making progress! The main story has 29 parts, and the the first two are now complete. I've planned out parts 3 and 4 in some detail, and hopefully 3 will be fully coded (and maybe even tested) by the end of today. It's still early days and I'm still tweaking the generic puzzle engine, but I'm pretty confident that I should be averaging a new part complete every two or three days. Expect the next two months' blogs to be like "completed part 5"... "completed part 6"... though I might decide to take a few days off to address one of the later tasks (like adding crowds) . The great thing about being your own boss is the freedom!

Today's word is "linearity." Linearity in games means you have to go in a straight line, that is you have to do things int he exact same order every time you play. Linearity is rightly considered a Bad Thing, since it limits interactivity. The problem is, multiple paths take much longer to code than a linear game, because you have to think of every possible path that the user might take, and not just the preferred path. This issue dominated yesterday's work.

I have a certain time to finish this game, and if I put in more choices then the game becomes shorter. Let's say I have the time to code one thousand puzzles (actually that number is about right). And let's say each puzzle would take three minutes for a typical player to figure out. If I make the game linear, 1000 times 3 = 3000 minutes, or 50 hours. A long game. But if I go for complete non-linearity, then ten events could combine with another ten in 10 x 10 = 100 ways. Another ten could combine in 100 x 10 = 1000 ways. The user would have a lot more choices, but would only actually make 30 choices before the end of the game. So the game takes just as long to create (1000 possible events) but the user only sees 30 at any sitting, and the game is over in 30 x 3 minutes = one and a half hours, a very short game!

Obviously a game needs to strike some kind of balance. My feeling is that, for a story, more linear is probably best. First because the story only makes sense in a certain order, and second because uses just won't think of doing things in a really crazy order. A particular case came up yesterday. In order to achieve event 'C' the user must make choice 'A' and 'B.' It is pretty easy to code 'do A then do B then C will happen' but it takes much longer to write all the separate code just in case the user decides to do B first then A. And I cannot imagine that most users would even realize that they need to do B, there are clues, but it isn't obvious until they have done A. Sure, I could make it obvious, but it makes more sense from the story point of view to do A first. However, if they play the game again, next time they will think "oh yes, I need A and B, maybe I'll go and get B first." But is it worth the effort for such a small reward?

Of course, a well written linear puzzle is more fun than a badly written complex puzzle, and vice versa. Probably the best plan is to do it the easy way (i.e. linearly) for the first playable version, then add complexity later is testers say "this part is boring." Oh, and one other thing. Every stage will have some non-linear elements, so hopefully any linearity will not be obvious.

One final thing is that this should be seen in the context of the purpose of the game. Story implies direction. The real non-linearity of this game comes from three directions. First, in the long term, there will be many stories to choose from. Second, you can explore almost the entire game universe from the start. And third, you can discuss things with people, regardless of where you are in a particular story. So I'm not going to worry too much about the story being linear until I get feedback from users. In the final analysis, user opinions are the only opinions that count.

Busiest day ever yesterday - dawn til dusk typing! Well not actually dawn til dusk, but that's what it felt like. I budgeted for one day to enter the events for each part of the story, and one day to test. Most days won't be as long as this (I hope - I have a day job, and yesterday I was lucky to have a holiday), but I think it's worth putting in extra time to the first part, since that's where people will judge the game and decide if it's worth playing. If I'm running behind shedule by mid April I can make later stages a little simpler. I'll keep an eye on the calendar.

Of course, I may have just made the game impossibly hard? I'll find out when it goes for the first complete test in May. I don't expect the game to be fun right now, I just want it to be playable. The "fun to play" quotient should increase as I adapt and change it in response to user feedback over the summer.

I haven't uploaded the weekly screenshot yet, because I'm getting on well with coding the first part of the game again (recoding using the new streamlined code) and don't want to break my stride. I'll upload something tonight.

It's surprising how much goes into even a simple puzzle in a game. The first puzzle is relatively simple, you basically talk to a couple of people and combine a couple of objects. And the new code means I only need to define one event for each task. For example, "give object A to person X" is now just one action, instead of the previous ten or so (find the object, walk to the person, remove from inventory, say something, animate the movement, etc., etc.) Yet despite this, the foist part of the game has more than 30 different events. When you work it out logially on paper that makes sense, because ou have to always think "what if this happens" and "what if that hapens" and they all need seperate events. But still, it is quite surprising to see how much goes on behind the scenes for even the simplest event on screen.

Everything is progressing according to plan (see yesterday's post)

Trivia: I have two blogs. One (on land rent) is in deep freeze while I concentrate on the game. Every day I log onto Blogger and it tells me I have 210 entries on the land rent blog, while the Les Miserables blog has fewer... until today! 210 entries on both. Like it matters. :)

Good news on the puzzle code front. As far as I can tell all the unpleasant coding is done, so (fingers crossed) today I should be able to get part 2 of the story complete (where Valjean meets the bishop). Then tomorrow I will move back to part 1 (where we first meet Valjean), and change the clumsy and bloated old code into the neat and efficient new code. Then by Monday, on to part 3 (stealing the candlesticks). Next Wednesday part 4 (making Valjean's fortune), and so on, so the whole story (29 parts) is playable by the middle of May.

One more day working on the general purpose puzzle code. One more day. Hey, that would make a great title for a song. One more day...

It may sound like I'm spending inordinately long on this code, and you maybe think either (a) the code is something amazing, or (b) I'm not leaving long enough for the actual story (the clock is ticking!) but don't fret. The past few "days" have consisted of less than two hours each, due to day job and family commitments in the evenings. And the whole reason for the new code is so that the rest of development runs more smoothly (i.e. fewer silly bugs!). I have Friday through Tuesday off work, and expect to be running at full speed by the weekend.

Just a reminder of why the general purpose puzzle code is important:

The mains story has 29 parts. I started it about 3 weeks ago and set aside 3 days for each part. That way the story (in alpha version) is finished by late May. I completed most of the first 2 parts, but they took 4 days each. That was tolerable, since the first parts always take longer due to the learning curve. But 2 of every 4 days were spent tracking silly bugs, and that was no fun. It also presented the danger that the final game could have bugs I didn't spot. So I decided to spend up to a month in creating new general purpose puzzle code. That way, once the bugs are ironed out of that code, it can be reused again and again without new bugs appearing. So that will allow me to create each of the 29 parts in 2 days, not 4 (1 day for coding, 1 day for testing). It will also save time on other parts of the game and in future versions. So the alpha version is still on track for late May.

About alpha and beta versions:

Alpha version = first barely playable complete version. Expect it to be loaded with errors. Beta version = first version that might, in theory, be ready for the end user. But in practice beta versions need a lot of testing because users find things that the developer missed.

A reminder of the time line:

February: Early alpha: the game world and characters are playable, but not the story.

Late May: Late alpha: the full story is playable, but without some details (e.g. barricade animation) and without the secondary story (i.e. it gets boring if the user wanders away from France)

September: early beta: everything is there, but needs polishing, tweaking, testing, etc. teaser video created.

November: late beta. Review copies sent out.

1st December: game is ready to upload. Final final testing and promotion, to ensure that everything works smoothly on release date (15th December)

Not much to add, except I've been planning how to make the 'database' load faster for version 2.

Another wading-through-treacle programming day. On days like this I remind myself of why I am doing this. Remmeber the vision, the whole point. Not just to make a game based on Les Miserables. if that was my only goal then I would not be writing all this customized code. If I only wanted a Les Ms game then I would use the standard code that comes with the game engne, and I would use unaltered photographs (they look nicer and involve less work). But instead I am writing all this customized code to automate stuff like backgrounds and puzzles etc. Yet I am not a great programmer. So why am I doing it? Because I have this vision, this dream.

When the code is done and I have some practice in using it, I will be able to add new stories quickly and easily. Long term, after a few years of this, I hope to be able to add a simple story in just two months. Then the game will get bigger and bigger, deeper and deeper, more involved, more incredible, just bursing with every amazing idea I have ever found. That will take a long time. Years! I may mess up several times along the way. But I will keep working at it, keep on refining and learning frommy mistakes. This is something I really want to do. And if it means I must write a lot of behind-the-scenes code then so be it. I have a dream, and I'm going to make it happen, however long it takes.

On a brighter note (programming wise) I just realized tat the new code, if necessary, will allow me to dramatically reduce the number of sub-functions. This probably means nothing to anyone else, but it is important to my long term plans. Sorry for all the technical talk!

If there was an award for stupidest programmer in the world then I would have won it yesterday! I spent half the day trying to track down a bug. You remember how the puzzles are based on a master database which then creates a smaller database which is then examined in detail to create the action on screen? Well I just could not get this one puzzle to work. For hour after hour I tweaked it, changed settings, recompiled, tested, and no matter what I did the darned thing WOULD NOT WORK! I couldn't see anything wrong with the code, yet it refused to show up in the game. Finally, after nearly a whole day, it was 11pm at night and I was lying in bed waiting for it to compile for the twentieth time, and suddenly it hit me: I had spent so long designing the code that I had forgotten the simplest art: the one line at the end that said "now enter this puzzle into the database." It was never in the database to begin with and that is why the game could not find it! D'oh! So I added it and now it works. Promise you won't tell anyone, OK?

Spent yesterday tracking down a single bug in the new puzzle code. Oh such fun. Nobody will be interested in this, but I'll tell you about it anyway.

This will give you a flavor of why I don't like bug tracking, and why I think it is worth taking a week off the tight schedule to write the general purpose puzzle code, so that I will save time later on. One week of frustration now equals months (and years) of plain sailing later.

This is a typical bug, the one that stumped me yesterday: The core of the general purpose puzzle code is two lists of puzzles (arrays or stacks, for the programming minded). On startup, the game creates a master list of all puzzles. Then when you do enter a room or use something, it quickly creates a second list of all the puzzles that might match, and that list is then examined closely. But the code refused to work. yet it looked perfect on paper. After much head scratching I realized that, when the code reads and copied the two lists, sometimes it started at the beginning of the list and worked forwards, and sometimes it starts at the end and worked backwards. Add the fact that most of the elements in the list are numbers, and the first list element is essentially junk and is later deleted, and you can see that a tiny mistake (reading backwards instead of forwards) can result in all kinds of strange and hard to track down results. But anyway, I did finally track down what was happening, fixed it, and today I continue adding more puzzle types.

So far the code only handles simple "have something in the room" or "pick up something" type puzzles. Now I will progress to "combine objects" and "talk to someone until they say the right thing" type puzzles. This may not sound like much, but until now each one meant creating brand new code, new sub-functions, testing, bug tracking, and so on. No fun. But from now, these things are as simple to add as they are to describe. Which means, when the code is fully tested and working smoothly (around the middle of this week) I will be able to steam ahead, adding more and more puzzles every day, adding five or ten puzzles a day instead of the current rate of one or two.

Still plugging away at the general purpose puzzle code. I find this kind of raw coding to be tedious (I'm not an expert programmer!), but it will be worth it, to speed up the rest of the work.

Still working on the general purpose puzzle code. Each event has up to 415 different variables! That's programming for you.

Yesterday was spent adding clouds to the sky (I like clouds!) and in creating the general purpose puzzle code. It might take until the end of this week to get that code working properly, but it will be worth it in time saved. And in making development more fun. Adding puzzles is fun, but spending days in tracking down bugs is not! :)