My adventures with WON

[PhilThib]

Very interesting (and long) reading and exchanges of comments in all the above posts. There are some good lessons to take for the future, although the immediate concerns are more to fix what is still creating issues in WON and finding a right balance. Indeed, the engine was initially designed and tailored for a simple "match" of 2 players in a simple campaign environment with little non-military decisions (i.e. BOA/WIA)...that was 9 years ago! The engine and products have evolved since them and increased depth and complexity has inevitably led to more potential issues and 'bugs'...that's usually what happens when you grow up / age...

Honestly, the 2 of us couldn't have keep up with the demands of the crowd without help of the betas. But also the betas are the most dedicated players and those more involved / aware of the engine, and of course, like us, they tend to overcome what is an obvious difficulty for newcomers.

That's where we want to go for our next game: make it simpler and accessible to all, like it is now expected by players.

As for the modding part, we also need to find an "easier" way to let players try it...

[Sirlion]

That's where we want to go for our next game: make it simpler and accessible to all, like it is now expected by players.

If I may humbly suggest from a "newcomer" perspective: dont do this. Dont say publicly "we want to do this and this for our next game". One immediately loses faith in your current prodcut because it looks like you cant do anything about it beside patching and you are already ahead with your schedule. I understand that an engine cannot be upgraded / adding new features etc when the initial release is already up for download, but it is just common courtesy for somebody who already bought the game.

With that being said, I dont think that streamlining aspects of your games is something urgent. They are brilliant games. They just need to work.

[lukasberger]

As for the modding part, we also need to find an "easier" way to let players try it...

Look, I understand you've been innundated out of the blue with complaints, criticisms etc lately that are perhaps fair, but maybe unfair as well. Overall, I love your games and am a real supporter.

That being said, the AGEOD db structure totally sucks. See my other comments for details.

I don't say this as a hater, or an attacker, or anything other than a true friend, but the typical AGEOD db structure is really crappy, it's incrdibly difficult to work with as a modder.

Please, add a db structure that allows for easy changes, not only using public posts but any db, user based or otherwise as well as plenty of mods.

Please give us some flexibility and creativity in the mods that we apply to the game. If you can do so, this is absolutely the best game available. If not it's still very good, but not incredible. Please, do all all you can to lift it to the later level. You've done so before and (I'm confident) you will do so again.

[lukasberger]

Let's keep perspective. We aren't talking about an overhaul. All in all, the engine and game is very good. Tons of historical detail. Beautiful games. The deeper you scratch the more that is there, though in a relatively simple display. Brilliant game design.

Comparing this to something like War in the Pacific, the depth is comparable in terms of supply, cohesion, combat mechanics, etc. But if you've played War in the Pacific, it's a click fest and a monsterous effort to undertake. Far too detailed for a game of that size and magnitude. Each turn (1 day in a 1200 hundred day war), requires hours if you want to be successful at it. I get a similar amount of depth from AGEOD games with a heck of a lot less clicking and it doesn't take hours for each turn. I got to the point where I dreaded a WITP turn because of the sheer scope and effort involved.

There's quick fixes to reduce the number of events and longer term fixes which could be a layer added to interpret what the engine is currently doing and translate that into some type of DB call. These could be done without a massive overhaul. Heck a simple global variable for faction that's available to the scripts would take perhaps a day or two to implement and reduce scripts by a significant percent (at least 50%)

So we aren't talking a year. We are talking perhaps months. A conversion program could reduce the number of events without having to redo all of the game files. Another conversion program could build a database. An interpretation layer could enable DB access without changes to the engine.

If they take my suggestion and add a country concept to the data relationships, including the distance between countries (or come up with a dynamic check during turn execution which WOULD require a database for performance), then that would definitely push out on the delivery but provide for a lot more flexibility when dealing with multiple minor countries, who owns them and what effect ownership has on neighbors, etc...

I don't think this is a matter of technical expertise at AGEOD. I believe they've tried to extend their code base, which was built for a 2 faction game, into something it wasn't designed to do (7-8 player games). There have been countless massive software companies who have done the exact same thing.

At this point it's a choice for them.
1) Enable 7 players in WON, but only 2 factions similar to what Altaris did in EAW Ultimate Mod. 7 player but only 2 factions and the diplomacy system there enables trying to swing Italy one way or another. Each faction has it's own money, rail pool, build pool, etc..
2) Enable 7 independent players in WON, and make changes to the engine to support it.

Great post, love this!

[lukasberger]

Just wanted to apologize to PhilThib and Pocus and all for my last big post. It was way too strong and aggressive.

It was late and I was tired and was cranky and had just been driving myself crazy wrestling with the db and CSV splitter working on mods for PON and for ACW2.

As I mentioned, you guys make the best games, and all you do is very much appreciated.

I'd just really, really like to see a db structure eventually implemented that would be easier to work with. If that could happen, I think you guys would be surprised at how much modding interest there would be in the games, and how much cool stuff people would work on coming up with.

As it is while the games themselves are fantastic, modding them is just frustrating and sadly feels more like work than fun at times

[veji1]

Just wanted to apologize to PhilThib and Pcus and all for my last big post. It was way too strong and aggressive.

It was late and I was tired and was cranky and had just been driving myself crazy wrestling with the db and CSV splitter working on mods for PON and for ACW2.

As I mentioned, you guys make the best games, and all you do is very much appreciated.

I'd just really, really like to see a db structure eventually implemented that would be easier to work with. If that could happen, I think you guys would be surprised at how much modding interest there would be in the games, and how much cool stuff people would work on coming up with.

As it is while the games themselves are fantastic, modding them is just frustrating and sadly feels more like work than fun at times

I think the devs know that even when we post harsh criticism which doesn't help their publicity, we are still big fans of their games. I am a big fan of my 4 year old, doesn't mean that he doesn't drive me crazy sometimes !

[PhilThib]

Indeed, nor harm done. Criticism is healthy and helpful. and we are always interested in learning stuff.

Lukasberger, could you extrapolate a bit on how you see a "better DB structure", so we can figure out what to change?

[lukasberger]

Lukasberger, could you extrapolate a bit on how you see a "better DB structure", so we can figure out what to change?

Sure, I'll do my best to prepare a useful and informative post for you soon! Just want to make sure to get it right, and provide something that'll be really useful to you

[lukasberger]

Sure, I'll do my best to prepare a useful and informative post for you soon! Just want to make sure to get it right, and provide something that'll be really useful to you

I would just mention in the mean-time though that the db related posts in this thread from myself, veij1 and vicberg in this thread are good summaries of the issues I have with the db.

[vicberg]

That's simple. Managing thousands of scripts via excel spreadsheets and CSVSplitter is a sure method for creating errors. You need a real database, one that enforces data integrity. One that allows for SQL queries against your data comparing and verifying data and easy global changes. One that ideally you use to generate your game files OR your new game engine utilizes for performance and flexibility.

You have 5000 models files. 3000+ units files. 2500 scripts files. Multiple other files I'm not mentioning. Each file contains anywhere from 20-50+ individual pieces of information. You need a real database. Excel spreadsheets are not a database

BTW: I wrote scripts that have loaded factions/regions/events/models into a database (I have oracle installed on mine, but it could be any, including shareware). I've been running SQL queries against these. I've found a few guard units that do not have the *guard* attribute by doing an comparison via SQL. I could do more thorough SQL checking if I felt like it, but I've been focusing on other things.

[veji1]

That's simple. Managing thousands of scripts via excel spreadsheets and CSVSplitter is a sure method for creating errors. You need a real database, one that enforces data integrity. One that allows for SQL queries against your data comparing and verifying data and easy global changes. One that ideally you use to generate your game files OR your new game engine utilizes for performance and flexibility.

You have 5000 models files. 3000+ units files. 2500 scripts files. Multiple other files I'm not mentioning. Each file contains anywhere from 20-50+ individual pieces of information. You need a real database. Excel spreadsheets are not a database

BTW: I wrote scripts that have loaded factions/regions/events/models into a database (I have oracle installed on mine, but it could be any, including shareware). I've been running SQL queries against these. I've found a few guard units that do not have the *guard* attribute by doing an comparison via SQL. I could do more thorough SQL checking if I felt like it, but I've been focusing on other things.

+1.

Basically all the in game "data" (units, events, settings, etc..) is spread over many many many different documents. It forces the engine to "turn" pages looking for stuff, it's slow and it favours errors seeping through.

[lukasberger]

That's simple. Managing thousands of scripts via excel spreadsheets and CSVSplitter is a sure method for creating errors. You need a real database, one that enforces data integrity. One that allows for SQL queries against your data comparing and verifying data and easy global changes. One that ideally you use to generate your game files OR your new game engine utilizes for performance and flexibility.

You have 5000 models files. 3000+ units files. 2500 scripts files. Multiple other files I'm not mentioning. Each file contains anywhere from 20-50+ individual pieces of information. You need a real database. Excel spreadsheets are not a database

BTW: I wrote scripts that have loaded factions/regions/events/models into a database (I have oracle installed on mine, but it could be any, including shareware). I've been running SQL queries against these. I've found a few guard units that do not have the *guard* attribute by doing an comparison via SQL. I could do more thorough SQL checking if I felt like it, but I've been focusing on other things.

+1.

Basically all the in game "data" (units, events, settings, etc..) is spread over many many many different documents. It forces the engine to "turn" pages looking for stuff, it's slow and it favours errors seeping through.

Yes, basically this.

Both these comments are right on, but this is also the issue from a modding perspective.

If I want to say, add a new leader (which is kind of my thing) or unit, right now I'm forced to edit both the models and units spreadsheets and not make any typos that cause the two to fail to match up. I have to set several tricky fields within both files, f.e. manually setting the proper number of models after the | symbol in the model type field etc.

Then to get the files to work in the splitter I have to re-open both files in a text editor to eliminate any extra blank cells that somehow get added or else the splitter will crash, set several options in the splitter, generate the files, move everything to the proper folders, hope everything was named correctly, regenerate the scenario if I changed any ids, and finally load the game only to spend a significant amount of time debugging the files because no matter how much care I take, there are certain to be some naming mismatches and errors.

If I want a new leader to be available at a different rank, I then have to add completely new lines to the models and units file and manually change the values in quite a few cells.

Then I have to edit events files to get the new leaders to show up etc. etc.

So to add just a couple new leaders to an AGEOD game might take me something like 30-60 minutes all said and done and is frustrating as well as time consuming. Not to make comparisons to a competitors game, but when I do the same thing in a Paradox game (even though I much prefer AGEOD games overall), it takes me maybe 5 minutes because I literally only have to edit one file and 1-5% of the amount of overall lines to accomplish the exact same result and the only way I get errors is if I've mis-formatted the data, not from having to ensure that several fields match each other perfectly over several different files.

[veji1]

So to add just a couple new leaders to an AGEOD game might take me something like 30-60 minutes all said and done and is frustrating as well as time consuming. Not to make comparisons to a competitors game, but when I do the same thing in a Paradox game (even though I much prefer AGEOD games overall), it takes me maybe 5 minutes because I literally only have to edit one file and about 5% of the amount of overall lines to accomplish the exact same result and the only way I get errors is if I've mis-formatted the data, not from having to ensure that several fields match each other perfectly over several different files.

Soooo true. And so frustrating. I remember EUII back in the day, I made myself a fictional mod for a byzantine revival where I would basically copy the byzantine leaders and events (religioux crisis, etc) of the 619-1020 period to the 1419-1820 time line, so I made up Heraklius as first emperor, etc.. with military leaders I could find, with the political and religious crisises (Iconoclasm, etc...). Well it was long ago and I kept it simple but I remember that whole mod being just a couple of evenings work once I had the material (lists of leaders, their stats, the events, etc). No need to triple check, it was all in the event file of the Byzantine empire at the time. One file only for everything, all I had to do was type it correctly. In Ageod game it is just so much more compllicated.. And it's a shame because I love those games to bits.

[vicberg]

I get around it by writing python programs that reformat or make global changes to the data files in the mod directory I'm working with. I have full copies of all the data files. Right now, I have new strings for the RGD cards I've created. Major pain to open the Excel Local Strings, modify and save, so I may write a program that appends what I want. This way, new release come in and I run programs to apply my mods with a single click. Otherwise, it's truly awful.

But the real reason for a database is managing the massive volume of data. There's probably 25-50+ spreadsheets to create this data. Spreadsheets are not easy to work with, not easy to filter, just not a good way to manage a game that is this data intensive.

With a database, then I can go into data driven designs. Meaning you don't hard code, but rather let the data drive the processing. Right now, it's a very hard coded game.

[veji1]

I get around it by writing python programs that reformat or make global changes to the data files in the mod directory I'm working with. I have full copies of all the data files. Right now, I have new strings for the RGD cards I've created. Major pain to open the Excel Local Strings, modify and save, so I may write a program that appends what I want. This way, new release come in and I run programs to apply my mods with a single click. Otherwise, it's truly awful.

But the real reason for a database is managing the massive volume of data. There's probably 25-50+ spreadsheets to create this data. Spreadsheets are not easy to work with, not easy to filter, just not a good way to manage a game that is this data intensive.

With a database, then I can go into data driven designs. Meaning you don't hard code, but rather let the data drive the processing. Right now, it's a very hard coded game.

True, and it's why it requires abilities like yours to really delve into it and be able to sift through all the layers. Beotians like us just end up trying not to screw things up when modding and just wonder why the engine seems to work this way in many aspects of the game.

[vicberg]

Here's an example of a "more" data driven design:

1) Have the engine only bring in events <= current date making sure that there' s a mindate on all events. Engine isn't looking through thousands of events each turn to determine what has fired, what will fire and what needs to fire
2) Track used events in a database, so the engine can quickly ignore what it doesn't need anymore. This will enable not only better performance but also more in game events without slowing down the game
3) Enable Faction, Date and a few other fields to be available to all events, so now many of these events can become generic rather than hard coded for all powers. Front End determines who gets what generic events, who clicked on a generic event (factional modifiers are a sample generic) and the generic event adds the modifier to the faction. The engine checks against a database, determines that this modifier is already added and removes the event from that power. So it's similar processing to #2
4) Remove the need for locked/on/AI/off/use (or fire event) for each event. This is truly a nightmare to manage or to build from scratch. A single event is placed out there and the Front End determines locked/unlocked/AI/off/Use (or fire event). Add a script command that determines if the event is displayed to the user as an option (either locked based on not meeting the criteria or unlock and both based on mindate) or not displayed to the user at all and fires upon meeting the criteria. The front end then determines that the user has clicked the event (if displayed as an option) and fires it off.
5) With a database, you don't need to manage each and every individual piece of information on a model. You can capitalize on your "common" model template that's brought into each model and build more factional commons, such as "common french template" tagged to the model. If I were you, I would change the approach, which is CURRENTLY to bring in a common template and then override the common parameters . Your approach is increasing the already high volume of data.
6) With a database, you would have many more options to reduce volume and errors resulting in volume. For example, have a common template and put in place a % increase or decrease (or +/- modifier) based on model type and faction. This data would be at a factional level and could be further increased by factional modifiers. THEN override the specific models that you think deserve it. But the majority of models come down to very few commons, with factional level data that makes percent changes, a few specific model overrides and factional commons that determine color, etc..you could even rip names of the models and build that dynamically so the models themselves aren't hard wired, they become more generic and when you build the game for the first time, name is matched with model type, matched with factional commons, matched with template commons and voila, you have yourself a data driven database without the massive hard coding.

[vicberg]

True, and it's why it requires abilities like yours to really delve into it and be able to sift through all the layers. Beotians like us just end up trying not to screw things up when modding and just wonder why the engine seems to work this way in many aspects of the game.

Let me give you an example of what I've had to do with programs

1) A program to make global changes
2) A program to load data into a db, so I can sift through what is going on
3) A program to split out all events from the mass number of .SCT files. Each event becomes it's own file and is placed in a new directory
4) A program to determine the turn and sift through the individual event files and move those files into an unneeded directory
5) A program to determine the used events and move those to a used directory
6) A program to sift through host file to determine where RGD cards have been played in order to create new event files to manage satellite, annexation, liberation, with some events ongoing.
7) And finally, I bring it all together by bringing all events back into the main scenario .sct file, which is brought in by the engine.

I have a few challenges yet to figure out. How am I going to deploy these programs within the mod, since a few of them need to run and poll through host file each turn in order to figure out what's happened. How can I get this program to kick off automatically when a turn has been run? How can I manage multiple games for a user when the engine uses a single event directory?

I've got a few things to figure out.

I can say that performance has increased dramatically as I've been able to remove 1/2 of the events (used or unneeded) from the engine in 1805.

[veji1]

Let me give you an example of what I've had to do with programs

1) A program to make global changes
2) A program to load data into a db, so I can sift through what is going on
3) A program to split out all events from the mass number of .SCT files. Each event becomes it's own file and is placed in a new directory
4) A program to determine the turn and sift through the individual event files and move those files into an unneeded directory
5) A program to determine the used events and move those to a used directory
6) A program to sift through host file to determine where RGD cards have been played in order to create new event files to manage satellite, annexation, liberation, with some events ongoing.
7) And finally, I bring it all together by bringing all events back into the main scenario .sct file, which is brought in by the engine.

I have a few challenges yet to figure out. How am I going to deploy these programs within the mod, since a few of them need to run and poll through host file each turn in order to figure out what's happened. How can I get this program to kick off automatically when a turn has been run? How can I manage multiple games for a user when the engine uses a single event directory?

I've got a few things to figure out.

I can say that performance has increased dramatically as I've been able to remove 1/2 of the events (used or unneeded) from the engine in 1805.

Gee man, that's lots of work from a very qualified man if one sees it as a player working to improve/mod the game. But if one turns the perspective around and thinks of it in terms of work hours if you were working for Ageod.. Well it's not that ginormous is it ? This is the frustrating bit : what you are doing is something they should have been doing since 2010 when they started working hard on Pride of Nations as a heavily multifactions game....

eDIT : with all due respect for the work you are doing which is fantastic coming from a fellow player of course !

[vicberg]

Gee man, that's lots of work from a very qualified man if one sees it as a player working to improve/mod the game. But if one turns the perspective around and thinks of it in terms of work hours if you were working for Ageod.. Well it's not that ginormous is it ? This is the frustrating bit : what you are doing is something they should have been doing since 2010 when they started working hard on Pride of Nations as a heavily multifactions game....

It hasn't been that much time and I've taught myself python, which is the reason why I've done this. I'm awaiting my next project so I have time and have learned a new language. All good.

[veji1]

It hasn't been that much time and I've taught myself python, which is the reason why I've done this. I'm awaiting my next project so I have time and have learned a new language. All good.

That's great. I suppose the best thing would be for you to teach the Phils a few tricks so that they can clean up quite a few of their latest games !!!

[vicberg]

I'm available if they want to contact me or capitalize on what I've done. They could translate the code base into whatever language WON is written in.

[veji1]

I'm available if they want to contact me or capitalize on what I've done. They could translate the code base into whatever language WON is written in.

Pocus !! Philthib !!! Come here !

[Taillebois]

Ok AGEOD, call this Vicberg guy. Swallow your pride; you won't die; it's not poison.

[veji1]

Ok AGEOD, call this Vicberg guy. Swallow your pride; you won't die; it's not poison.

Actually I am pretty sure deep down all they want to do is make the product better. I would say the 2 hang ups are probably fear of the cost when running a very humble little studio, and the fear of losing control of their baby in a way.

[vicberg]

I'm working with the end result, so they don't have to do anything to their spreadsheets. I can also rebuild their spreadsheets if that makes everyone more comfortable.

[vicberg]

Actually I am pretty sure deep down all they want to do is make the product better. I would say the 2 hang ups are probably fear of the cost when running a very humble little studio, and the fear of losing control of their baby in a way.

They won't lose anything. What I'm suggesting is improving upon the technology. There's short term changes that can have a dramatic impact without a major overhaul and longer term changes requiring a new engine.

For example, the event management (used, unneeded) is something that is short term and could be fairly easy to implement. The passing of Faction/Region/Date (possibly others) into each script is also short term. I could then rewrite their events using a program to capitalize on Faction/Region/Date and rewrite their spreadsheets if that's important.

[Montbrun]

All of the "under the hood" stuff is PFM to me - LOL. I'm just looking forward to having this game, which has enormous potential, working right.

[veji1]

All of the "under the hood" stuff is PFM to me - LOL. I'm just looking forward to having this game, which has enormous potential, working right.

Same for me to some extent. But what I see under the hood is scary because it is such a complicated mess of wires that you fear they won't quite be able to make the game be as good as it could withouth tidying it all up a fair bit.

[fred zeppelin]

This all great stuff!

It really isn't that difficult to get help on things like this. My nephew has a start-up software company, and he routinely hires university students to assist in discrete coding projects. In this job market, students are often willing to "intern" for free just to enhance their resumes.

This isn't a hard fix once you commit to recognizing the problem.

[bommerrang]

I guess this thread is where I put my comments about the game.
I'm playing the French under 1.02 beta Dec 21.
1.) The crashes for me have apparently been fixed. I took a poster's recommendation to delete a certain file that gets out of synch and after 43 turns, no crashes.
2.) The French player has way more than enough soldiers, WC, and horses but money is a problem. Thing is, you can play cards to get the money you need.
3.) Diplomacy is sometimes weird but diplomacy in the real world is weird. Several things the developers should consider addressing IMHO:
a.) I have full allied treaties with Brunswick and a few other minors but Austria still is attacking them even when France forced Peace on Austria. You would think that if France forces peace on a major that major must also go to peace with allied minors and can never declare war on the allied minors unless they declare war on the major.
b.) The diplomacy screen (F6) is very hard to work with. You have to click to scroll through the countries. A table format would be much better or best...click on any countries' province and have the option to go right to diplomacy...maybe their capital.
c.) when Saxony "switched sides" it didn't really switch sides and attack Prussia, it kicked both countries out (teleported). Fortunately the French could move right back in, but so could the Prussians.
4.) I'm not sure having France force peace against Austria and Prussia. just occupy all of their cities and win with the NM because it appears the NM drops back after peace when those cities revert back to Austria and Prussia.