Thread: [Widelands-public] Post Release Discussion of build 18 and Cap over mill.
Status: Beta
Brought to you by:
sirver
From: Holger R. <Hol...@gm...> - 2014-02-22 14:09:03
Attachments:
smime.p7s
|
Heyho Folks, build 18 is out of the door and I can only say again: great job to everybody involved. The feature freeze length was suboptimal this time and generally I felt that new features where not well tested (especially obvious corner cases). I hope that we can improve on that for the next release, but otherwise I’d say this was a damn fine release and we can be proud. This directly brings us to the cap over mill part of this email. A short reminder what that is: Everybody that feels like working on Widelands in the next time can write what he/she plans to work on for the next build. Just a general plan of what to expect. This time, I want to conserve the statements so that it is easier to see next time what actually got done and which plans became outdated rather quickly. I’ll copy and paste anybodys plans into the document, but you can already read through build 17 analysis here: https://docs.google.com/document/d/1LlpNsWLYO-x7NtXDdkL2MR4D4GreLb03ccMqp4Zph2M/edit# I’ll grant everybody edit rights on this document that asks for it. For my part, this is my plan for build 19: ---- I want to merge the better lua serialization - this will break all safegames. I then want to clean up the code base - remove useless options, fix some style inconsistencies, remove compatibility code for safegames, rework the cmake build files. I also want to revisit the stacked animations idea and finish up this code. And I want to look into adding a proxy to the metaserver, so that no open ports are required on the client side anymore. Oh and I have some plans for a better messages window… but that all sounds like so much already :). Generally speaking I believe we are moving towards a 1.0 version with build 19 or at the latest build 20. My biggest project though will be to explore the idea of a Widelands Foundation - essentially a way to sell Widelands on AppStores and collect the money for non-profit charities like Child’s play or WWF or something. I hope that Widelands can do a little more good for the World than just being an awesome time sink. I started talking to lawyers if there is a good organizational structure for such an idea. —— I’ll send out a separate Email about the Widelands Foundation idea. So, what are your plans for b19? Cheers, Holger |
From: Matthias H. <in...@an...> - 2014-02-22 15:19:22
|
Hey everyone, just recently I decided to get back on hacking on Widelands and right now have huge plans for build 19 but little time. My main goal is to improve the structure of the code, especially the main class is really a mess right now and there is no clear main loop. To improve the situation this is my personal roadmap: 1.) Create a GUI class that is responsible for handling the GUI and is called from the WLApplication main loop to do so. The Panel::run() method is removed and its purpose is split into the WLApplication main loop and the GUI class. These changes reduce the size of the WLApplication file by several hundred lines. I already have some proof of concept code on my HDD which I will push to launchpad soon^(TM) to get some feedback. However this might conflict with the SDL2 changes in some places. 2.) The GUI class also adds the possibility to create GUI elements from XML files instead of hard coding the GUI. This makes UI adjustments for small screens and touch devices possible! The idea is to have the whole GUI written in XML+Lua which also makes it easier to create special elements and dialog for scenarios. I already have successfully built the main menu from an XML file as proof of concept. However it is really necessary to have the GUI class in place first. 3.) To further clean up the WLApplication class and continue the work that I wanted to have done for build 18, I will try to figure out a proper way to handle command line arguments, the config file, default values and option settings. That is everything I have planned so far. The main problem I see right is the interference with other big changes to the Widelands code, like the SDL2 migration or the ingame help (we should not create a lot of LUA help files if we decide to create a XML+LUA GUI). Best regards, Matthias Am 22.02.2014 15:08, schrieb Holger Rapp: > Heyho Folks, > > build 18 is out of the door and I can only say again: great job to everybody involved. The feature freeze length was suboptimal this time and generally I felt that new features where not well tested (especially obvious corner cases). I hope that we can improve on that for the next release, but otherwise I'd say this was a damn fine release and we can be proud. > > This directly brings us to the cap over mill part of this email. A short reminder what that is: Everybody that feels like working on Widelands in the next time can write what he/she plans to work on for the next build. Just a general plan of what to expect. This time, I want to conserve the statements so that it is easier to see next time what actually got done and which plans became outdated rather quickly. I'll copy and paste anybodys plans into the document, but you can already read through build 17 analysis here: https://docs.google.com/document/d/1LlpNsWLYO-x7NtXDdkL2MR4D4GreLb03ccMqp4Zph2M/edit# > > I'll grant everybody edit rights on this document that asks for it. > > For my part, this is my plan for build 19: > > ---- > I want to merge the better lua serialization - this will break all safegames. I then want to clean up the code base - remove useless options, fix some style inconsistencies, remove compatibility code for safegames, rework the cmake build files. I also want to revisit the stacked animations idea and finish up this code. And I want to look into adding a proxy to the metaserver, so that no open ports are required on the client side anymore. Oh and I have some plans for a better messages window... but that all sounds like so much already :). > Generally speaking I believe we are moving towards a 1.0 version with build 19 or at the latest build 20. > > My biggest project though will be to explore the idea of a Widelands Foundation - essentially a way to sell Widelands on AppStores and collect the money for non-profit charities like Child's play or WWF or something. I hope that Widelands can do a little more good for the World than just being an awesome time sink. I started talking to lawyers if there is a good organizational structure for such an idea. > ------ > > I'll send out a separate Email about the Widelands Foundation idea. > > So, what are your plans for b19? > > Cheers, > Holger > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > > > _______________________________________________ > Widelands-public mailing list > Wid...@li... > https://lists.sourceforge.net/lists/listinfo/widelands-public |
From: Holger R. <Hol...@gm...> - 2014-02-22 16:13:24
Attachments:
smime.p7s
|
On 22.02.2014, at 16:06, Matthias Horne <in...@an...> wrote: > Hey everyone, > > just recently I decided to get back on hacking on Widelands and right now have huge plans for build 19 but little time. My main goal is to improve the structure of the code, especially the main class is really a mess right now and there is no clear main loop. To improve the situation this is my personal roadmap: > > 1.) Create a GUI class that is responsible for handling the GUI and is called from the WLApplication main loop to do so. The Panel::run() method is removed and its purpose is split into the WLApplication main loop and the GUI class. These changes reduce the size of the WLApplication file by several hundred lines. I already have some proof of concept code on my HDD which I will push to launchpad soon™ to get some feedback. However this might conflict with the SDL2 changes in some places. that sounds great > > 2.) The GUI class also adds the possibility to create GUI elements from XML files instead of hard coding the GUI. This makes UI adjustments for small screens and touch devices possible! The idea is to have the whole GUI written in XML+Lua which also makes it easier to create special elements and dialog for scenarios. I already have successfully built the main menu from an XML file as proof of concept. However it is really necessary to have the GUI class in place first. Uhh - I am not a fan of defining the UI in XML. First, xml is really terrible to work with and secondly the UI does not change so frequently that we need something dynamic there in the first place. Can you split this change from the others so it can be discussed and reviewed separately? I am also interested why you think it is better than using the programmatic UI that we have with UI::Box? > > 3.) To further clean up the WLApplication class and continue the work that I wanted to have done for build 18, I will try to figure out a proper way to handle command line arguments, the config file, default values and option settings. That sounds good too - though I think what we have in place is not bad - maybe not perfect. But I would not invest too much time into this. > > That is everything I have planned so far. The main problem I see right is the interference with other big changes to the Widelands code, like the SDL2 migration or the ingame help (we should not create a lot of LUA help files if we decide to create a XML+LUA GUI). > > Best regards, > Matthias > > > Am 22.02.2014 15:08, schrieb Holger Rapp: >> Heyho Folks, >> >> build 18 is out of the door and I can only say again: great job to everybody involved. The feature freeze length was suboptimal this time and generally I felt that new features where not well tested (especially obvious corner cases). I hope that we can improve on that for the next release, but otherwise I’d say this was a damn fine release and we can be proud. >> >> This directly brings us to the cap over mill part of this email. A short reminder what that is: Everybody that feels like working on Widelands in the next time can write what he/she plans to work on for the next build. Just a general plan of what to expect. This time, I want to conserve the statements so that it is easier to see next time what actually got done and which plans became outdated rather quickly. I’ll copy and paste anybodys plans into the document, but you can already read through build 17 analysis here: https://docs.google.com/document/d/1LlpNsWLYO-x7NtXDdkL2MR4D4GreLb03ccMqp4Zph2M/edit# >> >> I’ll grant everybody edit rights on this document that asks for it. >> >> For my part, this is my plan for build 19: >> >> ---- >> I want to merge the better lua serialization - this will break all safegames. I then want to clean up the code base - remove useless options, fix some style inconsistencies, remove compatibility code for safegames, rework the cmake build files. I also want to revisit the stacked animations idea and finish up this code. And I want to look into adding a proxy to the metaserver, so that no open ports are required on the client side anymore. Oh and I have some plans for a better messages window… but that all sounds like so much already :). >> Generally speaking I believe we are moving towards a 1.0 version with build 19 or at the latest build 20. >> >> My biggest project though will be to explore the idea of a Widelands Foundation - essentially a way to sell Widelands on AppStores and collect the money for non-profit charities like Child’s play or WWF or something. I hope that Widelands can do a little more good for the World than just being an awesome time sink. I started talking to lawyers if there is a good organizational structure for such an idea. >> —— >> >> I’ll send out a separate Email about the Widelands Foundation idea. >> >> So, what are your plans for b19? >> >> Cheers, >> Holger >> >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk >> >> >> _______________________________________________ >> Widelands-public mailing list >> Wid...@li... >> https://lists.sourceforge.net/lists/listinfo/widelands-public > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________ > Widelands-public mailing list > Wid...@li... > https://lists.sourceforge.net/lists/listinfo/widelands-public |
From: Matthias H. <in...@an...> - 2014-02-22 16:46:05
|
>> 2.) The GUI class also adds the possibility to create GUI elements >> from XML files instead of hard coding the GUI. This makes UI >> adjustments for small screens and touch devices possible! The idea is >> to have the whole GUI written in XML+Lua which also makes it easier >> to create special elements and dialog for scenarios. I already have >> successfully built the main menu from an XML file as proof of >> concept. However it is really necessary to have the GUI class in >> place first. > Uhh - I am not a fan of defining the UI in XML. First, xml is really > terrible to work with and secondly the UI does not change so > frequently that we need something dynamic there in the first place. > Can you split this change from the others so it can be discussed and > reviewed separately? I am also interested why you think it is better > than using the programmatic UI that we have with UI::Box? Yes these changes will (or won't) be done separately and are open for discussion (not much work went into it so far). Defining UIs is never fun, but I personally think, defining them in code is the worst. I see the following advantages in XML defined UIs: * They are easy to change without programming knowledge or recompiling the software. Therefore designers can improve the UI easily which might attract new people to help. * We can easily create two different UIs: One for desktop and one for mobile. Creating two UIs programmatical is much more difficult IMO. * Scenarios can add their own UI elements, for example to show counters or add windows which might bring up completely new ideas. * Many functions have to be exposed through the LUA API to be available for onClick events in the XML/LUA UI file. This will add missing functions to the LUA API, which might be beneficial for scenario or AI development. * A lot of classes can be removed, because they just stick UI elements together. Many of these points are just personal taste of course and we have a lot of time to collect different opinions, since I won't start with this feature soon. Regards Matthias |
From: Nicolai H. <pre...@gm...> - 2014-02-24 10:00:55
|
Hi especially to Matthias and Teppo, these are just some observations from reading the thread. Take them as well-intended suggestions/advice which can be ignored based on technical merit. I am not doing inline quotes because this mail really has two "parent" mails that it replies to. First, about making the UI more scriptable: I like this, and had even toyed with the idea a long ago when I was still active. However, I am not so fond of an XML-based approach. Making the UI fully programmable from Lua would be a great thing for scenarios and other random experiments here and there. However, if the Lua interface is done well, then the benefits of an additional "XML interface" are very small compared to the costs of maintaining a third way to define UI elements. Most importantly however, Teppo's goal of starting a Widelands game entirely from the command line would mesh very well with Matthias' goal of refactoring the main loop and making the UI scriptable. If the latter is done, the former should be doable just by changing the Lua script that controls the main loop. So the two of you should really work together! Cheers, Nicolai -- Lerne, wie die Welt wirklich ist, aber vergiss nie, wie sie sein sollte. |
From: Teppo M. <tep...@ce...> - 2014-02-23 09:49:16
|
On Sat, Feb 22, 2014 at 03:08:53PM +0100, Holger Rapp wrote: >Heyho Folks, Hello. >Everybody that feels like working on Widelands in the next time can write >what he/she plans to work on for the next build. Just a general plan of what >to expect. Widelands yields almost all other things, so it could easily happen that I do not do a thing. However, these seem interesting at the moment of writing: >So, what are your plans for b19? - Write another AI. I would probably aim for a CPU-light version, which does not perform worse than the current one. - Make it possible to run an entire game from command line, without UI. The purpose of this would be to characterize map starting points using AI only players and repeated matches, plus playing AIs against each other. This could also be used to find maps where the AI stalls, to make it easier to find AI weaknesses. - Small improvements here and there. I would like to add a way to change the working triggers for various production sites to economy settings, for example. - Add features to the editor to make symmetric maps more easy to do; either copy&paste/paste_rotatedinverted region, or through a possibility to multi-apply each user action. I am a bit unsure on how this should be done. It is 100% certain that I will not do all the above. The most likely outcome is that I do none of the above; there is also a fair change that I manage to get some of the above done. Feedback on which of the above would be improvements from you points of view too is appreciated. I do not intend to reserve any topics. If you are interested, feel free to improve the odds of a working solution by doing it yourself! An e-mail reducing odds of duplicate work would be nice. >My suggestion is the following: Let’s bring Widelands on tablets and into >app stores and sell it. A small amount - maybe 2 euros or so - and with a >fat disclaimer that you can play it for absolutely free on your computer. Widelands on tablets is a great idea. Assuming that somebody goes through the trouble to port Widelands to tablet(s): Since Widelands is GPL, the touchscreen UI might have to be GPL as well. If this is true, everybody can build self for a no-cost WL experience. I guess we would not be able to prohibit somebody from uploading such a package to a marketplace with a smaller or zero price tag, though the lawyers probably know better. The disclaimer should say that WL is free software, and the price should be thought as a donation to the WL foundation. Of course it is OK to say that downloads to computers are free on WL website, but we should not give the impression that the only way to have WL on tablet would be though the wallet. Regards, Teppo |
From: Peter S. <sea...@gm...> - 2014-02-23 10:56:40
|
Hi, Am 23.02.2014 10:48, schrieb Teppo Maenpaa: > - Write another AI. I would probably aim for a CPU-light version, > which does not perform worse than the current one. Surely a big task, however very useful especially for the mobile version as there most people will play offline + have weak cpu > - Make it possible to run an entire game from command line, without UI. The > purpose of this would be to characterize map starting points using AI only > players and repeated matches, plus playing AIs against each other. This could > also be used to find maps where the AI stalls, to make it easier to find AI > weaknesses. At least the basic functionality is already available via the dedicated server module. What seems to be missing for your plan until now is the control over the game speed and the save load functionality. However you could pretty much start the game from a client UI, set the desired speed and unconnect. The autosave functionality should do the rest. > - Add features to the editor to make symmetric maps more easy to do; either > copy&paste/paste_rotatedinverted region, or through a possibility to > multi-apply each user action. I am a bit unsure on how this should be done. I guess a mirror tool would be more straight forward as the "multiply user action tool" would either be: * Applied from the beginning of the map creation and therefore would pretty much be the same as creating a small map and mirroring it afterwards * Could lead to problems if turned on after the map has already been worked on without the tool or has been loaded from a map file that was not (100%) created with this tool. E.g. trying to place a duck on a coordinate which indeed is water but is a none water terrain on the other parts of the map, placing resources, etc. |
From: Holger R. <Hol...@gm...> - 2014-02-23 12:03:19
Attachments:
smime.p7s
|
On 23.02.2014, at 10:48, Teppo Maenpaa <tep...@ce...> wrote: > On Sat, Feb 22, 2014 at 03:08:53PM +0100, Holger Rapp wrote: > >> So, what are your plans for b19? > > - Write another AI. I would probably aim for a CPU-light version, which does > not perform worse than the current one. That is a good idea. I would love to kill the current AI - the code is a minefield. > - Make it possible to run an entire game from command line, without UI. The > purpose of this would be to characterize map starting points using AI only > players and repeated matches, plus playing AIs against each other. This could > also be used to find maps where the AI stalls, to make it easier to find AI > weaknesses. This would also be very useful for ./regression_test.py. For this to work the logic must be made fully speed independant, so that a game can be run basically as quick as possible. Also saves right now happen at rather arbitrary times - a cmd_queue packet for saving must be introduced. Also, an approximation for this is SDL_VIDEODRIVER=dummy - but only an approximation. > - Small improvements here and there. I would like to add a way to change the > working triggers for various production sites to economy settings, for > example. > > - Add features to the editor to make symmetric maps more easy to do; either > copy&paste/paste_rotatedinverted region, or through a possibility to > multi-apply each user action. I am a bit unsure on how this should be done. that would be awesome - some symmetries are easier than others, but having any tool would already be pretty useful. > > It is 100% certain that I will not do all the above. The most likely outcome > is that I do none of the above; there is also a fair change that I manage to > get some of the above done. Feedback on which of the above would be > improvements from you points of view too is appreciated. That is obvious - that is why it is called cap over mill :). > > I do not intend to reserve any topics. If you are interested, feel free to > improve the odds of a working solution by doing it yourself! An e-mail > reducing odds of duplicate work would be nice. > > >> My suggestion is the following: Let’s bring Widelands on tablets and into >> app stores and sell it. A small amount - maybe 2 euros or so - and with a >> fat disclaimer that you can play it for absolutely free on your computer. > > Widelands on tablets is a great idea. Assuming that somebody goes through > the trouble to port Widelands to tablet(s): > > Since Widelands is GPL, the touchscreen UI might have to be GPL as well. If > this is true, everybody can build self for a no-cost WL experience. I guess > we would not be able to prohibit somebody from uploading such a package to a > marketplace with a smaller or zero price tag, though the lawyers probably > know better. > > The disclaimer should say that WL is free software, and the price should be > thought as a donation to the WL foundation. Of course it is OK to say that > downloads to computers are free on WL website, but we should not give the > impression that the only way to have WL on tablet would be though the wallet. > > Regards, > > > Teppo > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Widelands-public mailing list > Wid...@li... > https://lists.sourceforge.net/lists/listinfo/widelands-public |
From: Peter S. <sea...@gm...> - 2014-02-23 11:06:34
|
Hi everyone, I am not yet sure how many time I'll be able to invest in Widelands in the next month, however: * I would really like to work on the proxy feature with Holger to finally remove the port forwarding, firewall opening and ipv4 barriers our current internet gaming engine has. This is more interesting than ever to me, as I am currently connected only via IPv6 and Widelands does not support pure IPv6 for opening a game. * Further seafaring needs some love (or better to say war) to implement a solution for island take over. * And finally I changed my mind concerning the auto tree spreading feature. I am still a big fan of the terrain affinity that gices a lot to the look and makes foresters less efficient on e.g. mountain terrain. However I must agree with those of you who argued that auto spreading trees lead to bigger problems than the improvements to the game. So I would be glad to disable this feature again if the majority of you agree on this point. (Small disclaimer: This however does not change the need for a "tree removing feature" of expeditions, as else players could shut up their islands by just placing trees over the whole beach. That's it for now. Let's see how far we get. :) Looking back I can just say: We've come a long way and it was more than worse. Thank you everyone who made Widelands what it is with Build18. Now let's bring it closer to 1.0 :) Cheers, Peter |
From: Holger R. <Hol...@gm...> - 2014-02-23 12:08:34
Attachments:
smime.p7s
|
On 23.02.2014, at 12:06, Peter Schwanemann <sea...@gm...> wrote: > Hi everyone, > > I am not yet sure how many time I'll be able to invest in Widelands in > the next month, however: > > * I would really like to work on the proxy feature with Holger to > finally remove the port forwarding, firewall opening and ipv4 barriers > our current internet gaming engine has. This is more interesting than > ever to me, as I am currently connected only via IPv6 and Widelands does > not support pure IPv6 for opening a game. right - lets schedule a VC over this topic. I thought a bit about a possible design, but it will need some changes in Widelands. > > * Further seafaring needs some love (or better to say war) to implement > a solution for island take over. Please use the regression_test.py and add tests for your new features. I gladly provide any help in teaching you how to write tests, add lua wrapped features and run them. > * And finally I changed my mind concerning the auto tree spreading > feature. I am still a big fan of the terrain affinity that gices a lot > to the look and makes foresters less efficient on e.g. mountain terrain. > However I must agree with those of you who argued that auto spreading > trees lead to bigger problems than the improvements to the game. So I > would be glad to disable this feature again if the majority of you agree > on this point. :) I think removing the tree spreading is a good idea. The affinity needs no adjusting really - it can still control how many trees die when they are younger. This gives map makers even some control over the randomness of the forrests you see on th map: they can simply place lots of younger trees and some will survive, some want. Old trees should just not spread anymore. > (Small disclaimer: This however does not change the need for a "tree > removing feature" of expeditions, as else players could shut up their > islands by just placing trees over the whole beach. > > That's it for now. Let's see how far we get. :) > > Looking back I can just say: We've come a long way and it was more than > worse. Thank you everyone who made Widelands what it is with Build18. > Now let's bring it closer to 1.0 :) > > Cheers, > Peter > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk > _______________________________________________ > Widelands-public mailing list > Wid...@li... > https://lists.sourceforge.net/lists/listinfo/widelands-public |