Jump to content

New Scenario Format


Celtic Minstrel
 Share

Recommended Posts

I'd like to talk about the eventual new scenario format. I noticed Sylae started on it a bit here; that could be used as a base.

 

As for my own thoughts, I think I'd like to split up the towns a bit more - keep the map in a separate file, probably the special nodes as well, and maybe even the dialogue. I like the idea of saving the special nodes in a format that vaguely resembles an assembly language, for example, and I don't feel that XML is a good choice for two-dimensional data; I'd prefer just having a file with one row per line, separated by commas or tabs or whatever.

 

I also want the editor (and maybe the game as well) to be able to handle two separate formats. Since the scenario format will be a gzipped tarball, the editor should be able to read an unpacked scenario as well as a packed one. I'm not sure if this is too complicated, but the main reason for having an unpacked scenario format is actually so that we can see diffs to the mainline scenarios in the version control. I'm also not quite sure how it would identify an unpacked scenario.

 

I'm going to start building a schema for the sample in the above link, but I was wondering what the point of the <id> generated from creation time is? (Also, how do you expect people to use their Spiderweb user ID as an author ID if they don't have a Spiderweb forums account? :p ) And what's the purpose of the <user> subtag under <ratings>?

 

Originally I was going to bundle it up in such a way that the old BoE detects that it's a BoE scenario from a newer version of the game - do you think that's still necessary?

Link to comment
Share on other sites

Yeah, I've been toying around with an XML-based format for a long time, and never really got anywhere with it. Unfortunately I can't remember what most of my intentions were for this particular incarnation, so it might as well get thrown in the bin.

 

I agree on your choice for large array-things like terrain data. A CSV as a separate file or even encapsulated in a CDATA or something. Saving the nodes in a custom format would work too, although I've been thinking nodes in general need a revamp.

 

As far as the silly <user> subtag, that was to allow for a future expansion into carrying CSR data with the scenario. Which is kinda stupid. So let's not (especially now that I've almost-got a finished API for my CSR parser). :p

 

The <id> tag is simply a way to provide a machine-readable 'link' to a database, enabling things like 'view CSR reviews' and 'download via an in-game browser' or some such. On the off chance we have similar-sounding scenarios (or a name change?) it could come in handy. (A key feature I'd like to see in CBoE is integration with online services like the CSR and scenario downloads. I think it'd make it really easier for people to find a scenario to play)

 

Author ID/SW ID is just a vestigial bit from when this was planned on being tuned towards CSR reviews as well. Feel free to eradicate.

 

As far as version control, I had a couple thoughts. One was that we could essentially have the actual scenario folder be its own local git repo, and each save is effectively a commit. This has a lot of drawbacks, however. The better solution, I think, would be to go with a 'dev layout', where its saved, unzipped and uncompressed, for version control use. Once it's ready to go, the game could create a 'release layout', which is essentially the same thing except tarballed.

 

w/r/t having the old BoE detect it as new, I don't think it'll be worth it. I mean, I doubt very many people are using the original BoE anymore, and the new format will probably have a different extension anyway, so I doubt there'll be too much of 'oops, opened it in original boe by mistake'. I dunno.

Link to comment
Share on other sites

Okay, so the <id> is effectively intended to be a uniquely generated ID. I'll leave it in, but might choose a different way to populate it. I'll scrap the author ID and the <user> subtag.

 

At the moment I'm thinking I'll expand on your idea of saving certain location-bound data with the map data (you had sign IDs and special node IDs); so far I'm thinking boats and horses, but I'll likely add more as I think of them.

 

So far, I've got a working XSD schema for the core scenario data, and one for the core town data. On the todo list are monsters, items, terrains, outdoors, and dialogue.

 

For the version control, I think what you mean by "dev layout" is kinda what I was thinking of - the editor (and possible also the game) would be able to load a scenario from an unpacked folder - so I'll go with that; the only question is how the scenario can detect that a folder contains an unpacked scenario. I can probably work something out once I get to coding it.

 

About nodes needing a revamp, did you have any particular ideas about it, or was it just a vague thought?

Link to comment
Share on other sites

Well, the current 'node' implementation is missing a lot of things, like any sort of string manipulation and variable management. Ideally I we could replace 'nodes' with a basic scripting engine similar to Avernumscript, and the editor could act as a simple point-and-click IDE of sorts. The issue is finding a balance between usability and features. Personally, I think we should strive for something similar to Warcraft III and JASS. The editor would present this interface, which was pretty straightforward--if ten-year-old me could make something somewhat-playable, anyone can. The interface would take the triggers and write a JASS script out of them (this is all transparent to the user, who just has their trigger editor).

 

It's a big jump from the current system, but I imagine something like bison could help a lot with parsing a script language. I might take a look at this and see if I can come up with something.

 

As far as detecting an unpacked scenario, I had originally thought about making the main 'info' file act as a sort of 'carrier signal' for the scenario. So if you open a folder in the editor, it would look for that xml file in the folder, and if it found it (and it was valid) it'd know the folder was good.

Link to comment
Share on other sites

I'm reluctant to switch to a full-fledged scripting language like AvernumScript. In particular, I seem to recall that the nodes system is one of the reasons BoE was considered easier to design for than BoA. I don't have any objections to improving the special nodes interface though. And I was thinking about storing the nodes in a sort of assembly/BASIC-like syntax, which could end up being sort of like a scripting language (but more low-level than AS). The node system has a lot in common with assembly languages in particular, with each node containing an "opcode" and a set of parameters, but if we were going to properly support that as a scripting language, we'd have to include support for things such as labels and defines.

 

Regarding your first sentence about missing things, those could be just as easily implemented as additional node types.

Link to comment
Share on other sites

Okay, I wrote up a tentative grammar for special node definitions - it's up here. Any thoughts?

 

(Note: I adjusted the list of possible node types partly on whim, combining ones that seemed similar and such; before actually using this grammar, we'd have to make sure the list here matches the list in simpletypes.h.)

 

EDIT:

 

Maybe I should put a sample here!

 

The following file would define a node sequence (IDs 0, 1, and 5), which reveals a town if the party has enough gold.

@if-gold
  ex1 50, 5      # If they have 50 gold, take it and jump to node 5
  goto 1      # Otherwise, jump to node 1
@disp-msg
  msg 2      # Shows string 2; the omitted argument is assumed to be -1
@town-visible = 5 # Explicitly specify node number (if omitted, assumed to increment from last node)
  msg 3,4      # Shows strings 3 and 4 in the message dialog
  ex1 3,1      # Town 3, set visibility to true

Edited by Celtic Minstrel
Sample time!
Link to comment
Share on other sites

BoE assembly language? I like it. An awful lot, actually. :)

 

(Reading real x86 ASM makes my eyes bleed, but treating BoE nodes as if they were instructions for a really weird CPU seems like a fantastic approach. Might just be the late hour though.)

 

Edit: you wrote a header file? OMG OMG you are so awesome. Thank you, I'll see if I can't contribute something to the Github repo this weekend when I'm not horribly busy...

Link to comment
Share on other sites

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.

 Share

×
×
  • Create New...