Lets learn from Spring and think about the future of Wesnoth

Discussion among members of the development team.

Moderators: Forum Moderators, Developers

Lets learn from Spring and think about the future of Wesnoth

Postby AF_ » July 26th, 2015, 7:12 pm

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

Hokomoko 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.


Full list of staff here: https://springrts.com/phpbb/memberlist.php?mode=group

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!
AF_
 
Posts: 1
Joined: July 26th, 2015, 7:01 pm

Re: Lets learn from Spring and think about the future of Wes

Postby shadowm » July 26th, 2015, 8:25 pm

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:

  • 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 (*)

1.14 goals:

  • 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 (*)

1.16 goals:

  • 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 an asterisk are currently not doable by the development team due to a lack of experts with the required skill set for the task.
(?) 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.
I also made Wesnoth RCX, a team-color preview tool for artists and content creators.
Elsewhere: shadowmBlogFollow me on Twitter
User avatar
shadowm
Site Administrator
 
Posts: 6199
Joined: November 14th, 2006, 5:54 pm
Location: Chile

Re: Lets learn from Spring and think about the future of Wes

Postby Elvish_Hunter » July 27th, 2015, 8:09 am

My personal two cents.
Some things that I'd like to see in 1.14 are:
  1. A new ability, similar to Swarm, which instead of altering attack strikes, alters the damage
  2. 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 :augh: ), 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).
  3. Remove the 72x72 pixels limit for [item]s. Ideally, they should be handled like halos, but drawn before halos and units.
OK, this is my short list for now.
Current maintainer of The Sojournings of Grog, Children of Dragons, A Rough Life and Wesnoth Lua Pack
Co-author of The White Troll
On Wesbreak until the 21th of December
User avatar
Elvish_Hunter
Developer
 
Posts: 1360
Joined: September 4th, 2009, 2:39 pm
Location: Lintanir Forest...

Re: Lets learn from Spring and think about the future of Wes

Postby mattsc » July 30th, 2015, 12:30 am

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.
mattsc
 
Posts: 991
Joined: October 13th, 2010, 6:14 pm
Location: Wandering, mostly aimlessly

Re: Lets learn from Spring and think about the future of Wes

Postby Slann » July 30th, 2015, 11:54 am

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.
User avatar
Slann
 
Posts: 66
Joined: March 2nd, 2008, 3:47 pm

Re: Lets learn from Spring and think about the future of Wes

Postby aquileia » July 30th, 2015, 12:12 pm

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.
aquileia
Developer
 
Posts: 120
Joined: August 25th, 2012, 5:13 pm

Re: Lets learn from Spring and think about the future of Wes

Postby Slann » July 30th, 2015, 12:26 pm

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)
User avatar
Slann
 
Posts: 66
Joined: March 2nd, 2008, 3:47 pm

Re: Lets learn from Spring and think about the future of Wes

Postby Yomar » July 30th, 2015, 3:53 pm

* 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.


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 ?

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.


Yes, that would add some "new juice" to the game.
Yomar
 
Posts: 240
Joined: October 27th, 2011, 5:14 am

Re: Lets learn from Spring and think about the future of Wes

Postby Pentarctagon » July 30th, 2015, 11:29 pm

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
User avatar
Pentarctagon
Forum Administrator
 
Posts: 3138
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Lets learn from Spring and think about the future of Wes

Postby Bitron » October 30th, 2015, 10:18 am

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)


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.
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.
User avatar
Bitron
Moderator
 
Posts: 340
Joined: October 19th, 2015, 9:23 am
Location: Germany

Re: Lets learn from Spring and think about the future of Wes

Postby shevegen » October 31st, 2015, 1:32 am

> 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.
shevegen
 
Posts: 140
Joined: June 3rd, 2004, 4:35 pm

Re: Lets learn from Spring and think about the future of Wes

Postby Pentarctagon » October 31st, 2015, 7:33 pm

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.


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:- 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?


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: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.


There is, in fact, an entire forum for problems with compiling from source.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
User avatar
Pentarctagon
Forum Administrator
 
Posts: 3138
Joined: March 22nd, 2009, 10:50 pm
Location: Earth (occasionally)

Re: Lets learn from Spring and think about the future of Wes

Postby doofus-01 » November 2nd, 2015, 2:24 am

shevegen wrote:The game was getting much larger than it used to be...
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.
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
User avatar
doofus-01
Art Contributor
 
Posts: 3601
Joined: January 6th, 2008, 9:27 pm
Location: USA, the civilized part.

American Standard Code for Information Interchange Client

Postby fendrin » November 2nd, 2015, 5:49 pm

shevegen wrote:The game was getting much larger than it used to be...


I am working on the solution:

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."
fendrin
 
Posts: 31
Joined: September 10th, 2009, 10:45 am

Re: Lets learn from Spring and think about the future of Wes

Postby beetlenaut » November 2nd, 2015, 10:45 pm

:shock: That doesn't look like a joke, but why?
Campaigns: Dead Water
The Founding of Borstep
Secrets of the Ancients
User avatar
beetlenaut
Developer
 
Posts: 2103
Joined: December 8th, 2007, 3:21 am
Location: Washington State

Next

Return to Developers’ Discussions

Who is online

Users browsing this forum: No registered users and 2 guests