Jump to content

Gauging Interest in Blades of Exile Rewrite


eirikoder

Recommended Posts

One of my favorite memories from my childhood was playing the Exile series. The storyline, the dialog, and the puzzles were all fascinating to me, and I feel like I learned a lot from the games.

 

I have followed the progress of the Open Source Blades of Exile project for some time, and I can respect what Celtic Minstrel and others have done to make this game compatible on more modern systems. Sadly, it looks as though BoE will always be stuck on the desktop, never making the transition to newer platforms and technologies.

 

I want to change that. I have been mulling around ideas for how to rewrite Blades of Exile to work on modern systems with modern input, and I wanted to get the opinion of those who have worked on game code, scenario designers, and people who still play the game.

 

Here are some thoughts I had on the rewrite:

 

1. Rewrite game code using C#. Write all non-UI code as portable. UI code can be written using cross-platform tools like Xamarin.

 

2. Redesign scenario data structure. Instead of binary file, save scenario data as JSON or XML. Include scenario assets, like images or audio, with scenario data in a single ZIP file.

 

3. Expand options for scenario writers. Drop special nodes, replace with custom scripts (Javascript, C#, other). Allow for custom spells, alchemy, etc.

 

4. Simplify game UI. Keep more options for desktop users, but allow for touch mode on tablets/phones.

 

This would be no small undertaking, I understand, but my love for this game and this series propels me to work on this idea.

 

I appreciate any input that anyone has on the idea. I am new to this forum, so I apologize if this topic has already been discussed.

Link to comment
Share on other sites

I'm glad you're interested in this, but do please keep in mind that the desktop is going to stay around for a while, especially as a gaming platform... IMO anyway.

 

1. Rewrite game code using C#. Write all non-UI code as portable. UI code can be written using cross-platform tools like Xamarin.

 

Hmm. C# is pretty unfriendly for Linux, IIRC, unless you take care to make it compatible with Mono. Not sure what other reasonable choices there are though.

 

2. Redesign scenario data structure. Instead of binary file, save scenario data as JSON or XML. Include scenario assets, like images or audio, with scenario data in a single ZIP file.

 

This would probably be a good idea. :)

 

3. Expand options for scenario writers. Drop special nodes, replace with custom scripts (Javascript, C#, other). Allow for custom spells, alchemy, etc.

 

Then it wouldn't really be BoE any more... ;)

 

I do think it's important to retain a "core" of spells and alchemy recipes, so that parties can move from one scenario to another.

 

OTOH, by far the most important part of modernizing BoE (IMO) is giving it some kind of scripting system. Special nodes are very painful to work with; I absolutely think it would be better to use scripting, even if the learning curve were steeper at first.

 

4. Simplify game UI. Keep more options for desktop users, but allow for touch mode on tablets/phones.

 

The game UI may not be bad for touch devices as it stands. Almost everything is accessible through buttons and the pointer device.

 

Anyway, my input...

 

I hope you've got way more free time than I do, and are a really really good programmer. Because "huge undertaking" does not even begin to cover this. Maintaining any compatibility at all with the original BoE spaghetti code is going to be quite difficult. Not to be patronizing or anything; it's just that a lot of people have tried to modernize BoE, and called it quites after not much time.

 

That said, I do have some good news - there is a port to C++/WxWidgets that's been stagnating for a while. See here:

http://code.google.c...e/source/browse

This might hopefully be of some help. Likewise the Classic BoE Win32 port (also on that link), which gets rid of the 16-bit rubbish and gives lots of variables human-readable names.

 

In all seriousness though, good luck. And thanks for volunteering your time.

 

Edit: Also, I should mention I might be of a little help. I'm no good with software design at this point, but I've done some coding on Angband variants and know how C works; if you could use e.g. a function written to certain specifications, I could probably do that.

 

(Though I would need to set up a Windows VM or something. Right now I don't have any way to compile CBoE.)

Link to comment
Share on other sites

Java would probably be a better choice as it could be run on just about any operating system.

 

Blades of Exile has one of the best RPG systems out there, and I would hate to see its development come to a standstill. But as the above user mentioned, rewriting the game is no easy task. That having been said, I see three possible course of action:

 

1. Find a way to renew interest.

 

Games like Doom have maintained a large fan base after so many years. The Exile series may not be as popular, but I don't see how it's impossible to get more people interested in it again.

 

2. Actively recruit people.

 

There are many, many talented programmers out there. If we find someone who has experience in developing games, it wouldn't hurt to ask them if they would be willing to help.

 

3. Hire a freelance coder.

 

The main issue here is money. A conservative estimate is that it'll take at least several man-years to write a game engine from scratch. Software engineers are in high demand right now, and having someone rewrite BoE for us would likely cost at $500,000. So I don't think this is going to work out.

 

4. Wait a couple of decades.

 

Computers of the future are likely to be much more powerful than the human brain, and it may be possible to simulate hundreds of software developers working together. Such simulations may even be replaced by strong AI. "Computer, analyze this file [the current version of BoE] and rewrite it in Java, using the specs in [file name]." But that's probably going to be a very long wait.

 

#1 is probably the best choice, although #2 may also help.

Link to comment
Share on other sites

"Computer, analyze this file [the current version of BoE] and rewrite it in Java, using the specs in [file name]."

 

I'd been dreaming of a compiler which does stuff like, if you say "Make me a game which is an RPG, takes up several gigs of space, has a fantastic storyline, has awesome graphics and audio effects, has an old-school stats-based character building system etc" and it actually does that.

 

I just wish things worked that way now and not many decades after.

Link to comment
Share on other sites

  • 2 weeks later...

2. Redesign scenario data structure. Instead of binary file, save scenario data as JSON or XML. Include scenario assets, like images or audio, with scenario data in a single ZIP file.

I don't really like XML; JSON is slightly better, at least. I was working on a mostly-plaintext format packaged into a ZIP file, but that got put on hold due to issue with loading the original scenario format... issues which never actually got solved.

 

3. Expand options for scenario writers. Drop special nodes, replace with custom scripts (Javascript, C#, other). Allow for custom spells, alchemy, etc.

No. Don't replace nodes with scripts. Custom spells and alchemy... maybe, but probably not.

 

4. Simplify game UI. Keep more options for desktop users, but allow for touch mode on tablets/phones.

I think I'd rather preserve the current UI; this may be familiarity or nostalgia talking, but it kinda wouldn't seem like the same game with an overhauled UI.

 

And... touch screen? I suspect that's unlikely to happen. The game makes heavy use of keyboard shortcuts, after all (though I guess it can maybe be played with just a mouse).

 

OTOH, by far the most important part of modernizing BoE (IMO) is giving it some kind of scripting system. Special nodes are very painful to work with; I absolutely think it would be better to use scripting, even if the learning curve were steeper at first.

The steeper learning curve is basically why I'm against this. That said, what's so painful about the special nodes? Maybe it's just that the interface for editing them is awful and could be dramatically improved to make the use of special nodes even easier than it currently is?

 

That said, I do have some good news - there is a port to C++/WxWidgets that's been stagnating for a while. See here:

http://code.google.c...e/source/browse

It may be a bit of a stretch to call my wxWidgets work a port; I wrote a resource management system and was working on a dialogue engine before I abandoned it.

 

Some time ago I discovered another library, one that's more like SDL, which might possibly serve as a better substitute for the Carbon libraries. It's a C++ library called SFML. Perhaps if I get some time this summer I'll try porting my resource management to that library and seeing if I can write the dialogue engine in it... I would like to finally see some more progress on this, but I've just been so busy with school and personal projects.

Link to comment
Share on other sites

A LOT of updating has been done to the Blades System and I, for one, am VERY thankful to all who have contributed to that end. The thing is... like so many projects, there never really is an 'end'. Other games and devices come along evey day and IMNSHO, I feel that a point has reached that has gone beyond the original concept of the Blades of Exile Game(s).

I still play, and work with, the Blades Scenarios and, when writing Walk-Throughs, I use the 'ScenText' and 'ScenData' files for reference. I know that's only a small item in the greater scheme of things, but I'd like to see the Blades of Exile Original concept remain in its 'repaired', or 'updated' status.

On the other hand, perhaps some of the ideas that are proposed here have a lot of merit. For instance, how about creating a whole new 'Blades of Exile II' system that would be written with modern programing and devices as a base? That would not only solve the desire to have Blades in modern language, but may very well draw in new younger enthusiasts as did the original Blades?

Note that each game has it's own generation of players who, like that game, fade into obscurity. Years ago, our oldest son won an Arcade Machine of Asteroids. About a decade ago it finally went into the Recycling Center, (notice, 'Recycling Center', not 'Dump'.)

I'll be 72 in a few weeks, have been playing and working with Blades for quite a while now and fully expect to continue for a long, long time. What has been done to 'clean up' the system is GREATLY appreciated. However, any ultra modernizing would be wasted on me and, probably, a lot of others.

Again, I think the ideas presented here would probably be better utilized to create a newer, updated version and draw in newer, updated players.

Thanx for listening,

me

Link to comment
Share on other sites

One thing I found most frustrating about the current scenario file is that there are many things that have a fixed number of entities; only so many fields, monsters, items, special nodes. I had a concept of a layout that was more dynamic, where some towns/dungeons would have, for example, more special nodes than the 200 allowed, and others would have less, depending on their need. This would apply to signs, town entries, and other things as well.

 

Another thing I found annoying was the inability to see the location on the design map things like horses, boats, etc. I fixed that in my VB version of the editor. Finally, the special node form had no way to see the meaning of a stuff done flag, or a sound setting or an inventory item. My VB editor addresses this problem as well by using list boxes and an additional file for the stuff done text. I really would like to get this re-written into a more common language so as to be accessible to the MAC community. If anyone has the time and the talent, I have uploaded the source code to my web site, and welcome any one to use any part of it. If there is interest, I will also upload my concept version of the dynamic database editor.

Link to comment
Share on other sites

One thing I found most frustrating about the current scenario file is that there are many things that have a fixed number of entities; only so many fields, monsters, items, special nodes. I had a concept of a layout that was more dynamic, where some towns/dungeons would have, for example, more special nodes than the 200 allowed, and others would have less, depending on their need. This would apply to signs, town entries, and other things as well.

Yes, much of my work was towards removing these arbitrary limits. As I recall, I updated all the in-memory structures to support it, but the scenario file format was also in need of a redesign and I don't quite recall how far I got on that.

 

I think showing boats and horses on the map was also done, but I can't remember whether it was in my Mac version, the Windows version (probably thanks to Ishad Nha), or both.

Link to comment
Share on other sites

I have a version that would read either format, but write the extended format. i also have a document detailing the format. These are available on my website.

 

Did you have a chance to look at how I dealt with the special nodes? This is in the version I have on my website.

 

The direct link to the page is:

http://www.hasenjs.byethost33.com/BoE/ExScenEd.html

Link to comment
Share on other sites

The steeper learning curve is basically why I'm against [scripting]. That said' date=' what's so painful about the special nodes? Maybe it's just that the interface for editing them is awful and could be dramatically improved to make the use of special nodes even easier than it currently is?[/quote']

 

Point taken...

 

The main problem for me is inability to view special nodes as chains instead of a list. It would be much better if I could see which special nodes lead to where, and interact with those chains in real time (as opposed to via a text dump or such).

Link to comment
Share on other sites

Hmm. C# is pretty unfriendly for Linux, IIRC, unless you take care to make it compatible with Mono. Not sure what other reasonable choices there are though.

 

I've looked into a couple of cross-platform options for GUI development and I have decided that Mono would work the best given the knowledge I have. If you look here, under the WIndows.Forms section, it appears that most applications are supported, as long as any platform specific calls are avoided.

 

No. Don't replace nodes with scripts. Custom spells and alchemy... maybe, but probably not.

 

The main problem with nodes is that scenario writers are limited in what they can do by what the application developer has determined they can do. Surely there have been times that you are writing a scenario and wished there was a special node that checked for party size, or if a certain type of pc is present, or even just wanted to do something multiple times in a loop. With scripts, scenario writers wouldn't be limited in what they can do. While nodes would work, it is unreasonable to define thousands of nodes to handle any reasonable action or event.

 

While scripts may be harder to learn at first, there are things that can be done to help the transition. Imagine a toolbox of code snippets, each matching existing functionality in BoE, that can be dragged and dropped onto an event handler. The code snippets would lower the barrier to writing scenarios, and people would learn the scripting language (Javascript) over time.

 

And... touch screen? I suspect that's unlikely to happen. The game makes heavy use of keyboard shortcuts, after all (though I guess it can maybe be played with just a mouse).

 

I envision two types of BoE applications: the first would be the 'classic' version of the game. This would include the scenario editor, party editor, and game itself. The interface would be similar to the existing interface, at least for the game, and all keyboard bindings and mouse events would work the same. Using Mono, one version could be written that works the same on all development platforms (Windows, Mac, Linux). This version would mainly be for scenario writers or people who enjoy the classic version of the game.

 

The second type of BoE application would be the 'modern' version. This type of application would be platform specific. For instance, one version would be written for Windows 8, another for iOS, another for Android, etc. This 'modern' version would only include the game itself (and possibly the party editor) and would add touch support. Instead of (or perhaps in addition to) keyboard bindings, certain actions would be presented as buttons only. This version would mainly be for a new audience, or people who want to play on devices besides their desktop computer.

 

On the other hand, perhaps some of the ideas that are proposed here have a lot of merit. For instance, how about creating a whole new 'Blades of Exile II' system that would be written with modern programing and devices as a base? That would not only solve the desire to have Blades in modern language, but may very well draw in new younger enthusiasts as did the original Blades?

 

Initially I thought that the conversion from old scenario format to new format should be done on the fly, so that you could just pick your favorite scenario and start playing it in the new format. I think this idea may be a mistake, however. Rather than automatic, scenario writers should have to import their existing scenarios into the new scenario editor, checking for errors, and allowing them to be tested before they are played by the average user.

 

I'm still mulling this idea over, but since this project is open source and would likely be hosted on Github or another online repository, we could have some sort of directory containing scenarios that have been converted and tested by users. A single location for scenarios we know to be playable in the new format.

Link to comment
Share on other sites

http://hasenjs.byeth...ecial_Nodes.pdf

 

This one works (for now) and I re did the other one as well. This is the full link in case the abbreviated shortcut fails again.

 

hasenjs.byethost33.com/downloads/EXSCENED/Special_Nodes.pdf

 

It seems that if you leave the htt:// on at the front of the URL, it gets turned into a hotlink, and gets abbreviated. If you select the line above and paste it into the address, it works OK.

Link to comment
Share on other sites

The scenario file I built does do away with limits in almost every way. I do this by changing the static arrays of records into a dynamic array, resizing it as needed, and storing the count of elements in another variable so I know how many of a thing to read in. Feel free to download my Version 2 editor to see how this was done. The Visual Basic files are readable by any text editor.

 

The one thing I could not see my way clear to was the limit of 10 NPC dialogs per town, There is a work around by using unused NPC (dialog nodes) from other towns, but you have to be careful to not use special nodes in their dialog.

Link to comment
Share on other sites

The main problem with nodes is that scenario writers are limited in what they can do by what the application developer has determined they can do. Surely there have been times that you are writing a scenario and wished there was a special node that checked for party size, or if a certain type of pc is present, or even just wanted to do something multiple times in a loop. With scripts, scenario writers wouldn't be limited in what they can do. While nodes would work, it is unreasonable to define thousands of nodes to handle any reasonable action or event.

...what.

 

This problem that you describe is nothing whatsoever to do with the node system. It is entirely plausible to have a node system that is equally as flexible as a scripting system.

 

Suppose you were to have a scripting system, and want to check the party size. But wait! There's no function to get the party size! So you're out of luck, right?

 

Loops are perfectly possible with a node system. Granted, they may be a little harder to understand, and due to the draconian node limit are difficult to make work. But that node limit is easily removed, and in fact has been in my version of the code.

 

What's the difference between defining thousands of nodes and defining thousands of functions? There's not a whole lot of difference between a node and a function, after all. Each takes some parameters and performs an operation with them. The main difference with a node is that part of its action is to determine which node is to be called next.

 

But... all things considered, the main reason why I don't think a scripting language is the right answer is because the game absolutely needs to be able to read ancient scenarios, and leaving the node system in place make that simpler to handle (no conversion required). I would not however be averse to having an alternate way of programming the nodes – a scripting language of sorts which would compile into a sequence of nodes. Exactly what form that would take, I'm not sure. It almost certainly wouldn't be Lua or Javascript.

 

I envision two types of BoE applications: the first would be the 'classic' version of the game. This would include the scenario editor, party editor, and game itself. The interface would be similar to the existing interface, at least for the game, and all keyboard bindings and mouse events would work the same. Using Mono, one version could be written that works the same on all development platforms (Windows, Mac, Linux). This version would mainly be for scenario writers or people who enjoy the classic version of the game.

 

The second type of BoE application would be the 'modern' version. This type of application would be platform specific. For instance, one version would be written for Windows 8, another for iOS, another for Android, etc. This 'modern' version would only include the game itself (and possibly the party editor) and would add touch support. Instead of (or perhaps in addition to) keyboard bindings, certain actions would be presented as buttons only. This version would mainly be for a new audience, or people who want to play on devices besides their desktop computer.

Well, once a scenario and savefile is standardized, there's nothing to stop you from writing a new interface to the game core. However, my preference would be to focus on the classic feel, so if you want an alternate feel you'll likely need to do it yourself (unless you can find some other like-minded coders to help you).

 

Initially I thought that the conversion from old scenario format to new format should be done on the fly, so that you could just pick your favorite scenario and start playing it in the new format. I think this idea may be a mistake, however. Rather than automatic, scenario writers should have to import their existing scenarios into the new scenario editor, checking for errors, and allowing them to be tested before they are played by the average user.

Converting on the fly is what I was planning. The game would open a scenario file, recognize that it's in the older format, and load it as such. The in-memory structures would of course correspond only to the new format. It's true that it complicates the game a little, but I don't think forcing the scenarios to be converted is reasonable. Perhaps there's a scenario somewhere that no-one has thought to convert, and someone who just wants to play downloads and installs it. They should be able to play it without having to know what format it is in.

 

I'm still mulling this idea over, but since this project is open source and would likely be hosted on Github or another online repository, we could have some sort of directory containing scenarios that have been converted and tested by users. A single location for scenarios we know to be playable in the new format.

It's already on Google Code. However, I don't think we should have a directory of scenarios in such a place. The scenarios cannot be considered open source unless their authors say they are open source. Even if they were open source, they are binary files, making version control a poor choice for storing them.

 

I have no objection to the general idea of a directory of scenarios, though. Perhaps you didn't mean to imply that directory should be under version control. I'd say it definitely shouldn't be.

Link to comment
Share on other sites

CM, it seems that we have had similar ideas to many of the problems. The place where I got stuck was after I had built an editor that would read either format, but write the new format. That is when I faced the next challenge, building a game engine that would read either format, (converting the old version on the fly), and there I got stopped. Now that the code has gone open source, I don't have time to go any further.

Link to comment
Share on other sites

Perhaps a dumb question, but is the current node system Turing-complete?

I think that it would be Turing-complete if you had unlimited SDFs, so... I'd say "almost", I think.

 

 

Harehunter, is there a document describing the file format you invented, or is the only documentation the source code itself?

Link to comment
Share on other sites

if this link becomes problematic, you can always link in via my home page, Blades of Exile, BoE Scenario Editor, and you'll find a list of links.

I also have a link to the download directory that gives you access to everything there.

 

http://hasenjs.byethost33.com/BoE/ExScenEd_Schema2.txt

Link to comment
Share on other sites

Yes, it is binary. It is more compact, and faster for reading it in. One other thing is that I read in the entire scenario when you open it, and write the thing in one swell foop. Actually, on writing the file, I delete the bak file if it exists, rename the current file to .bak, and write a new file.

 

I do have access to a tool set that stores everything as dynamic delimited strings, but when I looked at how to build a scenario database, I would have to have broken it down into several files.

Link to comment
Share on other sites

The only downside of a binary file is that endianness matters. Now... that may not be a significant issue anymore, since Mac has become Intel and this Win/Mac use the same endianness, but still. (Of course, the game will always need to be able to read legacy formats in PPC endianness.)

 

I was working on a zipped plaintext format. I won't say I was terribly attached to it, though. I'm not sure I'd use your format either, though. I'd need to look at all the code again to decide.

 

I don't really want to do XML; it's very verbose, though zipping it would alleviate this and I'm already using XML to define dialogs. I suppose JSON may be an option though.

Link to comment
Share on other sites

XML is cool, there's a lot of libraries for handling it and it's tried-and-true. JSON is okay, but from my limited experience with it it just doesn't seem as robust.

Edited by sylae
of course this is the person who defaults to the php serialize function, so my opinion may or may not be useful.
Link to comment
Share on other sites

I appreciate the objection to the endianess of binary files. The easy way to deal with that of course is to use the "magic number" at the very beginning of the file to determine whether to call the byte swap procedure or not. The advantage is that you can build fixed length record structures that can be retrieved in a single fetch with minimal overhead. And since numbers are stored in binary, there are no data type conversions to perform upon input or output.

 

As an alternate method, we could store the data into dynamic length, delimited text strings. The database engine I work in uses the special characters (decimal values 255, 254, 253, 252) to delimit records, attributes, values and subvalues. (Relationally, records equate to rows, and attributes to columns. Values and subvalues represent third and fourth dimensional aspects of a nested table.) In the context of a dynamic array, the meaning of a value depends strictly upon its position in the string as measured by the limiters. To get an understanding of this refer to the pick-wiki site www.pickwiki.com/cgi-bin/wiki.pl.

 

XML is cool and it is all the rage. But so was COBOL when it came out and both constructs are just too verbose. They also have the same drawback as dynamic arrays, in that you either have to parse everything from beginning to end, or build indexes, which would have to parsed before you can get access to your data.

Link to comment
Share on other sites

I'm down with doing things really efficiently, but I don't think we need to worry about the consequences of having the entire scenario/party in memory. And in any case, it wouldn't be too hard to break it into multiple XML files stored in a single tar.gz that gets extracted to /tmp when you load it.

Link to comment
Share on other sites

If we go in the direction of multiple files for the scenario, then why not use a real database engine such as mysql, or Exodus.

 

As for the entire scenario in memory, I only did that because I could. It also makes it easier to match the terrain on the outer edge of an outdoor section if you have the adjacent sections in memory. When I am in Outdoor Terrain mode, when you are working near the edges, I am able to paint the terrain along the edge with cell from adjoining sections. Besides, with today's memory (even the memory available 10 years ago when I wrote this) it is not necessary to page-in page-out sections of the scenario. Shoot, I work with far larger Word documents than the average BoE scenario. I'm not saying binary is necessarily the only way to go, just throwing out stuff about its advantages.

Link to comment
Share on other sites

XML is cool, there's a lot of libraries for handling it and it's tried-and-true. JSON is okay, but from my limited experience with it it just doesn't seem as robust.

What you say about XML is true. I don't think it's well-suited to two-dimensional data, at least; it's also not a great choice for a simple key-value configuration format (for that, you want JSON, YAML, or just the classic .cfg format). The latter is does not apply to a BoE scenario though. (The former obviously does.) Perhaps XML might be suitable for the scenario header data, including monster and item definitions, but... I dunno. It's still quite verbose, and even though the plan was to zip it... I dunno.

 

I appreciate the objection to the endianess of binary files. The easy way to deal with that of course is to use the "magic number" at the very beginning of the file to determine whether to call the byte swap procedure or not. The advantage is that you can build fixed length record structures that can be retrieved in a single fetch with minimal overhead. And since numbers are stored in binary, there are no data type conversions to perform upon input or output.

The disadvantage is that I don't want to deal with fixed length record structures. I want to remove limits, which means I need variable length structures. I'm extensively using std::vector and related classes in the updated structures, for example.

 

As an alternate method, we could store the data into dynamic length, delimited text strings. The database engine I work in uses the special characters (decimal values 255, 254, 253, 252) to delimit records, attributes, values and subvalues. (Relationally, records equate to rows, and attributes to columns. Values and subvalues represent third and fourth dimensional aspects of a nested table.) In the context of a dynamic array, the meaning of a value depends strictly upon its position in the string as measured by the limiters. To get an understanding of this refer to the pick-wiki site www.pickwiki.com/cgi-bin/wiki.pl.

I think a comma-separated format may be a little too simple. My preference would be some sort of key-value format.

 

 

 

I'm down with doing things really efficiently, but I don't think we need to worry about the consequences of having the entire scenario/party in memory. And in any case, it wouldn't be too hard to break it into multiple XML files stored in a single tar.gz that gets extracted to /tmp when you load it.

This is true, but as previously mentioned, I think at least some of the data is poorly suited to XML. Obviously the advantage of using a tgz though is that you can mix multiple formats, so this isn't really a big deal. (We're definitely going to be using either a tgz or a zip; the code is currently written with the former in mind).

 

I had no intention of having the entire scenario in memory at one time; the game itself only loads up to four outdoor sections and one town, as I recall, and in the scenario editor it would be sufficient to load only one section at a time (showing edges from adjacent outdoor sections does not require keeping those sections in memory, after all).

 

If we go in the direction of multiple files for the scenario, then why not use a real database engine such as mysql, or Exodus.

That's way too much. If we used a real database engine, it would be sqlite (or similar). However, I think most of the data is poorly suited to that as well. Perhaps the item and monster definitions could be done that way, though. I think they might be suitable for a database-type format.

 

It also makes it easier to match the terrain on the outer edge of an outdoor section if you have the adjacent sections in memory. When I am in Outdoor Terrain mode, when you are working near the edges, I am able to paint the terrain along the edge with cell from adjoining sections.
But you only need one strip of land in each adjacent section and perhaps a single tile in the diagonally adjacent ones, so you can just load nine sections, save the bits you want, and discard the eight you're not currently working on.

 

Besides, with today's memory (even the memory available 10 years ago when I wrote this) it is not necessary to page-in page-out sections of the scenario.

You do have a point here, but at the same time I don't think we should keep things in memory that we're not using. Okay, so because today's memory is cheap, perhaps the editor could keep the current section along with all eight adjacent sections in memory without a noticeable performance drop. Perhaps it could keep the rest of the scenario in memory too, but why should it, when you're currently only working on a specific outdoor section? And if you're working on the outdoors, you don't need any towns in memory and vice versa.

 

Loading adjoining sections of the outdoor map, 3D BoA Editor has always had that and it is good. It is one of many features that a BoE editor could import from BoA 3D Editor.

Yes.
Link to comment
Share on other sites

Is the limit you're trying to break out of the size of a data structure or the number of recurring instances of that data structure? For example, the data structure for a town monster definition does not need any variable length elements. It is a simple array of integers. The real problem is not the structure but the fact that the number of occurrences of that structure was fixed. To correct this problem, a parameter in the header section of the town would tell you the number of definitions and a pointer to the beginning of the list.

 

You are correct that a CSV would be too simple, but the system of delimiters in PICK database is actually a 4 dimensional construct. CSV's only represent two dimensions. I use this to describe a bill of material consisting of some values that apply to the item as a whole, and a multivalued list of component parts which may consist of a single set of attributes or as many lines of data as are necessary to build this item. The advantage of this data structure is that you don't have repeating text for the tag for each value, everything is referenced by its position in the structure as marked by the delimiters; the third value of the fourth attribute of the 22nd record.

 

Another reason I chose to load the entire file at once was due to the dynamic nature of my file layout. In Jeff's layout, the size of a towns data was the same for every town, so that it was easy to extract, manipulate, and replace the entire structure into the same place in the file. Now that I have variable numbers of the various data structures (variable # of fields, npcs, signs, dialogs, special nodes, ...) it becomes more difficult to insert a larger block of data into a file that had a smaller block to begin with. I would have had to read in the entire file in order to rebuild it with the expanded data size.

 

A good compromise would be to have a separate file for each section/town/dungeon. I was just trying to follow the original model as closely as possible for simplicities sake.

I'm not saying that a single file structure is the best. It just avoids the situation where you have not a directory of files for your multiple scenarios, but a directory of directories for the files of those scenarios. You would have to deal with conventions for identifying which data file was associated with which section/town of the scenario.

Link to comment
Share on other sites

Is the limit you're trying to break out of the size of a data structure or the number of recurring instances of that data structure? For example, the data structure for a town monster definition does not need any variable length elements. It is a simple array of integers. The real problem is not the structure but the fact that the number of occurrences of that structure was fixed. To correct this problem, a parameter in the header section of the town would tell you the number of definitions and a pointer to the beginning of the list.

In general, I believe most of the changes involved changing static fixed-length arrays to variable-length std::vectors, so it's the number of recurring instances of a data structure, like you said.

 

You are correct that a CSV would be too simple, but the system of delimiters in PICK database is actually a 4 dimensional construct. CSV's only represent two dimensions. I use this to describe a bill of material consisting of some values that apply to the item as a whole, and a multivalued list of component parts which may consist of a single set of attributes or as many lines of data as are necessary to build this item. The advantage of this data structure is that you don't have repeating text for the tag for each value, everything is referenced by its position in the structure as marked by the delimiters; the third value of the fourth attribute of the 22nd record.

I have no idea what this PICK database thing is, so I can't really comment on its applicability here.

 

A good compromise would be to have a separate file for each section/town/dungeon. I was just trying to follow the original model as closely as possible for simplicities sake.

I'm not saying that a single file structure is the best. It just avoids the situation where you have not a directory of files for your multiple scenarios, but a directory of directories for the files of those scenarios. You would have to deal with conventions for identifying which data file was associated with which section/town of the scenario.

As I recall, a multiple-file structure was what I was working on, but the files would be concatenated into a tarball and gzipped. (Then the gzipped result would have the scenario/savegame version header prepended; I never did manage to get that part to work though.) So, you get the advantages of having multiple files (opening a scenario amounts to extracting it into a temp directory, while saving means repacking it into the tarball), without having to manage directories of directories or needing the users to know what to call each file.
Link to comment
Share on other sites

Bulls eye Ishad. It is quite dynamic and extremely easy to do rapid on-the-fly design/development of any thing you can think of. I threw together a complete material requirements planning system in about two months. Another programmer was trying to build a simple hardware inventory system in Oracle and after a year, it still wasn't right. So my boss asked what it would take to do the thing in PICK, i said about two weeks, and got it done in one.

Link to comment
Share on other sites

  • 1 month later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...