Lets learn from Spring and think about the future of Wesnoth
Moderator: Forum Moderators
Lets learn from Spring and think about the future of Wesnoth
Warning: Semi-Coherent Rambling Ahead
The spring engine has just posted a cry for help: https://springrts.com/phpbb/viewtopic.php?f=1&t=33698
It seems similar to the situation here, and I've also seen they have familiar issues like campaigns (read: games) being broken due to interface changes
I think we need a frank discussion about what Wesnoths goals are (other than "build a turn-based tactical strategy game with a high fantasy theme") and I honestly had no idea, not to mention "high fantasy" is highly subjective.
I'd like your thoughts about:
1) Is it necessary Wesnoth have short/long term goals?
2) What should they be? (prioritise!)
Discussion guidelines:
1) This is supposed to be a constructive discussion about the future, not a criticism blamefest, be positive and focus on things that should be done rather than things that shouldn't have been done.
2) Goals != Features - this isn't the thread where you ask for spherical maps. Examples of goals: "Add support for better graphics", "Make more things controllable", "Make development easier".
Thanks!
The spring engine has just posted a cry for help: https://springrts.com/phpbb/viewtopic.php?f=1&t=33698
Full list of staff here: https://springrts.com/phpbb/memberlist.php?mode=groupHokomoko wrote:Sadly, a hard truth must be faced: The Spring Engine, as a project, is understaffed. At this time, there are fewer than half a dozen developers working on each new version of the engine, and even fewer of them are able to work on the games themselves.
It seems similar to the situation here, and I've also seen they have familiar issues like campaigns (read: games) being broken due to interface changes
I think we need a frank discussion about what Wesnoths goals are (other than "build a turn-based tactical strategy game with a high fantasy theme") and I honestly had no idea, not to mention "high fantasy" is highly subjective.
I'd like your thoughts about:
1) Is it necessary Wesnoth have short/long term goals?
2) What should they be? (prioritise!)
Discussion guidelines:
1) This is supposed to be a constructive discussion about the future, not a criticism blamefest, be positive and focus on things that should be done rather than things that shouldn't have been done.
2) Goals != Features - this isn't the thread where you ask for spherical maps. Examples of goals: "Add support for better graphics", "Make more things controllable", "Make development easier".
Thanks!
Re: Lets learn from Spring and think about the future of Wes
You posted this in the Website section, but I really believe it would benefit from being in a more topical forum such as Developers’ Discussion, so I have moved it there.
As we don’t have many people onboard right now, it’s not the best time to decide what our goals for Wesnoth 1.14 and beyond should be since we don’t necessarily have the technical qualifications to make it all happen, but there is no harm in throwing some ideas around and discussing exactly where we want to go — particularly for newcomers.
The other day I made a really long list of tasks I would like to work on for 1.14 and beyond, but I obviously can’t do it all on my own, firstly because I lack the technical skills for several of them, and secondly because it’s a huge time/energy investment.
These are obviously just my own ideas and this is the first time I’ve shared them publicly for fear of making impossible promises. And, as you can see, these are primarily technical stuff that most players are not interested in. Of course the other developers may have their own ideas — some feasible, some not — so I would like to invite them to post them to this thread as well.
Long-term goals:
(?) Items marked with a question mark have not received even preliminary technical evaluation.
As we don’t have many people onboard right now, it’s not the best time to decide what our goals for Wesnoth 1.14 and beyond should be since we don’t necessarily have the technical qualifications to make it all happen, but there is no harm in throwing some ideas around and discussing exactly where we want to go — particularly for newcomers.
The other day I made a really long list of tasks I would like to work on for 1.14 and beyond, but I obviously can’t do it all on my own, firstly because I lack the technical skills for several of them, and secondly because it’s a huge time/energy investment.
These are obviously just my own ideas and this is the first time I’ve shared them publicly for fear of making impossible promises. And, as you can see, these are primarily technical stuff that most players are not interested in. Of course the other developers may have their own ideas — some feasible, some not — so I would like to invite them to post them to this thread as well.
Long-term goals:
- All mainline content (including campaigns and the Default era) with new-style portraits and essential animations
- GUI2 completely replacing GUI1, all GUI2 features implemented (including theme support and a cleaner API for UMC) (*)
- More modular game logic (combat, XP, etc.) that can be extended or replaced by UMC like it’s already done with the events WML API (and conditional statements in 1.13.0) (*)
- Add-ons and MP servers using more secure and modern technologies (*)
- Built-in game upgrader (*)
- UtBS faction concept and portraits overhaul (in progress)
- Windows upgrade packages (?)
- SDL 2/OpenGL transition (*)
- Theme UI and game rendering engine decoupling
- Recent Files menu in the editor
- WML cache options dialog (done)
- Periodic WML cache cleanup
- Dropping the SDL_ttf dependency used primarily by GUI1 and moving all legacy code to our Pango/Cairo pipeline (technical background)
- Copy-to-clipboard functionality in the MP lobby and a less dysfunctional text selection mechanism
- Built-in build and version information UI (in progress)
- GUI2 dialogs: Preferences dialog, refurnished add-on Description dialog with tabs, maybe a GUI2 port of the Add-ons Manager?
- GUI2 core: Tab container, multiline text box.
- WML/Lua API:
- Add-on registration API and UI (more on that in a DD thread I’ll post soon)
- Help pages API for add-ons
- Story screens able to be invoked from WML events (may require minor reengineering of the game rendering code and the story screens code)
- Theme UI extension API in Lua (?)
- Ability to set save points that aren’t subject to autosave deletion in WML/Lua for long/complex scenarios
- Add-ons server:
- Port redirection + client/server info protocol
- Content tags and license information
- Incremental uploads and downloads (*)
- Fancy shaders everywhere, yay! (*) (Depends on OpenGL)
- New theme UI WML API
- Spritesheets API (*)
- GUI2 dialogs: story screen, loading screen, theme UI (*) (not feasible without a GUI2 maintainer who understands and is able to adapt the core code)
(?) Items marked with a question mark have not received even preliminary technical evaluation.
Author of the unofficial UtBS sequels Invasion from the Unknown and After the Storm.
- Elvish_Hunter
- Posts: 1576
- Joined: September 4th, 2009, 2:39 pm
- Location: Lintanir Forest...
Re: Lets learn from Spring and think about the future of Wes
My personal two cents.
Some things that I'd like to see in 1.14 are:
Some things that I'd like to see in 1.14 are:
- A new ability, similar to Swarm, which instead of altering attack strikes, alters the damage
- Real long range attacks. I know that this goes against FPI #24, but this didn't stop fabi from adding the required keys inside [attack]. Now we have this unused code that should be either completed or removed.
Besides, I'm not asking to modify every mainline unit (that would be a balancing nightmare ), but simply to add support in the engine, as I know some UMC stuff that will greatly benefit from it (like the Cannon unit in Fate of a Princess, or even the Ranged Era). - Remove the 72x72 pixels limit for [item]s. Ideally, they should be handled like halos, but drawn before halos and units.
Current maintainer of these add-ons, all on 1.16:
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
The Sojournings of Grog, Children of Dragons, A Rough Life, Wesnoth Lua Pack, The White Troll (co-author)
Re: Lets learn from Spring and think about the future of Wes
I'll put in my personal, narrow-minded wishlist for things that I have been involved with:
- The OS X build issues absolutely need to be solved in 1.13/1.14. Currently, we don't even have a dmg that runs on both Yosemite (1.10) and Mavericks (1.9). Both ancestral and I know what is going on (it's the pango libraries) and we are, probably, able to solve this in principle. However, neither of us has a lot of experience with this and we don't have much time right now either. Any help with it would be very much appreciated.
- There is also the list of known OS X bugs that is shown in each release announcement.
- Micro AIs: I'll continue to fix bugs as they are found, but don't have any new development planned.
- AI bugs and "unfortunate features": there's a small number of those that I am aware of. One of them (make the old simple aspect syntax work ...) is listed on the EasyCoding wiki page. I have a couple more in my notes somewhere that I can dig out. I know in principle what needs to be done to fix most of those, but my C++ expertise is rather rudimentary, so it's not the most efficient use of my time. These should be good starter problems for somebody who would like to work on the AI.
SP campaigns: Galuldur's First Journey (1.12 & 1.14) & Grnk the Mighty (1.10 & 1.12)
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
AI experiments: Micro AIs (wiki, forum thread, known/fixed bugs), Fred, AI-demos add-on
Re: Lets learn from Spring and think about the future of Wes
Maybe is time for building construction feature? Maybe a limited one (like some kind of units that can build if they don't move). BoW is a fantastic game, but its features make the experience limited, so unless you add a new feature, i don't see why someone would be interested in playing after years of the same content.
Re: Lets learn from Spring and think about the future of Wes
Ahem... are you aware that the addon server has multiple addons that allow you to build a settlement? 'Cities of the Frontier' and 'GambCiv' are two I know about, and there's probably more out there.
If you want to have one of these campaigns shipped with the base game, chances are that won't happen - you'd need a vote from the developers and someone willing to maintain the campaign so that it stays up-to-date.
If you want to have one of these campaigns shipped with the base game, chances are that won't happen - you'd need a vote from the developers and someone willing to maintain the campaign so that it stays up-to-date.
Re: Lets learn from Spring and think about the future of Wes
Well, i have given it a thought and this is a list of things i dislike about the game, and my naive solution.
* I think we can agree the main selling point of bow is its mp gameplay, and i think every consideration is executed from this point of view. But mp is actually a pain in the ass: Finding a new match that gets my interest is hard. You usually have to wait too much time until the required number of players is filled. It is not unusually that some of them leave the game at the very start, forcing you to remake the match. And lastly, for every minute you put in the match you have to wait like 5. This means that playing bof is actually not playing it, but waitting.
* I like the features of bow, but after nearly 10 years playing it, they have nothing new to offer. It is not the same situation as, say, counter strike, which is a simple game and easy to get started. BoW is easy but, after all, a strategic game. And strategic games earn more with more gameplay considerations, not less. I wouldn't mind to see another consideration included in the game.
* For me, one of the things that attracted me to the game was that i could run it in my old computer. This everyday is becoming no longer true. I dont see why the game has to consume so much ram and cpu cycles, but it wasn't the case in the old days. Since most of the people that are willing to put their time in a pixelated game dont have state-of-the-art computers, i don't think it is wise to make the game require a new computer.
My naive solution, as i said from the beggining, is to leave BoW as it is. It is perfect, and most of the additions that other users have posted won't make any difference in the user experience. The game is not going to change, and i'd say programmers prefer to colaborate in a captivating project, not one that is, in short, finished.
So, why dont we think on how to improve the gameplay? all those things that, over the years, we liked to see in wesnoth but we know it would violate its gameplay. Why dont we accept that bow is 'done' (in a good way) and think about wesnoth 2.0 ? For example, in bof2.0 we could see simultaneous turns (like Age of Wonders)
* I think we can agree the main selling point of bow is its mp gameplay, and i think every consideration is executed from this point of view. But mp is actually a pain in the ass: Finding a new match that gets my interest is hard. You usually have to wait too much time until the required number of players is filled. It is not unusually that some of them leave the game at the very start, forcing you to remake the match. And lastly, for every minute you put in the match you have to wait like 5. This means that playing bof is actually not playing it, but waitting.
* I like the features of bow, but after nearly 10 years playing it, they have nothing new to offer. It is not the same situation as, say, counter strike, which is a simple game and easy to get started. BoW is easy but, after all, a strategic game. And strategic games earn more with more gameplay considerations, not less. I wouldn't mind to see another consideration included in the game.
* For me, one of the things that attracted me to the game was that i could run it in my old computer. This everyday is becoming no longer true. I dont see why the game has to consume so much ram and cpu cycles, but it wasn't the case in the old days. Since most of the people that are willing to put their time in a pixelated game dont have state-of-the-art computers, i don't think it is wise to make the game require a new computer.
My naive solution, as i said from the beggining, is to leave BoW as it is. It is perfect, and most of the additions that other users have posted won't make any difference in the user experience. The game is not going to change, and i'd say programmers prefer to colaborate in a captivating project, not one that is, in short, finished.
So, why dont we think on how to improve the gameplay? all those things that, over the years, we liked to see in wesnoth but we know it would violate its gameplay. Why dont we accept that bow is 'done' (in a good way) and think about wesnoth 2.0 ? For example, in bof2.0 we could see simultaneous turns (like Age of Wonders)
Re: Lets learn from Spring and think about the future of Wes
I agree, I have a bunch of old computers, I can run well old versions of BFW on them, but it seems that with every new version you need a new PC to play smoothly, I don't see why the game demands always more power, but substantially it remains the same 2D game, yes revamped graphics and some new features, but that does not justify the increase in requirements tom play it well, its because the code gets more messy over time ?* For me, one of the things that attracted me to the game was that i could run it in my old computer. This everyday is becoming no longer true. I dont see why the game has to consume so much ram and cpu cycles, but it wasn't the case in the old days. Since most of the people that are willing to put their time in a pixelated game dont have state-of-the-art computers, i don't think it is wise to make the game require a new computer.
Yes, that would add some "new juice" to the game.Real long range attacks. I know that this goes against FPI #24, but this didn't stop fabi from adding the required keys inside [attack]. Now we have this unused code that should be either completed or removed.
Beheld the origins of BFW.
Max G on WIF
Rank 🌟🌟🌟🌟🌟
Max G on WIF
Rank 🌟🌟🌟🌟🌟
- Pentarctagon
- Project Manager
- Posts: 5572
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Lets learn from Spring and think about the future of Wes
Define "old computer".
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Lets learn from Spring and think about the future of Wes
This is exactly what i thought about it. I played wesnoth first time in Version 1.0.3, and even though i'm new to the forums i've played the game for years. And it has becoming great since 1.0.3 but i think, like Slann said, it's done.. in a good way.Slann wrote:My naive solution, as i said from the beggining, is to leave BoW as it is. It is perfect, and most of the additions that other users have posted won't make any difference in the user experience. The game is not going to change, and i'd say programmers prefer to colaborate in a captivating project, not one that is, in short, finished.
So, why dont we think on how to improve the gameplay? all those things that, over the years, we liked to see in wesnoth but we know it would violate its gameplay. Why dont we accept that bow is 'done' (in a good way) and think about wesnoth 2.0 ? For example, in bof2.0 we could see simultaneous turns (like Age of Wonders)
I will keep playing 1.13 and of course 1.14 and further.. but as a simple player, I would really love to see a 2.0.
Developer of Project Haldric
Add-ons: Millennium Era, Vision of a Shaman, A New Home
Art: Bitron's Art Thread
Tools: WML Syntax Highlighter for VS Code
Add-ons: Millennium Era, Vision of a Shaman, A New Home
Art: Bitron's Art Thread
Tools: WML Syntax Highlighter for VS Code
Re: Lets learn from Spring and think about the future of Wes
> This is exactly what i thought about it. I played wesnoth first
> time in Version 1.0.3, and even though i'm new to the forums
> i've played the game for years. And it has becoming great since
> 1.0.3 but i think, like Slann said, it's done.. in a good way.
That is not logical at all.
Nobody says that the underlying structure needs to remain the same
as it is/was.
That is, you could easily change the points that you mentioned there
and in the other part of what you wrote.
There were some things that bugged me in particular with wesnoth or
perhaps more so with the development:
- The game was getting much larger than it used to be. Since I always
compile from source, aiming for 1 Gigabyte downloads for just a game
that may crash, be unstable or not effectively change that much
between individual versions, just was not worth the "payoff" phase. I am
aware that it has not reached 1 Gig, but it's growing towards that.
Don't get me wrong there, I think Wesnoth is/was a great game, but
games should not become too big unless there are really compelling
reasons to warrant that size increase. Just for tiny enhancements in
graphics, really isn't worth to boost it up that much.
- The requirements became more annoying over time. As is often the
case with C++, boost gets in, other things get in, things increase
in size and complexity and then individual developers drop out. Not
a good way to manage a project. Complexity should be beaten down
with a stick that tries to simplify everything, at all times.
Wesnoth has had a good design, things were quite simple.
- WML is ugly to use, write or maintain. One could use a simpler
way to describe a campaign. Lua is no real alternative either.
The old ZakMcCraken etc... hat a pseudo-language for that.
Everything that people could want to have in a campaign, can
become a pseudo-simple language. Please no [if xml check],
embedding programming in XML tags, now that was one insane
idea. Is the dude who devised that still active?
> I will keep playing 1.13 and of course 1.14 and further.. but
> as a simple player, I would really love to see a 2.0.
For me, none of these changes really address the above problems.
A few months ago, I even failed to compile wesnoth from source.
Or rather, it compiled fine, but on startup there were problems.
And I am sorry but these problems DID NOT EXIST BACK IN 2010 or
so.
Wesnoth's strong point was in the tactical setups. You really
had to think before moving ahead with your units, as otherwise
your units may have been isolated.
This is what made the game a lot of fun. It was simple but also
could be complex at the same time, while remaining simple.
I would focus on this gameplay, think about the units too, and
perhaps think about how to make the map terrain complement the
units more than before. There could be special objects that
grant some minor enhancements on a per map basis. Like a
spirited town, where the villagers help defend (thus granting
like a +10% defence boost), and so on.
> time in Version 1.0.3, and even though i'm new to the forums
> i've played the game for years. And it has becoming great since
> 1.0.3 but i think, like Slann said, it's done.. in a good way.
That is not logical at all.
Nobody says that the underlying structure needs to remain the same
as it is/was.
That is, you could easily change the points that you mentioned there
and in the other part of what you wrote.
There were some things that bugged me in particular with wesnoth or
perhaps more so with the development:
- The game was getting much larger than it used to be. Since I always
compile from source, aiming for 1 Gigabyte downloads for just a game
that may crash, be unstable or not effectively change that much
between individual versions, just was not worth the "payoff" phase. I am
aware that it has not reached 1 Gig, but it's growing towards that.
Don't get me wrong there, I think Wesnoth is/was a great game, but
games should not become too big unless there are really compelling
reasons to warrant that size increase. Just for tiny enhancements in
graphics, really isn't worth to boost it up that much.
- The requirements became more annoying over time. As is often the
case with C++, boost gets in, other things get in, things increase
in size and complexity and then individual developers drop out. Not
a good way to manage a project. Complexity should be beaten down
with a stick that tries to simplify everything, at all times.
Wesnoth has had a good design, things were quite simple.
- WML is ugly to use, write or maintain. One could use a simpler
way to describe a campaign. Lua is no real alternative either.
The old ZakMcCraken etc... hat a pseudo-language for that.
Everything that people could want to have in a campaign, can
become a pseudo-simple language. Please no [if xml check],
embedding programming in XML tags, now that was one insane
idea. Is the dude who devised that still active?
> I will keep playing 1.13 and of course 1.14 and further.. but
> as a simple player, I would really love to see a 2.0.
For me, none of these changes really address the above problems.
A few months ago, I even failed to compile wesnoth from source.
Or rather, it compiled fine, but on startup there were problems.
And I am sorry but these problems DID NOT EXIST BACK IN 2010 or
so.
Wesnoth's strong point was in the tactical setups. You really
had to think before moving ahead with your units, as otherwise
your units may have been isolated.
This is what made the game a lot of fun. It was simple but also
could be complex at the same time, while remaining simple.
I would focus on this gameplay, think about the units too, and
perhaps think about how to make the map terrain complement the
units more than before. There could be special objects that
grant some minor enhancements on a per map basis. Like a
spirited town, where the villagers help defend (thus granting
like a +10% defence boost), and so on.
- Pentarctagon
- Project Manager
- Posts: 5572
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Lets learn from Spring and think about the future of Wes
I'm not sure if you have some sort of internet restrictions, but downloading 1 GB is not that much for a game anymore and sounds more like a restriction you are placing on yourself than anything.shevegen wrote:There were some things that bugged me in particular with wesnoth or
perhaps more so with the development:
- The game was getting much larger than it used to be. Since I always
compile from source, aiming for 1 Gigabyte downloads for just a game
that may crash, be unstable or not effectively change that much
between individual versions, just was not worth the "payoff" phase. I am
aware that it has not reached 1 Gig, but it's growing towards that.
Don't get me wrong there, I think Wesnoth is/was a great game, but
games should not become too big unless there are really compelling
reasons to warrant that size increase. Just for tiny enhancements in
graphics, really isn't worth to boost it up that much.
Well, there is a new possibility for replacing WML/lua, though I don't suppose you have any suggestions of languages that could be used keeping in mind that one of the primary functions of WML is that it's easy for people unfamiliar with coding to pick up?shevegen wrote:- WML is ugly to use, write or maintain. One could use a simpler
way to describe a campaign. Lua is no real alternative either.
The old ZakMcCraken etc... hat a pseudo-language for that.
Everything that people could want to have in a campaign, can
become a pseudo-simple language. Please no [if xml check],
embedding programming in XML tags, now that was one insane
idea. Is the dude who devised that still active?
There is, in fact, an entire forum for problems with compiling from source.shevegen wrote:For me, none of these changes really address the above problems.
A few months ago, I even failed to compile wesnoth from source.
Or rather, it compiled fine, but on startup there were problems.
And I am sorry but these problems DID NOT EXIST BACK IN 2010 or
so.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Lets learn from Spring and think about the future of Wes
How much of that is bloat, how much is music & images? Either way, it would still take many years before it grew to 1 GB.shevegen wrote:The game was getting much larger than it used to be...
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
American Standard Code for Information Interchange Client
I am working on the solution:shevegen wrote:The game was getting much larger than it used to be...
American Standard Code for Information Interchange Client.
"Wesnoth has many strong points but team and users management are certainly not in them." -- pyrophorus
"The thing a project in the true spirit of open source has to fear is not forking, but clean-room re-implementation. When that happens, you know something is wrong."
"The thing a project in the true spirit of open source has to fear is not forking, but clean-room re-implementation. When that happens, you know something is wrong."
- beetlenaut
- Developer
- Posts: 2827
- Joined: December 8th, 2007, 3:21 am
- Location: Washington State
- Contact:
Re: Lets learn from Spring and think about the future of Wes
That doesn't look like a joke, but why?
Campaigns: Dead Water,
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide