*i

Well yes, the Character Editor is nice for simple things. Checking the state of flags, doing other diagnostics, and doing in depth modification is not one of them. Granted we can edit the source code for that too, but I do think there is some virtue in keeping things simple for players.

Yes, binaries would the easiest to read. If one is clever, one can make a pretty generalized format too. I mean, at the end of the day, everything is just 1s and 0s. Mainly I am suggesting the ASCII format not so much to be easy to read, but to be easy to modify in the event something is wrong. If I want to go in and change a flag because something got messed up because of a bug, this is very easy to do in the ASCII format. Granted, it might take an "expert" user to do it, but it still is possible to do.

You are correct that I suggested a fixed number to constrain the amount of data we would need to keep. Now I do think we should set this number to be high. Quote: True, that would be a good format if we have a fixed number of flags for each scenario. Just to clarify, what I am proposing for the token would not care if there are a fixed number of these or not. An advantage to the ASCII format means that there does not need to be a prescribed order to anything aside from a few header things. Otherwise, you can just read the line, parse the arguments, and by way of a select case you just modify the default data. This parser type implementation makes changing the file a lot easier in the future.

I'm not sure I understand exactly what you are saying in your first paragraph. I get the point about storing everything, but robust access via the nodes is quite tricky because, unlike BoA, the fields are fixed and we lack a lot of flexibility. In other words, I do not see how one would rewrite every node (and maintain backward compatability!) to differentiate between flags in this scenario and the another. So yes, campaign flags are not elegant, but neither is the BoE interface. It's elegance comes from its simplicity on the user's side. Of course, we lose a lot of power, but BoE seemed to do pretty darn well. I agree letting save files grow without bounds is a bad thing. Strictly speaking, the number would be bounded by the number of campaign flags used in scenarios, which would tend to be small. This is part of the reason why I said to only copy very specific data, at the discretion of the designer, to alleviate this issue. Of course, the data will be there "forever", but that is the point. I also feel that all campaign flags for a scenario should be cleared if you reenter the scenario. If you load a party that completed a scenario, enter the scenario, and save, all the campaign flags from this scenario should be gone.

As a side note, I said this before a while back, but I think it should be said again. Remember, when Jeff wrote BoE, it was 1997 and he wanted the game to run on machines from the early 90s. He did a lot of things that, back then, were necessary. These days, our requirements are far less stringent and we should not be afraid to use the space if it makes things clearer for the programmer, designer, or player. I am not saying we should be wasteful, but we don't have to be a bunch of misers when it comes to memory usage.

Mainly I used the 2D notion because they act like an SDF flag this way. It is not essential and could easily be 1D. I think giving people campaign flags 0 to 255 would be reasonable. Somewhere in BoE, you would require this new array whose non-zero contents would be stored to the save file. This brings up an interesting thought about saving after leaving. What happens if the player forgets to save and moves on to another scenario? How will this data be remembered? Something we shoudl consider. A proposed format: CAMPAIGN "Scenario Name" flag value Note that I put Scenario Name in quotes. This solves the problem of white space. The variables flag and value are the campaign flag index and the value it is set to respectively. Each campaign flag assigned could have a separate entry eliminating the need for a list of that type. Upon entering the scenario, all previous campaign flags would need to be loaded, but this should be fairly simple. Somehow the data structure for it would need to have a notion of Scenario Name. Again, not too difficult.

The issue, as people said, is retrieval. However, there is an easy way to do handle this. Recall that the scenario text area has strings 10-59 that are essentially unused. One could craft a node to accept a string ID as an argument along with a campaign flag (much like an SDF). BoE can then do a string compare and copy the value of the flag. I would imagine if the scenario or relevant flag is not found, the value returned is a zero. One could do more elaborate checks, of course. So here is my proposal for the node: Set Campaign Flag: SDF A: x-coordinate of Campaign Flag SDF B: y-coordinate of Campaign Flag Extra 1a: Value to set flag Get Campaign Flag: SDF A: x-coordinate of SDF to set SDF B: y-coordinate of SDF to set Message 1: Scenario Name String Extra 1a: x-coordinate of Campaign Flag Extra 1b: y-coordinate of Campaign Flag Extra 2b: Special to call if scenario or flag not found Note that this would need to be stored in some array for campaign flags that would get transferred to the save file upon saving or leaving the scenario.

It is admitted weird reading this ten year old argument. It felt like one of those black and white flashbacks you see in movies.

I guess I was not clear exactly what you meant. I'm just advocating for some common sense system that we all decide on now so that versioning is standardized. The way I planned things with the scenario format was a routine that updated things from format n to format n+1 until the most recent format was reached. This way the Scenario Editor would auto-convert old scenario files without much effort. CM touches on the endianness advantage of going to an ASCII format. Even if we make the assumption of an Intel chip set (which is not advisable at this point), there is no guarantee that the endian consistency will continue forever and an ASCII format saves future developers from any headaches. In addition, there are definite advantages to an ASCII format in that it allows a user/designer to more easily modify things about their party and allows for a more free format specification for greater flexibility. As for storing the SDF array, it is probably going to be a bunch of zeroes. A good way to help with the ASCII format is to simply store an ordered triplet of each non-zero element: SDF 1 6 2 This would say SDF(1,6) = 2. Upon loading the scenario, the SDF array will need to be set to zero. Each read would check for the SDF prefix, and modify the appropriate element. Campaign flags would depend on how one handles scenario records and retrieval.

As far as I know, this should not break compatibility with any scenarios, so it should probably be removed. There is no reason for something like this and is probably an E3 relic.

By a role on him/herself.

Shanker is in the game because she plays a fairly important role in the region in the game and clearly meets the "everyone should get along" concept. So yes, she needs to be there. The problem is she is very clearly a mage. These are two things that must stay the same for plot reasons. The only solution where we have some wiggle room is to adjust the Anama. Again, I would like to see someone suggest something concrete for what we can do with the Anama that preserves storyline, keeps the Anama on parity, and is fairly simple. I would be willing to not include Shanker in the tally of Anama versus mages, even though it is ad hoc. I would even be willing to guarantee Shanker does not get selected by Micklebur. I would prefer something different, however.

I totally agree with gzipping. The main reason one would preserve the notion of the SDF array is for legacy reasons. The SDF array is fairly rigid in BoE that changing to a more flexible variable system would create headaches elsewhere in the code.

One more thing that just crossed my mind is campaign flags so data can be ported between scenarios. Sending these in the save file would be a very good thing. It may be worthwhile to start a discussion in another thread about the details of access/implementation.

I am indeed in favor of putting in more information in the save files. Hard disk space is cheap these days and internet transfer speeds are fast enough. If you have the time, I would even go so far as to say this data can be ASCII as opposed to binary to get rid of the cross-platform portability issues. Also, start giving the formats version numbers and place it near the head of the file. Version 0 would be the default format, 1 would be your new one, and future versions would have further increments. This allows future designers to change the format specifications with greater ease. What I would also do is make a lot of these things dynamic. The header information can contain info on the size of the arrays and stuff like that. One of the most frustrating things with the old scenario file format were these hard coded values. If you grow the SDF array to 310x30, put these values in the save file. If someone later decides to change the dimensions to 310x50, it will be easy to reconcile the two versions. I'm seriously considering getting back into rewriting the scenario format to be more extensible. Sadly, graduate school has been a huge drain on time until the last couple months.

Quote: I don't see any reason to load the entire outdoors at once. I don't think it would really provide any significant advantage, and it would be difficult to change; and also if the outdoors is large enough it may even be a bad idea (not sure though). If we decided to do it, though it would have no effect on the scenario format. Maybe the savegame format, but not the scenario format. When I still had time for this, I tried to modify the source to get it to hold the entire outdoors in memory. I cannot remember the exact reason except that it did help with the new, more flexible, scenario format I was working on.

Quote: The first is that reputation is fairly important in our small community, and so any designer who clearly stole another's idea would not be well received. Sadly, we had an experience with this about ten years ago. However, you are correct in the reaction. Said designer was not well received and pretty much ousted from the community.

I will say sure.

All artifacts may only be used once per day. Pass it as much as you want, but the recipient must wait until the next day to use it.

Also, I'm thinking of modifying the Holy Symbol. It is now an item people use, it counts as an ability use, can only be used once, and it does something different for each role in addition to removing Gladwell's geas. Here is what I have already: Adventurer: Reveals identity of one of your targets (random). Aimee: Not applicable. Alchemist: Grants you two more alchemicals. Anama Hunter: All Anama members are cursed for 24 hours. Anama Priest: Gives a bonus Anama member toward your victory condition. Bound Servant: If Gladwell dead, removes your geas. Craftmaster Strine: Reduces number of items you need to make by one. Darkside Blademaster: Grants you resistance for 24 hours. Darkside Mage: Grants you protection for 24 hours. Dionicio: Reveals the target list of the Darkside Loyalists. Domont: Reveals identity of one of your targets (random). Empire Spy: Reveals identity of one of your targets (random). Fae: No effect. Gladwell: Identifies all players who may join you. Infiltrator: Reveals identity of one of your targets (random). Machrone: Decreases the number of questions you must answer by one. Micklebur: Required for victory. Necromancer: Reveals identity of one of your targets (random). Nephil Activist: Gives a +20 coin bonus to the Fang Clan. Oliver: Gives a +10 coin bonus for your victory condition. Pure Spirit: Required for victory. Ronaldo: Reveals identity of one of your targets (random). Shanker: Reveals everyone's attitudes toward you. Vahkos: Not applicable.

Quote: For example, there's no reason that the Shanker has to be a mage, which seems the most obvious solution to me. Plot is the obvious reason and violates one of the requirements. I could restructure the Anama to take Shanker out of their target list, but I'm not sure of the idea of any role having absolutely no enemies whatsoever. The more palatable way from a plot point of view is to make killing her not worth the trouble. Right now, only two people even have a chance of taking her down: Ronaldo and Micklebur. Both would have a very hard time of doing it. Also, whoever plays this role is going to have to make some sacrifices. Some players are, by design, dedicated killers. At best, Shanker can help to keep them confused about who their targets are. Nonetheless, this is unsustainable from the long view. Information will inevitably get out. Here are some ideas for Anama related victory conditions: Anama Priest: Have the number of Anama members (living or dead) outnumber the mages that win. Using the Holy Symbol increases the effective number of Anama members by one. Micklebur: Two randomly selected mages dead and use the Holy Symbol. Anama Hunter: Both the Anama Priest and Micklebur do not win. As for Shanker's ability: Shanker: When attacked you are a skill of power for the duration of the battle and have a 50% chance of escaping. You are immune to negative status effects. May submit a list of up to four pairs of living players that does not use any one person more than once. You will learn the attitude (friendly, neutral, enemy) of those players. So here's what I have done. Shanker is no longer guaranteed a target of the Anama who now have much softer victory conditions. Trying to kill her has an unblockable 50% failure rate (read as wasted action). The only reliable way to kill her is with the valuable Wand of Death. Playing the game should have some risk for every role, even if that risk is only hypothetical.

Note that Dionicio was weakened slightly. I want to remove reliable ways to absolutely learn roles. As for Shanker, I made her immune to negative statuses and anyone who attacks her will have any positive statuses removed. She is a mage and will therefore be an Anama target. However, she will be very hard to kill. As of right now, the only ways to kill her are with the Wand of Death, Flaming Sword, or Weapon Poison. In her defense, because she is so hard to kill, the Anama would probably be wiser to find easier targets. In fact, a more viable strategy for Shanker would be to feed the Anama the Darkside Mage and Gladwell. I may change Micklebur's victory condition to bring back Gladwell being worth two kills.

The priest's ability does not work on immunities. Your point is all well and good, but comes without a solution that preserves balance of the Anama and keeps the storyline.

That means every time Oliver trades with someone he has not received an item from and receives an item, be gets a 5 coin bonus at the end of the game. The counter example is if he trades with someone three times, he only gets the bonus once. This encourages him to trade with lots of people.

I updated the role list. Please take a look. Just for a note, Oliver's victory condition is now: Victory Condition: Have 50% more in coins and items than you started. At the end of the game, you get a 5 coin bonus for each unique person you have traded with and received and item (coins do not count).