Topic: Realistic random events

SirVer wrote:

optional feature

That is also a trigger word of mine - optional means "nobody uses it".

Where is this coming from? I have no qualms at using optional features, if i think they could be intersting. which, in my book, mostly mean "make the game more difficult". widelands is the kind of game where i want good planning, so i would not use it in this game, but i may use it in other games. I could use it in widelands too against ai, if it oonly affected me, to make things more challenging. if it affected also the ai, it would hurt it much more than me cause ai would have less capacity to cope with it, so no way. it reminds me of total annihilation. I loved those maps with random meteor showers, but it was really disappointing when after one hour the game said that i won with barely any contact because thhe enemy had been completely destroied by said meteors.

Top

Quote

Having options can be great, but we have to be careful about which ones we pick, and that we don't get too many.

From the coding side, every line of code will potentially contain a bug. So, if you program an option that isn't used much, chances are good that this bug won't be both triggered and reported until after the next release. And then you need to spend time to hunt it down and fix it. Also, the bigger the code base, the harder it is for new programmers to find their way around. So, less code is good, frequently used code is good.

From the user's point of view, I expect that most people won't even look at the options unless something annoys them. So, this option probably would have to be visible within the game starting screen so that people notice it. There is already a lot going on in these screens, making it harder for the user to start a game. Every option means that the user will have to make up his/her mind about it.

Here are 2 entertaining articles on why options can be bad for the user:

http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html

http://www.joelonsoftware.com/items/2006/11/21.html

Now, should playing with disasters get really popular, we might consider it again in the future. To implement the range of ideas that OP had into the core engine would take a lot of time. So, this is why I think creating a scenario to try things out would be the best option. E.g. you could already simulate road accidents by ripping a flag and place it back, fires by ripping a building, etc. Terrains can obviously already be changed. Then design the messages the user would get, and write the randomizing part. If you are working on such a scenario and need more functions exposed to the Lua interface, this is certainly something we can talk about.

Busy indexing nil values

Top

Quote

I agree with SirVer and GunChleoc. For scenarios it could be great. Examples and how to get started with scenarios where given.

To claim something is allways a lightweight thing. If you want such things, make yourself familiar with the code and provide the community with your great results

Top

Quote

For me this idea is on the line between making the game more interesting and making the game random.

It can be now implemented with LUA scripting and some scenarios edits (also LUA?). Now we can play with and without scenario things. So it is good enough to use this engine in my opinion. We should consider adding a better front-end of it? Maybe some window when anybody can "click" everything and then run. Also it is good to provide a window where we can change all the LUA code, without going to files and modifying them outside the game.

Have you played Trident of fire map? There is something similar to your idea: temporary lava fields on the volcano.

einstein13
calculations & maps packages: http://wuatek.no-ip.org/~rak/widelands/
backup website files: http://kartezjusz.ddns.net/upload/widelands/

Top

Quote

We should consider adding a better front-end of it? Maybe some window when anybody can "click" everything and then run. Also it is good to provide a window where we can change all the LUA code, without going to files and modifying them outside the game.

It sounds like you suggest adding a UI for scripting and/or adding a text editor into the game. Both are things that I'd rather not do - a ton of work that will not benefit the players, but only the very small fraction of map makers. I think we should focus our time making map making as efficient as possible, but implementing a crappy UI from scratch is not the fastest way towards that. Frankly for the map editor I see two choices: either break it out into a separate binary that uses a real gui tool kit (e.g. QT). Lot's of commercial game use this approach and it seems pretty sound. Or make it even more minimalistic and think about how we can integrate with a separate text editor in a simpler fashion.

If I muster some energy, time and if situation permits then I will try to implement such optional feature (for map generator) Especially I support this idea: dividing all map to sectors (even simple squares). For each sector are randomly picked probabilities (from the map creator's ranges), which describes specific accident events. And if building is constructed on some specific sector, then this building is subject to events probabilities of that sector. Transport accidents fit to this method too.

If I would do such a task, I'd estimate 2-3 weeks of fulltime work to do it. I think you will have a faster path to success looking into Lua scripting in a scenario - that could also be integrated into the engine, but it will be much easier to get started.

Top

Quote