Team Blog

There’s been some time since the last news from me, so I decided to tell you what I am doing right now, and why it takes so long, so you won’t lose hope :).

I’m now working on a feature that will help the overall development of the LBA world areas. It is an automatic Fragment management in Designer (if you don’t know, it is a program that allows ‘compilation’ of separate Grid, Scene and Scenario files into HQR files that can be read by the game engine). This is how the game works: the lba_gri.hqr file contains Grids (which define terrain look and shape) and Framgents. Fragments are small parts of Grids (they have exactly the same format in LBA 1) that can be merged with a base Grid to change (replace) a specific area of it. For example the basement ceiling that disappears when Twinsen enters the north door in his house has been made with the Fragment feature (the Fragment contains transparent cells replacing the ceiling and nice egdes replacing the walls). Fragments are placed in the lba_grid.hqr at specified index, and they are referenced by their index relative to the first Fragment. It means that all Fragments that are going to be used in the game should be planned before starting work on the Grids, because later if you decide not use one of the Fragments it will have to be marked as ‘empty’ (blank entry in the HQR). It can’t be deleted, because this will change indexes of the Fragments above the deleted one (so indexes in the Scene will point to wrong Fragments). It is not much bothering, but can lead to many mistakes and problems.

The idea for the feature I am working on now is simple: reference Fragments by their names instead of indexes. If you want to use a Fragment in a Grid, add it to the Scenario (it will get automatic name, like ‘Framgent_1″, that can’t be changed yet), and use its name in the Script and in the Zones of type 3 (they automatically trigger Fragment replacing when player enters inside). Architect will add information about which Fragment is associated with which place in the Scene to the Scenario, and when you use that Scenario in Designer, it will automatically add all necessary Fragments and put their final indexes to the Scene. This will eliminate the need for manual creation and planning around the Fragments.

And now why it is taking so long: apparently this is much harder to make than I expected. the Builder part is finished (but not tested, so it may contain bugs), and I am now starting to implement it in Designer.

The second reason for the delay is the real life :). I am involved socially much more now than before, and therefore I have less time to work on this.

I hope this year will bring some more interesting developments in the Prequel :).

The following issues have been resoved now:

• The main menu items for Fragment support. Specifically: opening Grids as Fragments (intended for use with the original LBA 2 Fragments which are in the same format as regular Grids), copying selection to a new Fragment, closing the current Fragment and closing everything - it restores the program to state like it have been just started.
• Popup menu items for selection: Selecting everything, deleting the selection, and the meaning of “Copy sel. to…” and “Copy sel. the a new Fragment” have been changed. Now they don’t copy the selection, but move it, deleting the selected part from the original. This change was necessary, because I realized that there were no way of doing it with the options working as “copy”. This was because the selection is cleared while switching Fragments. Of course there is a possibility to copy instead of move by pressing Ctrl.
• All opening ways are now working for both regular Grids and Fragments,
• I have fixed some bugs,
• And I have added list of recently used Scenarios to the File menu for quicker opening. You will probably get an impression that Scenarios are something like “projects” in other software - this is a good association, and in fact I’m aiming to make them as comfortable to use as I can.

You probably wonder why these little things took me so long. This have been caused by two reasons:

1. I have less time recently. I can work on Architect only once per couple of days, and not for long each time.
2. When implementing these things I have found many bugs and inconsistencies that I just couldn’t leave that way. For example the selection moving feature didn’t allow for putting the selected area below [0, 0, 0] position, so for example when choosing Select All and trying to reposition the contents one couldn’t move the stuff “back” so a part of it would be off the rear wall. Even if there was some empty space between the contents and the rear wall - this in turn is caused by the fact that empty areas are also selected with Select All function (yes, it really selects [B]all[/B]). Another thing was a bug that caused normal blocks being cut out while playing aroud with invisible blocks. There were some more, that I don’t remember, and that took me quite much time to fix.

Not much to show this time: just a screenshot of the File menu after changes. It’s getting quite big already.

I have just finished fixing the modified/saving system. Unless it is bugged I shouldn’t have reasons to touch it any more.
Remember the dialog that popped up when closing Architect with unsaved files?

I have modified it to be more user-friendly and also informative. It now looks like this:

As I promised, I will from now on post information on the Architect progress. In the recent comment to the previous article I said that Link would be supposed to post his progress infos too, but I forgot that Link was not in the Prequel team, thus he couldn’t do that :). However he will be posting progress on the MBN in this thread.

Here we go:
1.0.0 beta 6 - (Released) major changes:

• [Feature] Actor templates - you can now save an actor as a template, and then put it as many times as you want into the same or another Scene. References to the Actor inside its Scripts are maintained through the new SELF keyword, which, during compilation, will be replaced with the ID of the Actor, that the script belongs to.
• [Feature] Textual LABEL names (by LBAWinOwns) - it is now possible to use textual names for the Track Script LABEL commands and reference them by these names in all other places (including Life Script).
• Checking for broken Brick data has been added to both Builder and Factory. Factory shows list of indexes of broken bricks for easy repair.
• And many bug fixes.

Download: Primary server, Mirror [1.7MB]

1.0.0 beta 7 - (in development) major changes so far:

• [Bug] Builder crashes when using “select by layout” tool - resolved.
• [Feature] It turned out that there was no easy way to make disappearing ceilings in LBA1, because the game crashed when trying to use such ceiling. The reason for that is the “Layout usage list” - a list contained in each Grid, that tells the game which Layouts from the Library the Grid is using, so the game engine doesn’t have to load the remaining ones into memory. When trying to put a disappearing ceiling the used one of the “unused” Layouts the game displayed a wrong Layout, and sometimes crashed. This gave me an idea to make an option for filling the Layout usage list for Gird with all possible Layouts, so the game will always load them all, and this problem would be solved. I was wrong. The game then crashed every time, because it probably has some maximum amount of memory reserved for the Layouts, which has been computed from all the Grids (by checking which Grid used the most memory for Layouts) and hard-coded into the engine (in LBA 2 that value is stored in lab_bkg.hqr file), so Grids can’t use all Layouts from a Library, simply because they won’t fit into the limited amount of memory and the game will crash. This led me to another idea of an option to allow users to manually edit the Layout usage list for each Grid, especially to allow adding other Layouts to the list, but I don’t like this due to couple of reasons. Main reason is that users would have to manually edit this every time they start editing a Grid. Not a pleasant thing.
  So finally I have come to this: I’m gonna make the disappearing ceilings (called Fragments, but they are regular Grids in LBA 1 (in LBA 2 they have different format)) editing “incorporated” with the main Grid editing. All Grids and Fragments related with each other will be opened in the program at the same time, so the program will know exactly what Layouts should be put into the usage list so that everything will run smooth. Currently the multi-Grid system is working in Builder; things that need to be adjusted to be compatible with it: opening and saving system, selection and copying between Grids. Screenshots will tell you more.
• Scenario (*.HQS) file format have been changed in order to be able to keep any number of additional Fragments inside. Architect versions prior to beta 7 will bot be able to open Scnearios created with beta 7 and above. Factory and Stage Designer still need to be adjusted for compatibility.

Planned Beta 7 release: about two months from now (all the dates are likely to be changed in both ways).

I’m sure most of you are wondering about “what the heck is going on?” and “is this thing dead already, but noone is honest enough to admit that?”

Well, NO.

The recent absence of news has been caused by discussions among us about the future of this project. Now the discussions are almost done. No final decisions have been made, but we have come to a kind of compromise, that was necessary to continue the Prequel. Believe me or not, compromise is a good thing in current situation.

You know that the Prequel from the beginning was planned to be made with use of the original engine (LBAWin) or our custom engine (codename: Prequengine) that would be very similar to LBAWin, but would allow us to add some modifications (e.g. use of better quality sounds). Some time ago (can’t even remember when it was) some of us came out with an idea to, as we were writing our own engine already, make the engine use more detailed environments and object models. This was to be achieved by use of a ready-made graphics engine, such as OGRE (that’s why I asked once in a comment if GeForce2 would be a reasonable minimal requirement). RobG had become the leader of the engine project, as he already had some experience in OGRE programming, and he presented us some astonishing results of his early tests. Also the new engine would make the game development easier, because:

• it would use different object model format, which is suported by many professional modelling tools (including freewares),
• it would allow for higher quality sounds and voices (which means no struggle to make the LBA 1 format sound decent),
• it would allow for better quality movie clips.

But then after few months he just stopped responding and none of us knows what is going on with him. Unfortunately the Prequengine leader, alexfont, doesn’t have time any more to work on the engine, so we can’t currently foresight when and if we will ever have any custom engine.

This have led us to rethink our priorities, and we were forced to make the decision to stick with LBAWin for now, and in the future, if there are chances of getting a better engine, we will try to switch to it.

But this has consequences, from which the most important one is that we don’t have any 3D modelling tool that is easy to use (even vaguely resembling the industry standards), which means we have to write one or make a converter from more common standards.

As I am writing this I have information that someone is working on a modelling tool for LBA format. I just have released the LBArchitect beta 6, which is almost sufficient for us, and now I will try to write a converter between the 3D object formats (this is not as easy at it seems). I think it can be made faster than an editor, and I hope this will enable the work on Prequel going on again.

Before I had plans to start another engine project (I can’t help much with the other engine projects, because they are being written in C/C++, and I’m mainly skilled in Delphi), but as we have decided to use LBAWin for now, I will do the thing that is more needed for now. But I still keep the engine in mind and maybe one day I will return to the idea.

I hope that cleared up the things a bit, and that you haven’t lost interest yet

In case you didn’t notice, the MBN is down, and we’re not exactly sure what the issue is. Until we hear something, we know about as much as everyone else does.

Drummerbummer67 suggested to create a new post about the engine we are building and I’ll clarify better all the things and also give you some input about the engine status.

Currently, to make progress in game demo we are using LbaWin as our main engine at the moment. This is port of the original engine for Windows created by Sébastien Viannay, an old member of Adeline International Software, the team behind LBA. The current status of this engine is very mature and stable due to years of beta testing by all the fans. This version used and improved the original source code of the engine.

During the project, we found some pending issues that would make Prequel game with less quality than what we expected, for example in terms of audio, video and portability since LbaWin was only for Windows and was using the original file formats. So this make us think we should have our own engine. By own engine I mean, creating a new one like the original, and not make a remake with the new 3D engines we have now-a-days.

We first thought about using TwinEngine project, also a reimplementation project of LBA, as our engine but the code was a bit desorganized to improve it and to include the features we want to add. Than, we thought it will be better creating a new engine based in TwinEngine source code and  reverse enginneer of the original engine.

So we create Prequengine opened to public as a side project. With it we hoped to get some external help from LBA fans but it didn’t happen. Only 2 people came to us to give help, not for coding the engine itself unfortunatily, but to help in other terms of code and porting. This make me start the engine by myself in May this year and put effort on it alone even knowing I won’t be able to work everytime in the engine since I need to make progress in the game demo, thats why we are sticking yet with LbaWin.

After this 5 months some resonable work was done, but I must say the engine is only more-or-less 15% accomplish due to working on it alone. In the past days, I’ve been working in 3D renderer engine which is the key in this project but I’m still getting some huge troubles getting it work. I can only render yet some parts of models and hope find and fix the bugs in the next weeks.  Doing it, I’ll be able to continue the engine faster giving the engines life, by making model animations and script execution.

Here’s the list of things we already did in the engine:

• Keyboard handle.
• Main menu working with Fire Effetcs and user can browse throw the buttons. Can also change volume settings.
• Play theme music while in main menu.
• Support to play MP3/OGG tracks instead of CD Tracks. (This will allow us to reduce a lot the disk space - 85% of the CD tracks space +/-)
• Support to play MP3/OGG as samples and voices.
• Images fade in and out like original game (fade to black) with options to turn it into a cross fade (fade to another image) which is the currently state.
• Open and Play FLA movies.
• FLA in fullscreen like in the original game. (Since its a bit streched I gave the ability to be widescreen).
• FLA movies with playing with samples.
• FLA movies with fade in and fade out frames.
• Play midis files
• Grid  (Scenario background) manipulation.
• Disappearing celling grids with cross-fade feature.
• Main scene elements and objects loaded. Like tracks, zones and actors.
• Sprite actors display in the correct scene position.
• Sprite actors with correct brick detph.
• Debug window with some key shortcuts to allow us to see few things while playing the game.
• And a lot of other back implementations.

• Currently working in the 3D engine system.

Hope I clear some things out. Be welcome to make a comment or ask for more detailed info.

LbaWinOwns wrote to me couple of days ago to say that he returns back to the LBA modding and he wants to help us developing LBArchitect. That should speed things up a bit :).

It’s been some time since the last blog entry and the announcement of the new version of Architect. I’ve been working hard during that time, and now I can proudly present you the results. I’m not good in writing (especially in English :)), but if I make a list of new features only, it will be too little, so I will try to describe each of new things, so you won’t have impression that the things were easy do write and it took so much time because of my laziness :D.

So let’s go:
1. The most important change is the integration of the Scene support, but you know about that already, so I won’t repeat the description. All the following changes come from this one (there are other changes, but they are minor).
2. Script editor with syntax highlighting (also highlights non-existent commands), code completion proposals and automatic indent.
3. Advanced Script compiler, that detects many errors and unusual cases (and gives warning messages on them). For all warning and error messages you can go to the corresponding place of the code by double-clicking in the message (like in most common programming language compilers).
4. Scene Object properties panel that lets you edit the selected Object properties instantly.
5. Selection menu, that appears when there are more than one object under the mouse cursor. You can now select an Object even if it’s fully covered by other Objects.
6. Objects can be easily found with the “Find” button in the properties panel. After clicking the button the selected object will be centered in the screen and marked for a while with a blinking frame. No more browsing through the area to find the little object!
6. The way of Scenario handling has been changed. You can now open and save Scenarios as regular files, and the program can be in two “States” (strange name, I know, but “modes” have been taken already): “Scenario State” and “Grid+Scene State”. The States determine two things:
1. Ctrl+S shortcut action - In Scenario State it saves current Scenario, and in Scene+Grid State it save Scene or Grid depending on the Mode.
2. The dialog shown when user tries to close the program with some element unsaved. In “Scenario State” the dialog simply asks if the user wants to save the Scenario before exiting. In the “Grid+Scene State” the dialog is more advanced, providing the following options: saving the Grid only, saving the Scene only, saving both Grid and Scene, saving everything as a Scenario, not saving anything and cancelling exiting the program.
7. The “New” menu option (File menu) has been merged with the advanced opening menu. You can now select to create a new Grid in the Grid frame in the advanced opening dialog.

And for those who have no idea what I was talking about in the previous points, here are some screenshots to show the features:

And if you feel like some Grid or Scene editing, don’t hesitate and try it out: http://sacredcarrot.xesf.net/mantis/view.php?id=66

But be careful for this is beta version. I’m pretty sure it contains serious bugs. This version is released mainly to help LBA modification teams (including the Prequel team of course) to faster design their Scenes. But I’m making it available publicly because maybe this way people find more bugs in shorter time than I would do alone (and this is also a good way to actually show that we’re doing something about the Prequel :)). If you decide to try how the beta version and you find any bugs or have suggestions, report them in the Bugtracker.

Hi,
Here you can see some screenshots of our work with our comments to help you guys understand a bit better about what we’ve been working on during this hiatus. I know we promised this awhile ago, but it turned out to be pretty hard to get all the teammates together to work on one blog post simultaneously.
The screenshots are, in most cases, very large, and the site engine will downscale them to fit your screens. To see the full size, you will need to click a thumbnail, and when the image finishes loading, click the green arrow on the bottom of the screen.

From Lewi-G:
Sep has proven to be a challenge to model. Unlike projects I have worked on in my career, Sep has a unique limitation in his design. Unlike a human face, which creates creases when you smile, Sep needed to keep his ‘LBA style’ head whilst having enough expression to look alive. Early in 3D, games were limited by computer processing power; simple shapes like spheres and cubes were used and hence Twinsen’s egg-shaped head was born.

In the end, I came up with a compromise and reshaped the head slightly so it was wider at the bottom to give the impression that Sep had cheeks. In order to create facial expressions a face needs to have a certain layout of deformation lines in its model in order for the face to change shape. Even though Sep’s head now had cheeks it was still a challenge to make new expressions without blendshape errors.

Not trying to bore you with too much technical talk, but blendshapes are a series of models which use each other as reference and morph between each other to give the impression of expressions. In the case of Sep I had to create 20 blendshapes! Each had to be modeled to a specific design to prevent eyes being sucked inwards or fat lips being created by 2 shapes adding to each other and doubling the overall head size.

You should have seen one of my early tests… Sep had the mumps!

The body rig was quite easy once the head was finished. I added a flexible spine and bones to allow an animator to push realism a bit and have some squash and stretching. This squash/stretch technique has been used in cartoons for a very long time to emote life but only recently has it been adapted for 3D. A good example of this can be found in the movie Ice Age when the Sabre toothed squirrel is pulling his acorn out of the cliff face. His arms stretch a little to tell the audience he is pulling for all his worth! Sep won’t be pulling acorns but I promise you the overall animation will look better than the original LBA animations

The only part left to finish are the eyes. I need to develop a method of using the eyelids as eyebrows. Eyebrows are an important part of human expression but unfortunately (most probably due to the computer limitations I mentioned earlier) Twinsen didn’t have eyebrows! I plan to use the eyelid itself to emote expression but I need to create a simple method of changing between these eyelid shapes for animation.

Yep. The LBA Prequels cut scenes will be much more advanced than the original LBA ones but hopefully will still stay true to the original charm/style.

From Double-J:
This image of the tavern interior really shows what we’re working on as far as atmosphere in the game. While everyone knows we’re working with the original engine, we’ve tried to think of ways that we can turn the old into new. This tavern - a central place for information in the game - highlights “the little things.” Different interior styles, revised layouts and items, and island-specific patterns and architecture are all going to help make this game have an easily identified atmosphere. You’ll know which island is which simply by the appearance of its buildings, the behavior of its people, and other subtle cues. One of the things I disliked about the original game was that I’d easily get islands confused since many of them had the same style and layouts. We don’t want players of the Prequel to have this issue. When you think of Proxima, it will jump into your mind. When you think of the other islands, it will too. There won’t be any question.

From alexfont:
In a more technical aspect, we tried to change the LBA1 Tavern to look older and give it a different mood. The picture shows some important stuff we’re working on (the grid is completely done). I don’t forsee any kind of brick layouts or structure changes for the planned demo. We still have the secret basement, a little change and with a new and different passage, which I’ll let you discover for yourselves. Some developments were made in the scripts and some navigation between different scenes are working now. Not much yet unfortunately, due to LBArchitect development and other obvious reasons, but even with this we were be able to test it and implement as we can see on the picture. Our first disappearing celling grid (cube), and its working :P. As a side note, we can also notice the game running with LbaWin, which is our main engine to use; this is even working on the original one and TwinEngine.

From Double-J:
At the same time, we did not want to stray too far from the original formula. Yes, each island should have its own personality, but they are also the same islands that Twinsen will see down the line. How much could possibly have changed from Hegesippe’s time to Twinsen’s? These were the questions we had to toss around when conceptualizing how these islands would appear in the game. One of the subtle changes you’ll notice is how close attention we’ve paid to trees and plant-life from the original game. Our theory is that if a tree was full grown in Twinsen’s time, it should be smaller or perhaps even a sapling - when Hegesippe existed. Similarly, we had to think about the differences in technology from Hegesippe’s age to Twinsen’s. We debated the merits or electrical power versus candlelight, and everything from steam to firearms. Once again, we looked to the original game for inspiration. LBA 1 + 2 had the certain blend of space-age excitement (Esmers, laser guns, cloning, etc.) while at the same time, relying on ancient myths and magic as well. I think we’ve done a good job in setting the ground rules for te Prequel in that we have made sure that technology - and its presence or absence - makes sense in each scenario.

From Luke:
I felt that Citadel Island should be a sleepy, old world village, rather like the kind that you can still find today in the south of England. Time has stood still or, at least, slowed to a crawl, perhaps rather frustrating for a young whippersnapper like Hegesippe.

The island is rather self-contained, more or less supporting itself - other islands in the Southern Hemisphere are more integrated into some sort of trading network, which of course offers plenty of opportunities for pirates - and the addition of a clock tower seemed to suggest this (as well as give the place a certain amount of chocolate box charm). I’m not sure who I intended to live in the area labeled ‘house’ in the drawing (presumably someone hard of hearing, given the proximity of the clock tower); we since decided that that would be a better location for the school.

Initially my designs for the buildings were somewhat German-Gothic. When Double-J suggested that architectural styles vary over Twinsun’s various islands and towns, I felt that the buildings of Proxima alone would be best suited to the Germanic look. The architectural style on Citadel is that of the first LBA game, so the player begins on somewhat familiar ground before venturing beyond Hegesippe’s hometown.

From alexfont:
Looking at Luke’s concept and all the idea behind I came to formulate this scene. We can find some similarities with LBA1 but still its a lot different. The scene building structure shouldn’t change, but the outside look must be change to what Luke’s explained. Its not that easy to create such thing and for now it isn’t a priority in our vast to-do list. I also like to say this was a tricky scene to build because of some limitations we have in the engine; we need to take out the player from some specific scene angles to kind of “trick” the viewpoint. The clock tower won’t be as we originally thought (with that roof, etc.), but the clock is still visible, all because the scene height is cleverly modified. Unfortunately, the clock can’t be higher :/

From Zink:
This screenshot shows what I am working on at the moment. The new version of LBArchitect will be a very important breakthrough for the project, nearly as important as LBArchitect itself was for the LBA community. Those of you who tried some scene editing using the connected LBA Story Coder and LBArchitect programs most likely noticed that it was a pain to make anything advanced with it. Not only wasn’t it very intuitive, but also many bugs prevented adjusting coordinates of the objects precisely. The sad thing was that alexfont didn’t have much time to work on his Story Coder. Thus, alexfont and I made a decision to connect both projects, and you can see first results on the screenshot. What does the connection mean?
- One program instead of two: a more stable, more intuitive, faster, and more reliable environment.
- Possibility of new features that were very difficult to implement earlier. You will see some of the new features in the upcoming version.
- We have a lot of ideas for improvements that alexfont couldn’t incorporate due to a lack of time. I hope to have more time than he does currently, so I will be able to introduce many of those improvements as early as in the next release.

So what exactly can you see in the screenshot? First, there is the object information panel in the top right corner. It shows information about the selected object and allows the user to edit its parameters. What stands out is the little “Find” button. Its purpose is easy to guess: it allows you to locate the object in the grid. No more having to look through the grid brick after brick. You will be able to find what you’re looking for with a single button click.

The second important thing, not standing out on the contrary, is the zone-adding button (next to the track and actor adding buttons). Before, if you wanted to add a zone, you had to click “New Zone” button in the Story Coder, which created a zone with initial position and dimensions, and to move it to the desired position and give it the proper dimensions you had to change the parameters and see what was happening through trial and error. Add the bugs in the editing fields to this, and setting a zone up was an almost-impossible task. I tried once, and gave up after a while of getting more and more annoyed. With that little button, it will be possible to create the zone you want with a little more effort that one click of a mouse button takes. Just click on the grid where you want to create a zone, drag the mouse to set its dimensions, and release the button. Yes, it’s as simple as that.

The last important thing that can be seen on the screenshot is the script editor. Not much new here: highlighting colours have changed; some parameters are now text constants instead of numbers; but the really important changes are not visible here (not only for the script editor), and I’m not going to tell you about them. I must keep something to make a surprise. I can assure you, that the jaws of many of you will fall to the ground when you see these things for yourselves. ;).

From Bot13 (about the window frames):
The style I wanted to achieve here was very clear to me. In the history of the LBA Universe, things were different. Now, even LBA1 had a pretty futuristic look all over, so I tried to make it the other way around. We already established it would be wise to go for a really old look, almost 18th century-ish. Myself, I’m a big fan of steam punk style, so that’s something that will be present in my future works.
The production was pretty simple; establish the material, look and feel of the object in a quick sketch, work it out in detailed form with the help of 3D software, and lastly render it in the correct shape, perspective, size, color. It’s not easy to really keep myself between the limits of the engine, resolution and color-wise it’s all very low standard. Though that’s all part of the pleasure and it sure is one hell of a project where I’m still planning to put much of my creativity, time and effort into.