Today I'm adding the "combination" monologs. That is, when you draw a character's attention to something and they respond. The equivalent of "look at" or "use." Sometimes this leads the story forwards, but most of the time if you click on "characters" and "tree" or "character" and "dog" then they give some other response. Making the response convincing and interesting is not easy, but it's essential if I want this game to feel like it has genuine freedom. Basically the gameplay is the freedom to draw anyone's attention to anything.
.
I added up all the characters and objects in the game, and the total is over 700. And you don't want people saying the same thing every time, so each of these has up to six different responses. 700 x6 = OVER FOUR THOUSAND pieces of dialog to write. And each piece needs to be interesting, applicable to every possible person who might say it, AND in keeping with Victor Hugo's Les Miserables. And worst, you cannot even guarantee that the character is on the same screen, so they can't just say "I'm looking at X," you have to think of what they would say (or do) if the idea of X just crossed their mind for no apparent reason.
.
I think this may take slightly longer than the one day I originally allotted for the task. Particularly since I spent the morning doing Dad's Taxi Service, and as I write, my other daughter has just asked me to help her clean out our (rather large) gerbil home.

Making good progress. More details tomorrow. (Nothing particularly interesting, just "more details") :)

Solved the import problem (actually I begged for help on the AGS board... I'm not too proud to beg!). Now I'm continuing to tidy up the code, according to my time honored habit of doing everything at least three times. The intro sequence has always botherd me - it works perfectly, but the underlying code was very messy, so bugs were inevitable. Now I've managed to simplify it and it looks a lot nicer. Instead of being a whole module on its own, full of mysterious, subclauses, and code that appears nowhere else, the intro is now a simple cuscene like everything else.
.
I am not a natural programmer (you mean you noticed?) so I try to make all my code as simple as possible, then go over it again to make it even simpler. It still ends up looking messy compared with what a REAL programmer could produce (i.e. someone who programs professionally and has always enjoyed hacking around), but at least it enables me to spend time concentrating on the stuff that matters - the story. Or at least it WILL do when I've got the last little bits of code in place. I'm constantly rewriting it as I add more story elements, because it's impossible to know what really works until it's finished.

I thought I'd upload an image of the game in production for a change (Adventure Game Studio 2.72 in use).
.
Today I've been wrestling with an "unresolved import" code problem, hence the delay in blogging.

The new new code is starting to look nice. It almost doesn't look like code at all, which is a good sign. With extensive use of strings it can be created and maintained in a far more natural (and hence fast and reliable) way than before. I was going to post some examples here, but it's taken me so long to develop (and it's actually quite simple as I said) that it's kind of my commercial secret weapon. :)
.
This way of coding is what gives me great confidence about this project. Obviously I hope that from day one hundreds or thousands of people will want to buy this game, but I've spent a long time on independent game maker web sites, and the hard facts are that independent games often sell in single figures. If that happens to this one then it won't matter too much because, thanks to the rapid development method I've developed, I will be able to quickly learn from my mistakes and have an even better sequel in production. Of course the reality is likely to be in between the extremes: the game will be neither an overnight hit nor a complete dud. But I have to plan for both eventualities.

Let's talk beta testing. I was originally planning to release an early beta in early April, when the game should be playable all the way through but without much dialog. But the gameplay relies heavily on the richness of the book's dialog. Without that dialog it's pretty shallow - like a shooting game where you can't shoot anything, or a racing game without the racing. I have April pencilled in for adding the dialog, so the beta is likely to be out in May. Originally that would be "first week in May" but to be realistic, everything takes longer than planned so middle of May is more likely.
.
I plan to send it to only about three or four people, because everyone will have their own views about what it needs, and I could very easily spend YEARS trying to please everyone. I plan to just spend a month making whatever changes reviewers insist on, then have a final test version in late June. And if nothing else comes up, release it in the first week of July. Yes, "if nothing else comes up." Forgive me for laughing.
.
As for current development, I decided to make some changes in how the game is coded, and I'm pretty excited about these. The might add a couple of days (maybe even a week) to the development time, but will make future stories much easier to and more enjoyable to code.
.
This is a continuation of my efforts to translate a novel into a game in the shortest possible time. I mentioned a few days ago that I already have the code in a state where I can pretty much go through a novel and type "puzzle = this" and "clue = that" but even that required a great deal of thought. I've now worked out an even better, even faster, even more elegant way to code the story. It does not mean a complete re-write, but merely a reworking of existing code so that it all makes more sense. This will add a few days to the schedule, but in the long run will save a lot of time (and allow for a better gameplay experience).

The game is currently at the stage where the entire story can be followed on one very long page (in code at least - I haven't had the courage to test it yet!). Yesterday was spent refining the clue code. I spend a lot of time refining code to make it prettier, neater, easier to read and follow. This may sound cosmetic, but it is absolutely essential in something as complex this. If the code is hard to follow then it's eaven harder to write, and bugs will arise everywhere. If those bugs are not spotted at coding time then it's very, very hard to fix them retroactively.
.
What I mean is, if you're playing the game and a character says something that makes no sense (or you seem to be stuck in some puzzle without any clues) it's because the developer (me) did not foresee the exact chain of events that would cause the problem. So I'd have to (1) work out exactly what went wrong, (2) trace all the steps in code , and (3) make changes to ensure it doesn't happen again. It is totally unfeasible to write special code for every possible circumstance, so the only possible way to make a game work is of the generic code is easy to follow, and has some kind of elegant logic to it. Preferably a logic that closely matches the common sense logic expected by the user. That way, mistakes can be avoided naturally, because weird or stupid things will just not be coded, and sensible things will arise naturally.
.
For example, if a given segment of the game has six puzzles, it makes sense to arrange them in code in the same order that the usaer is likely to find them. And it makes sense to arrange for six clues, and six generic conversations that take place while those puzzles have not been solved. And the code had better be written so as to hide anything that can be automated. For example, this line:
.
clue(1,"this is the clue for puzzle 1")
.
is much easier to write than this line:
.
(if(player.Room ==36)&&(Global.Get("noWaiting")>0)&&(GetGlobalInt(400)==n)){if(GetGlobalInt(23)<=0)&&(getEvent(n,1))&&(character[i].Room ==player.Room)){if((getEvent(n,2)==false)&&(GetGlobalInt(23)<=0)){player.Walk(character[i].x,character[i].y); int companion = getFriend(i); character[i].Say("this is the clue"); character[companion].Say("I know.");SetGlobalInt(23,1);}}}}
.
The actual code would be even more complicated than that, but that's pretty close to what is needed. Remember that a typical stage in the game would have at least ten lines like that, and probably more like forty. And a single error anywhere would lead to the game not working properly. More important, the game would be too hard to code so there would be no time left to polish it and make it fun. Anyway, that's why I spend so long on getting the code looking right, and that's why I am confident that future games will be much quicker to create because all that hard thinking will have already been done, and in future I can just plug characters and clues into a proven template.

Still working!

This morning I'm working on the code that lets Valjean follow your mouse when in the "night escape" and "sewer" sections of the game. But he must not follow if there are police nearby. And sometimes Cosette follows him. And sometimes his needs a smaller than usual sprite (for long-distance shots). And sometimes he needs to carry Marius. Nothing is ever simple!
.
But I still hope to have all the puzzle code cleaned up by tonight. Then tomorrow I work on adding the clues (what peole say when you click on them). By Wednesday all the "if then" conditions should be in place, and I hope to have the game playable by next Sunday. Then April will be spent adding authentic (or nearly authentic) Les Miserables dialog.
.
Oh, and Happy Easter!

Short post today. Still working away!

At last! I've finally got the code working in a way that's easy to write. I already added all the puzzles (in the crudest, full of bugs way) but the code was becoming unmanageably complicated. So I've worked out some different functions that allow me to add puzzles, clues, cutscenes, etc., in an intuitive way. Hoorah! Coding is the most satisfying thing on earth when it works smoothly, as you are basically playing God. But coding is also the most infernal frustration when it doesn't work - think Tantalus and Sysiphus. So I'm very pleased that the new code is starting to act like my servant and not my master.
.
The key to all this coding goodness is DeNGVaT. DeNGaT is an extremely useful AGS (Adventure Game Studio) module, designed for Debugging, Named Global Variables, and Timers (hence the name De-NGV-aT). I only use it for named global variables, and it is a lifesaver.
.
Long time readers may recall that a big difference between AGS and Sludge (my previous game engine) is that AGS is room based and Sludge is not. Put simply, if you do something in AGS, it only applies to the room you're in. Which is really helpful if you want to avoid bugs. For example, in Sludge I would add random strangers in one room and they'd accidentally appear in another room. It was obviously a fault in my code somewhere, but I'd have to track down every possible effect of all the code in the entire game to see how it happened. Even the smallest bug took ages to nail, and nailing it usually created three new bugs. .That kind of inter-room problem can't happen in AGS. AGS rooms are like "Fight Club." Anything that happens in one room STAYS in that room.
.
But AGS rooms have a BIG down side. In a game you often want to do something in one room and refer to it in another room. This is easy in Sludge (Sludge does not know what "a room" is, so just write whatever code you want). But in AGS each room does not know that another room exists. Let's say for example you want a cut-scene that starts in one room, briefly moves to another room for a few seconds then moves back. In Sludge you would just say "this code means 'a room,' so load 1 room, load another, then load the first again." But in AGS when you leave one room all functions stop running. It is like you just forget EVERYTHING. The code has to be written to start everything from scratch in every room, and give the illusion that there is some kind of continuity. Have you ever seen the movie "Fifty First Dates"? (it starred Drew Barrymore I think?) It was about someone who can never remember the previous day so has to learn everything again each morning? AGS is like that. .Well obviously there are SOME ways to get information from one room to another, but it ain't easy.
.
You see, AGS is not really designed for long complex stories. It's designed for relatively simple stories that are based on wandering around a small number of locations picking up objects. The only truly flexible tool you have is an array of 500 global integers, so you can write code that says "if global integer number 500 = 1 then we have not been in room A yet." Pretty awkward, eh?.
.
Anyway, the point is that DeNGVaT solves the problem. It does some magic hocus pocus and provides a way to create and read global variables. And give them sensible names. And not worry about importing, exporting, or other tricks. it just works. So it doesn't matter wherever you are, you can always remember stuff and use it. As a developer you still need to think how to write the code, but at least common sense now prevails. It's like having big windows between all the rooms, so the story can flow freely. it's kind of hard to explain in more detail without spending days on giving examples, but programmers will know what I mean.
.
Global variables == good for stories.

Minor revision to how the games will be released
.
A few months ago I stated my plan to have version 2 replace version 1, and contain both "Les Miserables" and "War and Peace." The subsequent games would be one download each. And there would be a separate "library" mini-game as a front end to the others. I've given this some more thought, and I think there is a simpler way to do it:
.
Each game will be self contained, but also link seamlessly to all the others. Right from the start. I think a separate front-end is needlessly complicated, and the games are too big to comfortably develop two in one file. (I may add a front end anyway at some point, but it will be optional.)
.
As a result, version 1 (Les Miserables) will contain several links to several games that have not yet been made. Right now those links will just result in some message like "that story wasn't ready when the Les Miserables game was released - visit EnterTheStory.com to see if it's available now." When that story becomes available, just download it to the same folder and you will magically be able to walk to the new location. At least I'm pretty sure that will work. I'll have to test it of course.

There are three reasons for doing it this way. First, so people never have to download the same stuff twice. Second, to let the user see the big vision, that one day this game world will be enormous! And third, as an anti-piracy measure. Whenever someone plays the game they get gentle reminders that EnterTheStory.com is the place to go. And NOT the pirate bay or any other source :)

Still working...
.
BTW this little graphic is actually quite a good likeness of me (I couldn't find a source image I liked, so got out the camera). Exaggerated for comic effect of course. It looks even MORE like my little brother, but don't tell him I said that. :)

Instead of finishing another 2 plot points, I half finished 12. And discovered that I forgot to create sprites for Aunt Gillenormand, Mme Magloire, or the two little boys! That's now fixed. I particularly like the two little boys (left).
.
By tomorrow I should have the barest alpha version of the game complete. That is, if there are no bugs it will be possible to click from the beginning of the story right through to the end. Of course there WILL be bugs, and I still need to add clues, dialog, details for all the minor cut scenes, etc., etc. but progress IS being made.

Yesterday I finished coding the first two plot points (the intro sequence and defeating Napoleon). It took much longer than I HOPED but about as long as I EXPECTED. Since I'm always hopelessly optimistic about these things and I know it! :) By "completed" I mean it is technically playable, but it still needs the serious dialog added - right now the characters just say the minimum necessary to show that it works. Next month I'll go through and add more appropriate words based on the text of Les Miserables. I also expect to have to refine and change details to make it more fun, but that's scheduled for the beta testing in May.
.
Today I expect to get another two plot points coded (getting Valjean out of jail, and installing Myriel as bishop). By that time I expect to get faster at coding these, so by the end of the month I should be adding three plot points a day. I hope. But of course, some days I spend more time at my day job and with the family. So realistically the game will probably be playable by the end of the first week in April.
.
The latest schedule then: first week in April: the game is playable but no fun. First week in May: the game has more text from the novel, and is ready for beta testing. First week in June: the earliest date when the game might actually be on sale. First week in July: a more realistic date! On 4th July 2008 I turn 40 years old. I would very much like to have the game out the door by then, and be busy working on the next version. It would be fantastic if I could get War and Peace out by the end of this year, if possible.

Just added a new conversation module to the game, as the code was getting cluttered. It won't look any different to the user, but it makes the coding easier, and therefore faster to write, and with fewer bugs.
.
Not much else to report. Still plugging away!

Today I'm adding the outlines for the cut-scenes. I'll add the detailed content later. There are around 200 cut-scenes in the game, mostly simple stuff like talking. The very complicated cutscenes are already done (such as the rigging, barricade and fire animations seen in the teaser video).
.
Even the simplest cutscene has to be reworked two or three times so that it looks right. It takes a whole day to add the outlines for all 200, and it will probably take a week to define what happens in each one. Then another week (in April) to add the proper dialog, after re-reading Les Miserables again, to remember how Victor Hugo did it. And another week (in May) to refine them based on beta test comments.

Still refining the main script. I had expected to go through it one plot point at a time (there are 33 plot points in the game) but I'm finding it makes more sense to go through everything, again and again, refining it more each time.
.
The exciting thing about this (from my point of view) is that I'm refining the code used to create the actual story, making it easier for me to understand and write. What I'm doing today is, in effect, creating a gaming language that enables novels to be translated into games very easily. Although Les Miserables has taken me years of experimentation, future stories will take just months. After a few years I hope to be so familiar with the code that I can translate a story into a game in one go, without the usual process of creating a rough plan, then a detailed plan, then pseudo code, etc.
.
One other point, and this is significant from a game-play point of view: there are now a few more automatic scene changes than previously.
.
This happens in two situations. First, if you combine a character with an object, if that object is in another scene, then you immediately switch back to the original person to get their response. The other way is in cut-scenes. If a cut-scene makes sense to happen over three different rooms, then I just switch rooms as needed. The metaphor for this game (its look and feel) has always been a book, and I figure that people who read books are quite comfortable with switching scenes as needed. Also, since there is no avatar walking about, the user will be used to rapidly switching scenes so I don't think game-driven scene switches will be a problem.

Coding is progressing smoothly. Or as smoothly as it ever does -spent two hours yesterday in simplifying the intro code, creating a new bug, tracking it down, so the result looks exactly the same as before, but as the guy who coded it I feel happier with it.
.
I occasionally have weird dreams about trying to do incredibly ambitious and stupid things that cannot possible work. Last night I dreamed that I was in Jules Verne's "Around the World in Eighty Days." Except in my dream Phileas Fogg was being chased around the world by two policemen... and I was chasing them all, trying to get there first. And all I had was a unicycle (without gears), an imitation iPod with a fading battery, no money, and I was dressed in shorts. And this was in the 1800s , so the roads were terrible and there were no street lights. After pedaling for hours in the dark and making maybe twenty miles, I began to realize that maybe this was not realistic. But I kept on pedaling anyway, hoping it wouldn't rain, and I would somehow get round the world in eighty days at 20 miles an hour with no food.
.
Please don't read too much into these dreams, I am sure they are totally random and nothing to do with making this game. :) :)

Not much to report today except that work is progressing nicely. Every day I get more confident that this thing will be completed on time. Within a few days I should have coded enough of the story to have a much better idea of when it will be compete.

Adventure Game Studio is amazing! And not just the software, but the community that supports it! Yesterday I spent several hours trying to fix a bug in the conversation code. I finally narrowed it down to something in a module written by someone else. So I posted the problem on one of the AGS forums. And within minutes, MINUTES, the author of the module had seen the message, looked at his code, found the problem, and uploaded a new improved version of the module.
.
You would NEVER get that kind of quality and servuice with commercial software. I am just amazed.

I'm happy to report that the characters are all merrily talking, and the game is starting to look like a... well, like a game. Instead of a series of pictures and animations. It still needs plenty of work, but it's getting there.

The end is within sight! With the puzzle and conversation code taking its final form I can at last look forward and see how this is going to be completed, without the vague "black hole" scheduling unknowns. The current schedule looks like this:
.
Today: finish tidying the puzzle and conversation code.
.
Tomorrow: add the first working plot point.
.
End of March: finish adding all lot points (two per day)
.
April: re-read Les Miserables, adding in the actual conversation strings, to make the game as much like the book as possible.
.
May: test, test, refine and test again.
.
June: release, and start work on War and Peace.

Today I'm adding the final (!) conversation code. With this it should be possible to reach the Holy Grail of game development, for me at least: the ability to hold a novel in one hand, read it page by page, and with the other hand on a keyboard, transform it into a game in real time, page by page.
.
OK, that is maybe a slight simplification, but rapid game creation has always been the goal. The strength of tghis game, as I have said many, many times, is that it will be ful of many, many classic stories. Not just one. And all the slow progress of the last seven years has been an effort to find the perfect template for that goal.
.
Conversations were the last major unknown of the development process. With these solved the remaining coding jobs should be easy. (Excuse me while I stop laughing cynically... :)

Instead of coding the first puzzle I went back and streamlined the underlying puzzle code. Warning: technical stuff ahead!
.
Adventure Game Studio only allows 500 global integers. In other words, you can only have 500 numbers that can be used by every scene of the game. (Actually this number can be increased by creating and exporting individual variables, or by creating structs, but both are fiddly and increase the chance of later bugs.) These 500 ints are needed for anything that may be referenced in more than one room: stages in the game, the behaviors of characters who might move between rooms, temporary variables for functions used in different rooms, variables shared between different games, and so on. Those 500 are used up very quickly. So I had allocated just 50 global ints to the story, mostly record of whether the major plot points were complete of not. However, each plot point could refer to up to ten or more actions from the user, and these individual actions would not have been recorded permanently. As I finished the final design, it became obvious that this would either become very complicated, or (if I kept it simple) very restrictive. So I rearranged the global ints to allocate 180 ints to recording decisions made by the user. Then I re-wrote the design in a streamlined way that takes advantage of the new method.
.
What this means to the end user is two things. First, the entire game can be completed by making less than 180 decisions (though each decision may include several mouse clicks). But more important, many (perhaps most) of these decisions can be made at any time, so the game does not feel too linear. Previously I had to restrict what the user could do, because the game could not remember or cope with every possible combination of actions.
.
Linearity is a very big issue with a game like this. Linearity means the game just goes in one direction. Too much linearity feels boring, like you have no choices. But if there are too many choices then the game becomes impossibly complex to design, and the story disappears (because users are free to do stuff in the wrong order, so Victor Hugo's the story would make no sense) and the risk of bugs and stupid stuff increases. But the new design hopefully solves the problem: the story still goes in one direction (as specified by Victor Hugo), but the user can now make decisions at any point, in any order, so they have the feeling of freedom. And equally important from my point of view, it makes coding the thing easier.

That is the final(?) revised design finished, in the new style (no visible avatar, simplified puzzle system). I think it works better than before, for three reasons. First, the simplified puzzle system puts all the emphasis on thoughts and feelings. Second, with no visible avatar there is no distraction from the characters and events of the book itself. Third, this is relatively quick to produce or will be for the next story). The plan is coming together...

That's all the people in all the scenes. The scenes now look like they will in the final game. I should really post some new screenshots, but right now it's more important to continue redesigning the story.
.
Every little change like adding more people, changes the dynamics of the game. A puzzle that makes sense with an empty scene does not make sense if there are people nearby. A puzzle that makes sense with an avatar does not make sense with no avatar. And so on.

I just noticed - there are now well over two hundred characters in this game! (Forty of them are random strangers who wander around in the distance, another forty are strangers you see close up, twenty are objects that are saved as characters for technical reasons, ten of the characters have two or more versions, etc.)

.

Gotta go!

I really like some of the characters I've been adding recently. They don't do much yet, but they look nice. At least I think so. This is the kind of game I'd like to play - I'm not saying it will be right for everyone.
.
Also I wasted over an hour on one characcter that I finally had to dump. I took ages on the face, it was a two year old kid, but it just ended up looking creepy. I won't post it here because anyone who glances at the site might think I like that pic, or might make suggestions for imporving it. I can't waste any more time on it - too many others to do!

Just for a change, another sprite. Yesterday I was putting the permanent people into their positions (the archivist is in the archive, the shopkeeper is in the shop, etc.) and realised that I need more bystanders. I like to have scenes that are full of people. So I set about making a few more, and may post some here over the next few days.
.
Slowly but surely this project is coming together, starting to take on its final form. It won't be like any other game that I know of, and I don't expect many people to buy the first version, but I have always seen this as a long term project that will build and build. These new bystanders are an important part of that. The core of this project, the foundation, its unique strength, its business secret, is a method of rapidly turning a classic novel into a game. Having a library of bystanders is part of that.
.
The biggest surprise to me, in making this game, is how long the learning curve has taken. Each story will represent six months of unique work, but the first version has taken an extra SEVEN YEARS of trying different ways to get the long term method right. Seven years! That is, I started in 2000, yet the first released game will not reflect that - it will look quite modest. The real strength of the game comes as more and mroe stories are added. This is gonna be big! Long term.