Thank you to this week's programming contributors, @Slipped, @imbris, @pfauenauge, @timo, @zesterer, @Algorhythm, @desttinghim, @Qutrin, @Mckol, and @YuriMomo!
Progress on 0.2
This week, we set the (tentative) deadline for 0.2 to be May 28th. This is the anniversary of the Veloren repo being created, so we want to try and get something in working condition to celebrate!
Since we have a due date on 0.2, we now have a burndown chart! This allows us to see how many issues are still left vs how much time is left. You are able to see what the velocity of work being done is, and therefore predict if you are going to hit the deadline. As of right now, we don't have enough Merge Requests completed to see this. But, as we approach the deadline, it will start to have a line tend towards 0. You can take a look at the 0.2 milestone here
The burndown chart for 0.2. It hasn't been decreasing, as there aren't many merged requests just yet.The team has also been working on making tasks more accessible. We've been creating many issues to be discussed and worked on, as well as adding tags. This means that there are lots of beginner tasks ready to be worked on! You can see all of them here, and we will keep working on adding more in the next few weeks.
Also, we have seen a massive rise in the number of weekly commits to Veloren this week. Two weeks ago, there were 12 commits by 2 people. Last week had 36 commits by 6 people. This week had 100 commits by 10 people. This is almost half the commits since the beginning of the year! This is great to see, as it means the engine is starting to become more accessible to more contributors.
Other programming progress
@Qutrin has been putting in quite a bit of work this week on quality of life issues and other fixes. He has worked with @Zesterer on animation states, as well as fixes to the single player version and some cleaning of constants. He has also started working on camera zoom interpolation, which is adding some new tick functionality to the engine.
@Timo has also been putting in lots of work on the engine. One of the big changes he is currently working on is client states. This gives a distinction between clients that are connected, registered, character, spectators. This allows the game to have a state that allows the client to use certain features. For example, a client that is only connected can't play because they are not yet registered. And a client with the character state would require certain information, such as player position.
@Timo has also been working on restrictions of networking animations, as well as animation smoothness. He also made some improvements to the Readme. Finally, he is working on character creation, which includes quite large changes to some of the character ECS. The character selection screen is in the game already, but it is not yet functional. It will be part of the 0.2 release though, and should be complete in the next week or two!
Character meshes are generated using their Character struct. Here, each weapon is using a random mesh. The same works for changing the head, arms or any other part.@desttinghim has made a lot of progress as well this week. He has worked on creating functioning singleplayer by creating a background thread that will run a private server. He has also worked on setting up a keybinding and setting file so that chosen settings can be saved after closing Veloren. He is currently working on networking settings and multiplayer UI improvements.
Networking notes by @Zesterer
Hello, Zesterer here. This week, we’ve made a truly enormous amount of progress. Of particular interest is the way in which the networking systems for Veloren have evolved. Below, I'll explain some of the challenges we've come across, and the way in which we've solved them.
Veloren uses an ECS (Entity Component System). This is an architecture in which components of each in-game entity are stored separately, but are all tied together by a single
As an example, an NPC might have a
Positioncomponent to store its position in the world, a
Velocitycomponent to store the speed at which it is moving, a
Charactercomponent to store information like the species, gender, and class of the character, and an
Agentcomponent to inform the game as to how the NPC should be controlled.
We need to synchronize all of these entities and components (including new components, deleted components, and modified components) over the network such that all connected clients see the same world state. To do this, I've created a Rust library named
sphynx. Sphynx is a layer that sits on top of the existing ECS and watches for changes to entities and components while the game is running. Every tick, it can wrap all of these changes up into a bundle of information that can be sent over the network to clients in other to inform them about how the world state has changed since the previous tick. This works perfectly for most systems and is a really reliable and easy way to do networked gameplay.
However, Sphynx also has some issues. For example: when the player moves around, we don't want to be sending a message to the server to indicate that the player wants to move, waiting for the server to respond, and then updating the position. Such a delay for movement input is simply unacceptable. Instead, we want to be doing movement client-side, informing the server, and then have the server only correct us if we did something illegal (such as trying to fly).
But, Sphynx doesn't understand that this is how we want to do things, and as a result, we end up with the client and the server "fighting" for authority over the player's position. This results in a lot of jittery, glitchy movement.
Sphynx can't do everything
To solve this problem, we've had to move synchronization of the physics information (position, velocity, and direction) away from Sphynx and towards a custom system that's more lightweight and provides the dynamic control we need. We'll still be using Sphynx for most things (like synchronizing inventories, character models, classes, abilities, etc.), but for specific systems that need more subtle control, we're forced to use a custom solution. Thankfully, the code for this has ended up being very neat and we're very happy with the progress of this.
In the future, we'll be using more advanced interpolation techniques such as 'Hermite interpolation' to make networked physics butter-smooth.
Another thing that's come to our attention is the need for distinct 'client states'. Unlike in most games, Veloren allows clients to choose the way in which they'd like to play the game. We permit chat-only clients (that don't have an in-game character), spectator clients (that can fly around, but cannot interact with the world) and character clients (normal gameplay as you'd expect). In the future, we'd like to support additional client states that allow the game ecosystem to be even more capable than it currently is.
The solution we've come up with is a system that looks very much like the state machines you'll be used to if you've ever studied Computer Science. Each client can be in one of several distinct states, and the game can conditionally move clients through these states according to a set of transition rules.
We've realized that this idea is more powerful than we first imagined, and so we're working on integrating extra states like a death state (used for the period between a player dying and them respawning) and a visitor state (used to allow clients to ping servers and request information, such as when looking at the server list screen). We're confident that this design is the best route to follow, and we're looking forward to exploring just how powerful this design will be in the future.
Veloren Coding Challenge II
With a new blog comes a new coding challenge! If you want to give it a try, you can check it out here.
Also, be sure to check out some of the answers from last week! There were lots of great solutions, and many used very different techniques to solve them.
Better interface scaling, switch to .vox imports, new small buttons near the bag and new window frames
Recently I was surprised to find some people wondering if Tales of Maj'Eyal was dead (as in not developed anymore). I was like "WTF??" because I knew it was not, quite the opposite in fact, but then I pondered some more and realized that I'm utterly bad at regularly communicating that fact! So let's try to improve on that with a Grand List Of What Is To Come (Possibly).
As usual I never give dates unless I'm sure. So always take this kind of things with a grain of salt, they may come in two days or two years 😀
Release of patch 1.6 with huge changes
1.6 is the next free big (huge) patch for Tales of Maj'Eyal. I have already delayed it far too much as such it has grown into such a monster patch that I likely won't be able to list everything going in without forgetting many others. Still, here are a few of them:
- Deep rework of early game balance, main goal being to reduce startup tediousness. This includes changes to difficulty, scaling, shops, drowning, items, ...
- A ton of cosmetic options for all playable races (including the expansion ones). From many shades of skin colors, to haircuts, beards, tattoos, ...
- Hugely improved NPC AI, smarter, better pathing, and so on. For MOAR GLORIOUS DEATHS!
- Update of Doomed, Cursed, Wyrmics, Antimagic, Shadowblades, Prodigies, Corruptors, Reavers
- Update to many randart powers and ego powers
- A complete revision of runes, inscriptions and charms
- Fixed bosses can now levelup in specific classes to keep the challenge up at higher levels/high difficulties
- Revision of many debuffs
- Melee weapon scaling revision to reign in on late game ultra high damage stupidity and buff early game low damage stupidity
- A ton of misc changes, updates, revisions, ...
- And the usual slew of bugfixes (and NEW bugs 😀 )
So you thought that when an expansion is released it's the end of its life? THINK AGAIN! After 1.6, Embers of Rage will get an update with a whole new class for you to slaughter poor creatures with: The Annihilator! As its name suggests this is a class for peace-loving orcs!
Annihilators use steamguns and new heavy weapons (flamethrower, shockstaff and boltgun) to destroy their foes all while deploying automated steam turrets and even riding around in a mecharachnid suit!
A force to be reckoned with for sure!
Note to be clear: this is NOT the very next update to Embers of Rage, that one will be released at the same time as patch 1.6 along with an update to all expansions, just to update their systems for 1.6. Annihilators will come a little afterwards.
DarkGod turns evil: Microtransactions, but the good kind!
Don't go screaming bloody murder just yet please ;) So let's say it upfront: no pay2win to be seen in there!
Now that this is said let's get into more fun details. So if there is no pay2win, what will there be?
Many things! Mostly fun and/or cosmetic stuff as could be expected:
- Additional Online Item's Vault space. Any purchase of the game, expansions, donations, ... already provides vault space, but this is for even MOAR!
- Various cosmetic themed packs. These will include shimmer appearances for most items, plus sometimes/usually additional cosmetic options for playable races. "But DarkGod, I want to have racial cosmetic options without giving you more money!" Well, fear not for 1.6 does bring in a ton of those for free anyway. The more, the merrier!
- Community events! Now for something a little different. In Tales of Maj'Eyal community events are temporary stuff that are sent by the server to any currently playing character. The server randomly sends two of those, called the Bearscape and the Lost Land of Poosh, to players automatically. There are many more, like seasonal ones, or ones only I can push when I feel like it. Now players will be able to acquire the ability to trigger either the Bearscape or Poosh themselves, in addition to the random server pushes that are not changing. But wait there is more! They are still community events, so whenever somebody buys and triggers one, all players currently online will benefit!
- I don't like pay2win. I really really don't. So instead of doing pay2win, I've decided to add a pay2die system instead! If you think your character is too strong, that nothing can kill you as you stride effortlessly through the toughest of foes, just buy this option and get a few level 500 god-level horrors randbosses summoned on you! Death is guaranteed! You can even boast online by showing off what horrible horrible creatures are about to kill you!
In last October Steam had a glitch in their algorithm, which effect lasted for months and for many can still be felt today. Basically the algorithm suggesting games had gone bonkers and unless your game was an AAA or super indie it sank to the bottomless depths of hell. Many indie devs, including me, had their revenue cut by like 50+% (sometimes much more).
Valve told us this was not intentional and I truly believe them; they've always been very nice people when I needed them so I have no reason to doubt their word. But still, it made me realize that I am so dependent on Steam. This kind of made me enter panic mode, I was mentally unwell for some time I must admit. Maybe I'm too fearful, a scared little boy or whatever but still that's how I feel/felt.
So I've pondered about additional revenue streams and I remembered about some players that kept asking to be able to buy more vault space and cosmetics. So finally after many years I caved in and the rest is (future) history!
And to be perfectly clear: this is just a way for people who want to support the game to do so while getting a few cosmetic/fun stuff out of it. The game itself is free/cheap and will keep on being so because making my game accessible to more people is something I truly believe in. Also I'm an evil god of darkness, thus I want to reach as many minions as possible; you know to eat their souls and stuff... 😀
Next expansion announcement: The Lost Land
And last but certainly not least... A new expansion! And not a small one at that. For a long time now I've only announced expansions when they were very nearly finished. This time I'm trying another way and instead I'm teasing it early on. As you can see on the teaser, no ingame art exists yet but many sketches. The lore, zones, foes, stories, ... are all roughly defined and being implemented. The new races and classes are already half-way done. Still it'll be a long way until release, which will obviously happen in exactly 1DGTU!
"But DarkGod, you didn't tell us what it is ABOUT!" Fear not my brave minion, I'm coming to that!
I can not yet reveal too much about it, and keep in mind anything can change, but here are some key facts for your pleasure:
- It is set on the continent of Tar'Eyal, to the south of Maj'Eyal, which you can already glimpse at the shores on the southern point of Shaloren lands ingame.
- Two prominent forces on the continent: the Great and Bountiful Undeath Empire and the Saupur Imperium
- The continent has been shielded from the outside by a mysterious shield for millennia
- It features a "half-campaign". It happens at the same time as Age of Ascendancy, the player starts on Tar'Eyal and it replaces the first half of the normal game.
- About 15ish zones planned, perhaps more
- At least two new classes: Dust Mages and Gravelords. It is very likely at least a third one will be added.
- At least six new races: Risens, Vessels, Vampires, Exarchs, Saurpurs (two kinds, reptilian and draconic). And possibly more!
- The usual tons of new lore, artifacts, npcs, achievements, quests, ...
So it seems like every single content creator is on Patreon but me. Well, I suppose I need to fix that then!
Joking aside, I've been asked many times if I could provide alternatives to Paypal for donations because well, some (many?) people are not fond of it at all. Lately Patreon announced they'd change their fees, except for people that got on before May, so I thought "Hey, I suppose it's as good as time as ever".
Now this is a bit of a different Patreon page than people are used to. In the spirit of always trying to keep things fair for every players, no matter where they buy the game/donate, I've decided that all the different pledge tiers would never entail players to anything special. Instead the system will simply count all the money that has been received from a pledge and add it to the voratun coins on te4.org. Just like any other donations. Patreon pledgers will get a blue name in the chat like any other recurring donation setups.
I know this is likely to lose me some pledges, but I think being fair to everybody is more important.
You can find the Patreon page here: https://www.patreon.com/darkgodone
The Future: new rendering engine
For a very long time now I've had a side project: upgrading the display code used by T-Engine4.
When I started making the game it was my very first OpenGL project, so as you can imagine the code sucked royally.
It has gotten better over time but it still follows the same principles I first implemented, and frankly, they suck.
Some time ago I spoke about porting the game to tablets & phones, this presents a lot of UI challenges as Tales of Maj'Eyal is just a wee bit more complex than your usual phone game. But it also presents code problems as the current way of doing OpenGL just does not cut it.
The new rendering code is meant to alleviate this problem. It's a very long project because it means rewriting so much code and because the new code is not the same even in concept. The worst part about this project is that, on the surface, the user will see very little change from all of this. Apart from a somewhat better font handling and some smoother animations, the primary changes will be a new particle system, and a visual editor to implement them.
Still it's a lot of thankless invisible work, but it is needed to ensure the future of the game 😀
The Other Future: translation?
This is even more hypothetical but something I've also worked on a bit, adding a translation layer to the engine to make it available in multiple languages. This is a huge undertaking and unlikely to come fast, if at all, but it would be so nice, wouldn't it?
Final Words: the DarkGod has spoken!
And there you go, you know of some of the projects being worked on/thought about. Do note that those are only the relative short-term stuff, ideas are certainly not something I lack ;) As I have said many times, Tales of Maj'Eyal is my baby, I love it and I do not plan on stopping as long as the community supports me with love (and sadly, money too as this is the real world :/ ).
Thanks to all of you and I hope you'll love what comes next, and then what comes afterwards and ... and ... well you get the idea 😀
Yes, if you have followed our development a bit, that might be a bit of a surprise. But we have been asked why we don't call this release 1.0, and the majority of us developers discussed this and decided that indeed this release is a major milestone that deserves the big 1.0 number.quoted from the 1.0 release blog post.
Indeed a nice surprise and definitely a big step forward with the inclusion of online multiplayer!
See more new features in the official release video:
As usual you can download the game here. Also don't forget to head over to our forums to provide some feedback to the developers.
This post was retrieved from freegamer.blogspot.com.
SuperTuxKart 1.0 official trailer
Should you not have followed our development: this 1.0 release adds support for networking races to SuperTuxKart. You can play with your friends online, and it doesn't have to be split screen anymore - your gaming partners can be in a different city, country, or even continent - you can still meet for a race or two. Cross-continent may not work the best; you should try to have a reasonable ping - 100ms works fine, and we had some races with 300ms ping, though unavoidable sudden stuttering and karts jumping around is more frequently at higher latencies. Even more important than the ping (unless it's abnormally high) is that there isn't packet loss or packet slowdowns (jitter), so a stable connection is required, especially for the server hosts. The bandwidth use is minimal even for hosting 10 players, so as long as you don't use a metered connection it should be fine for anyone with 150 kilobytes (~1.2 megabit) per second upload speed to spare. If that's still too much, less bandwidth is used with fewer players.
With the new version you can play various game modes online: normal race, time trial, soccer mode, battle mode and the new Capture-The-Flag mode. While you can easily start your own server (just select 'create server' in the GUI), the community also provides a set of servers to be used by everyone. Certain servers provide online ranking (since we have to make sure that the servers are not modified to favor certain players), and you can find the current rankings here. You can use one of the servers provided by the community. We would request that you do not abuse the servers provided by the community - they are meant to be used by everyone. If you want to play only with a certain set of friends, let SuperTuxKart create a server for you, and do not grab a public server and kick everyone else who wants to join.
The networking implementation has been a very big and ambitious task, which took even longer than the port from PLIB (anyone remember that?) to Irrlicht in 2010, which took around 14 months. But it is done: more than 20,000 lines of network related code and 18 months later, we have reached our goal, and online play is a reality. Across the whole game, more than 2500 commits and 300 resolved issues separate the 1.0 release from 0.9.3. And it was a very concerted effort, so a big thanks to all contributors involved, For the people who don't know the team, here a short introduction:
First and foremost Benau, who originally told me he would only like to work on some of the GUI aspects of networking, but who then grew to meet the challenges the network implementation threw at us. Without his work networking support would nowhere close to being ready or as complete as it is.
Alayan, a relatively new main contributor started several months ago, with a keen interest in balancing game play. He is an experienced speed runner for SuperTuxKart, and one of the best players in our online ranking system. While he was also essential in testing online racing, he made significant contributions to balancing SuperTuxKart and overall improving the playing experience.
We are still reaping the benefits from Google's Summer of Code program: leyyin is still with us, and he is helping us with the server side implementation. E.g. anytime you are looking for servers, his code will be involved. Then let's not forget Hilnius, who back in 2013 started to design the protocol implementation on which our networking code is still based. A very successful result for our participation in the GSoC.
Then the older core team, and I'll be a bit briefer here: Deve as always makes sure that all is fine on the Linux front, do many bugfixes and small enhancements, and maintains and improves our Android port. Auria keeps everything else running - pull requests, bug reports, forum posts, ... Samuncle, though busy with his private life, came through with the wonderful new "Ravenbridge Mansion" track. And Arthur keeping our social media feeds updated. Oh yes, there is also me (hiker) 😀
For the record: is the 1.0 release 'perfect'? No, it is not. There are improvements to be done, features to be added, and gameplay to be improved. Still, it is probably the most significant step forward in SuperTuxKart's more than 12 years of history. We would like to invite all of you to join some online games by fetching the new 1.0 release from our Download page.
On behalf of the SuperTuxKart team: thank you for your continued support through the years, and enjoy the big 1.0!
What could be terrifying about little cute bunnies and eggs?
Nothing you say? Well, think again for the Pikataclysm has arrived to Eyal and will stay active until May 1st!
Beware of what lurks in this strange place, for sometimes, bunnies have big teeth.
The Pikataclysm is a yearly special server event, triggered every 10 minutes by the server to all players currently logged in. There are others such events, come find them all during the year!
For the mappers, Tomos compiled a linux version of the Netradiant Map Editor. Together with the Q3Rally Game Pack you are ready to map for Q3Rally. You will get the Editor in the Downloads Area and the Game Pack in the svn.
The source code and Windows and macOS packages are already available on the downloads page. You may also find packages for other platforms there as they become available.
You may comment on this release in the forums.
Statistics: Posted by shadowm — 29 minutes ago
Veloren from above
This week, we're seeing lots of new potential contributors joining the Discord. This was from a post on /r/rust that can be seen here. It's always great to see new contributors, and they motivate the whole team to push further.
Weekly code challenge
Often in the Discord, there are many people who want to get involved with Veloren but feel that their Rust competence is not good enough. We want to make this an issue of the past!
A solution that we want to try is a weekly Rust code challenge. The challenge will be one that is designed to teach important concepts of Rust but remain accessible to Rust newcomers. We hope that discussion around the weekly challenges will spark excitement in the community around Rust. It would be great to see a lot more people feel more comfortable around the codebase.
If you want to give it a try, check out the challenge here. The challenges are currently being made by @AngelOnFira, with writing help from @Kidsnextdorks.
It is a dark time in Bagh Maldir. Over the last few years, famine has spread across the kingdom. You, a traveling wizard, are the king's last hope, lest his rule fall to shambles.
An issue that was addressed this week was how to store assets. Before the discussion, there were over 200 png files in the Gitlab repo. The problem with this is that anyone who wants to work on the project must download these files, even if they are removed.
The structure that Git uses doesn't actually keep track of all of the files that are current. Instead, every time you need to update the current files (by switching branches or downloading the repo), Git constructs the current files based on all of the previous commits. And since the png files were in the repo at some point in history, they are required to construct the repo.
There are a few different options to this. For most game development, Git Large File Storage is used. The problem is that the data needs to be hosted somewhere. We don't want to rely on a contributor to host it, as it would incur costs for them, and if they leave in the future then the problem would have to be assessed again. A few other ideas were thrown around, including Google Drive and Dropbox. But these all have their issues. As @zesterer put it;
- How do we ensure that all developers have access to the asset storage?
- How do we effectively integrate it with the existing build system?
- How do we ensure it's always up, throughout the entire lifetime of the project, even if members move elsewhere?
Some website changes
With the amount of other content starting to form around Veloren, there have been talks of changing parts of the veloren.net site. @Wulkan has spent some time this week adding a new navbar to the site (veloren.net). They have also expressed interest in changing the static site builder, in the hopes that it can start to become a homepage site rather than just a blog site.
There has been more work done on the book as well, as well as automated documentation. Be sure to check it out!
As has been the case in the last few weeks, networking is still a big topic. @xMAC94X, @Mckol, and @YuriMomo have all been providing support in different channels to make sure that bugs are being fixed.
A bigger networking problem lies in the current method of sending world data over the network. Here is an excerpt from @zesterer on the topic.
Ok, so I've been thinking about how we synchronize chunks between clients and the server. And I've realized that it's not a trivial problem, unfortunately. So there are two main models I think are useful to think about when doing this. "push" updates and "pull" updates. With the first, the server would automatically send new chunks or updated chunks to clients as and when they appear. With the second, the client must first request a chunk for it to be sent back. Now, this is all well and good, but it gets more complex when including things like view distances. How do you figure out whether to generate a chunk? Well... perhaps you iterate through all chunks that are within range of all clients, and then figure out which ones are generated and which aren't... then generate the ones that aren't. But that's a lot of chunks to be iterating through every tick (or every few ticks). Let's say the player has a view distance of 1000 (i.e: large, but not totally insane). With a chunk width of 32 and a world height of, say, 16 chunks, that's like... Ehm. I hope I just got this wrong. Volume of a sphere is PI * (r ^ 3) * 4 / 3. The radius in chunks is 1000 / 32 = ~32. So that's PI * (32 ^ 3) * 4 / 3 = ~140,258 chunks. Is that really right?. Because... God help us if it is. I guess it's smaller for a world height of 16 chunks only. But still... not smaller by much. And we'd have to iterate through that every tick for all players.
Basically, what the problem boils down to is how to send as little information over the network as possible while still representing the game world properly. Some of the ideas being thrown around to try to include some AI solutions, and other ways of representing color data.
In other networking news, there was an issue brought up where the client and server weren't communicating properly. You can check out the issue on Gitlab here.
Issues with the client and server fighting for control
Bigger push on Gitlab issues with milestones
With all of the new people joining the Discord server, it has become apparent that certain work has to be made. Better instructions on how to get up and running, more clear communication from the leads, and tasks distribution that can lead towards the greater goal. Gitlab issues is a solution to this.
You can see the current 0.2 milestone here. If you go into the milestone (here), you will see the issues that need to be completed for the milestone to finish. Now, that said, this is not to say that we are super close to finishing 0.2 because there are only X issues left. Issues are added as big tasks break down into smaller tasks, and as previously unknown problems come up.
The current issues in the 0.2 milestoneAlso, the core dev team is going to start making use of the "beginner" tag on Gitlab issues. These issues are designed for new contributors to get up and running with the engine. If you are hoping to get involved in contributing, start taking a look at these issues!
Characters with many different facial hair options
Icon for the Documentation by @Piedro0
Bow models from @Demonic
Beard/Hair/Eyebrow combination tests
Steadily growing collection of facial/head Features
So I decided to post the screenshot of a good part of the design of it, just to show you something.
Please bear in mind that it is something abstracted and not perfect, but I think sufficient for the purpose of this game.
(you can click on it and zoom for the full scale of the pciture)
Here’s one of its simulation on a spreadsheet:
Once the scope done, I will use the design of this effect, as a framework, to complete the design of Cold Wave, which is already in the process to be done too.
After that I will complete the design of the 3 geophysical effects (Earthquake, Volcanic Activity, and Volcanic Eruption) and their implementation will be fully done.
In parallel, I’m also in the work of implementing the process of these effects. It isn’t complete yet, but part of it is in the game.
Tomorrow, another full time design/dev day!
A few little gremlins crept into 1.9.0, so we thought we’d put the build farm to use while it still had some (undefined string) and release 1.9.1. There are no bugs left, which is just as well as we don’t want to run out of version numbers.
I also haven’t developped much these days (at least until April 2) because I had a good satck of work (from my day job) to finish…
But anyway I’m in holydays for the upcoming week, so I will work at least 7/8 hours a day on FARC to finally complete what I have to do with the WEAGES and starting afterward to add a few 2D assets, and additional infrastructures.
Regardless, this current version will be released before the end of April.
Thanks for your interest, and please enjoy the Spring!
- Fixed most issues reported with the last build
Since the beta-1 release, numerous bugs have been fixed. Obviously, as previously, the biggest feature is that networked multiplayer is now ready for general use, so enjoy multiplayer games over LAN or over the net!
A few tracks have also been added or upgraded. The old mansion track has been replaced with the new upgraded Ravenbridge Mansion track.
The Black forest add-on is now also part of the official STK track set! Thanks to Sven Andreas Belting for this great addition.
Download the game here : https://sourceforge.net/projects/supertuxkart/files/SuperTuxKart/0.10-rc1/
- Fixed many various crashes
- Fixed some balancing errors (incompatible with build 70)
- Added updated translation bundles
- Fixed drills not prioritizing correct items
- Fixed Impact Reactor displaying fluctuating and incorrect power values
- Fixed unplaceable blocks showing up as unbreakable schematics on servers
- Fixed kick messages and map author messages displaying as a garbled mess [Server]
- Fixed player teams being reset to blue after map reset in PvP
- ""Fixed"" ground units spinning around
- """Fixed""" a """"""bug""""" where the entire game would do very specific things and flash very specific colors when you opened a very specific menu under very specific conditions that were introduced on a very specific day
- Absolutely did not fix the flipped wave button bug
- Optimized all crafter block item and liquid processing
- Optimized unit collisions
- Implemented proper damage propagation - walls now contain explosions
- Buffed Differential Generator, Impact Reactor, Batteries, Mender
- PvP balancing: cheaper and more powerful units, weaker players, higher spawn cap
- Shuffled around tech tree
- Better stats for all blocks in general
- Made launch button be more flashy and obnoxious
- Made back button hide the application when in main menu [Android]
- Added stats for item consumption speed, all inputs and output for crafters
- Added minimap (prepare for the flipping)
- Added full-screen map view
- Added pixelation option (yes, stop bothering me about it now)
- Added new rule modifiers
- Added option for shield shaders, disabled by default on mobile
- Added full map screenshot button (again) [Desktop]
- Removed microtransaction permission and donations dialog
- Moved donations directly to itch.io
- The great FPS counter migration continues
After extensive testing and much feedback on the new feature for 16 cargos in and out of industries, we reached the conclusion that the economy is simply too complex. For this reason, all cargo types have been removed from the game, and been replaced with a single ‘Stuff’. The new freedom offered by this will for the first time in history let you genuinely build the transportation empire of your dreams.
The 1.9 release branch had barely been made, before a ton of pending pull requests were merged. Several changes in queue were pretty much waiting on 1.9 being branched off from master, since they were rather high-risk, and merging them in to 1.9 could have introduced new bugs with too little time to discover and fix them. Several of these are talked about at length below, but here are some short ones.
Many performance improvements have been made, through the use of smarter algorithms and data structures. dP from the CityMania community provided a savegame with slightly over 50,000 stations, which really brought the game to its knees, both loading and simulating it. The new fixes together improve performance of this pathological game massively.
Another big game used for testing is Wentbourne Transport, originally shared on TT-Forums, but unfortunately we can’t find the original thread at the time of writing. Wentbourne is a real game, with a very large number of vehicles: 5499 road vehicles, 4833 trains, 2818 ships, and 749 aircraft. The pathfinding this this large number of vehicles makes even top-end modern CPUs sweat, and it typically runs at less than 10 fps. One of the new optimisations added is path caching for road vehicles, similar to the caching introduced for ships in 1.9, and this gives a significant boost to performance.
A new generic data structure has been added to the library, a k-dimensional tree for improving lookup performance of objects in 2D space, in particular “nearest object” and “all objects within rectangle”. (It’s not actually k-dimensional in OpenTTDs implementation, it’s specialised to two homogenous dimensions.) This initially helps two cases: First, and most immediate, is finding the visible viewport signs, that is, station names, town names, player signs. The second is faster search for which town is local authority for a tile, this especially helps performance of many AIs.
SamuXarick helped find a particular edge case where world generation took unreasonably long time, and occasionally towns lost their bridges across waterways. When generating a huge map (4k square) with high number of towns, occasionally towns will end up never building any houses, so get zero population. These zero-population towns are deleted again during world generation, but it turns out that because bridges owned by towns do not store which towns owns them, the game has to search all towns for which is nearest and the potential owner. When the map is huge (16.8 million tiles) and there are around 10,000-15,000 towns, this search takes a long time. The fix for this was to look at the road tiles connecting to the bridge, and assume the town owning the roads also owns the bridge.
Everyone playing OpenTTD, and Transport Tycoon for that matter, have surely experienced stations inside towns eventually getting unmanageably many passengers. The central bus stop with 3000 passengers waiting is one classic example. The actual reason for this behaviour is that, when generating passengers, the population of a house is considered twice, one for chance of generating anything at all, and once for upper bound on amount to generate. A bit of statistics, or making a simulation, will show that the effect is quadratic growth in pax generation: A house with twice the population generates four times as many passengers. We’re adding a setting to control how pax is generated, and offering a new default method, where a house twice the population only generates twice the amount.
Fixing old exploits?
We have added two changes to the master (future 1.10) that can be described as fixes for old exploits.
The first is a new optional feature: Prevent player stations from serving industries that have their own neutral stations. This for example prevents a player’s train station next to an oil rig from receiving oil from the oil rig. To transport the oil from the oil rig, the player must instead send ships (or aircraft) to the oil rig, and would not be able to deliver passengers to the oil rig via train either. The default for this feature is the old behaviour, i.e. you have to opt-in to the more challenging gameplay.
The second is not optional, as we have agreed to classify it as a bug fix: Changing the way catchment area works for “sparse” stations, i.e. stations with multiple parts, that don’t form a single rectangle. Intuitively, the radius and shape of one station part’s catchment area should not affect the size and shape of other station parts’ catchment areas, but it did. In fact, the catchment area was calculated from the station’s bounding rectangle, such that a single bus stop distant-joined to an airport could expand the catchment area massively. This is now changed, so the bus stop distant-joined to the airport only extends the catchment area in the 7x7 area immediately around it, and there may even be a gap between the total catchment area parts. As an added bonus, the fixed code is even faster than the old, through the magic of improved data structures.
These changes/fixes can obviously be controversial, so please discuss and ask about them.
Over the last few weeks, we have been working on switching our build system to CMake. This unifies all build systems into a single one; no more
./configure, MSVC projects, and others. This also removes supporting both
vbsscripts, which were doing the same thing. As CMake also supports (via CPack) releasing NSIS (Windows Installer), Debian, RPM, and more, we will also be switching to that.
This gave us a great oppurtinity to clean up some old and weird quirks in the file structure and build system. For example, the build folder is no longer in-source.
With support for CMake nearing completion, we are asking for your help. Please considering testing this PullRequest, and let us know if everything is still working as you expect. It should support all OSes we support and should auto-detect all libraries. Please let us know if there are any issues or if you have additional suggestions. Your feedback will be greatly appreciated!
Years ago someone added DOS as a target, just because we could. It had some serious drawbacks: no threads, no network, different video-driver (allegro instead of SDL). This created some huge technical debt:
- We have tons of places where we have to keep in mind that network might also not exist (and DOS is the only one without network support).
- We have special glue to handle threads; and the compiler doesn’t follow std::thread (C++11), so we can’t switch to that.
- DJGPP (the compiler we use to create DOS binaries) doesn’t have support for CMake (to which we are switching).
- Last month we created some test-binaries to see the current state of DOS; turns out, the performance is not good (<1fps).
This doesn’t mean we don’t love DOS.. If you feel up to it, and can maintain DOS for a longer period, we would love to see a Pull Request reintroducing support for it. You can simply revert the patch that removed the code, and work from there.
MorphOS / AmigaOS / BeOS support
In 1.10 we will be dropping support for MorphOS and AmigaOS, as well as BeOS (you can use Haiku instead of BeOS). We did this as these targets weren’t maintained, and were unlikely to work in their current state. As we are working towards dropping SDL1 in favour of SDL2, and these platforms have no official SDL2 support, that meant either using unofficial SDL2 libraries or dropping support for these targets. As we have no maintainer, nor anyone to test on these OSes, we decided to drop support for it.
This doesn’t mean we don’t love any of these targets. If you feel up to it, and can maintain those targets for a longer period, we would love to see a Pull Request reintroducing for them. You can simply revert the patch that removed the code, and work from there.
Extensions & Tools
NML gained support for 16 cargoes which was added to OpenTTD earlier. For NML projects it means that they need to update the code for the production callback. Check FIRS for an example. Existing projects which do not want to make a change will need to use NML versions from the 0.4 branch which will continue to receive updates for the time being.
The basesets OpenGFX, OpenSFX and OpenMSX are now hosted under the umbrella of the OpenTTD group. OpenGFX got a new release (0.5.5) which contains the new GUI sprites for group liveries and lots of translation updates.
A “pony” is a personal pet project of a developer or community member. This section will be used in the future to showcase a project in detail.
OpenTTD in a browser
For today’s showcase, our community member Milek7 has had another go at bringing OpenTTD to the browser using Emscripten:
- Check it out here
- The changes to the source code this needed are listed here
- And there is also a version with music
Do you have an interesting Project you are currently working on in relation to OpenTTD? These Monthly Dev Posts are prepared in a branch on our GitHub website project before they are made public on the website. As soon as you are whitelisted as a contributor, it’s as simple as editing the file in the web interface. If you are not a contributor yet, drop by on IRC to become one (make sure you have a GitHub account).