Sweet Transit News

[h3]Conductors, [/h3]

Sweet Transit's launch is upon us! In just a few days - on Thursday, July 28th - we'll be releasing into Early Access.

Thank you for your help throughout our journey so far. We stopped at some cool stations along the way, your feedback and invaluable contributions have helped Sweet Transit become even better!

Without further a-do, let's look at Early Access Ticket prices for Sweet Transit...

[h3]Pricing[/h3]*Note - Launch & Bundle discounts stack.

Sweet Transit (Early Access Launch)

• $21.99/€21.99/£17.49 - Base Price
  

Sweet Transit Soundtrack

• $4.99/€4.99/£4.49 Base Price
  

Composed by Ely Robins, Sweet Transit's Official Soundtrack brings the unique train-city builder to life; evoking an era of pioneers, exploration and coal-based locomotion with old time jazz, rock and roll and Harlem parlor blues.

Sweet Transit Supporter's Pack (Game + Soundtrack)

• $26.98/€26.98/£21.98 Base Price
  
• $24.28/€24.28/£19.78 -10% Bundle Discount
  

-10% Launch Discount (July 28th - August 4th) (This is estimated based on the base price, actual exact price may vary)

• Game: $19.79/€19.79/£15.75
  
• Soundtrack: $4.49/€4.49/£4.04
  
• Bundle: $21.58/€21.58/£17.5
  

Sweet Transit will be pushed live into Early Access on the Steam Store Page at 6pm BST on Thursday, July 28th. (10am PT | 1pm EDT | CEST 7pm)

Any questions? Please leave them below, a member of the team will endeavour to head your carriage.

We hope you have a wonderful journey with us!

[h3]Sweet Transit launches into Early Access July 28th[/h3]

https://store.steampowered.com/app/1612770/Sweet_Transit/

Hello! With launch just over three weeks away on July 28th, I've been working hard on addressing further feedback in the recent days and adding even more features into the game in order to make the launch the best it can possibly be. It is time for one more week worth of changes. This week was more focused on smaller features and tweaks except for one big addition which took the biggest chunk of time. We can start with that!


This was on the to-do list, but later down the line. Now you will be able to copy existing rails, rail signals, rail bridges and stations. This allows you to solve logistic problems once and re-use your solutions in multiple locations.


For now, blueprint sharing is only done in two ways. The first way is just to copy paste it using Ctrl + C and Ctrl + V as you would with text. You will get a Base64 string once you copy which is easy to share. The next option is through modding by adding custom blueprints in the logistics build tab which then can be shared through Steam Workshop.

This feature will be worked on more in the future once there is more time to do so.


Before, saves were sorted based on their names. Now they can be sorted by data too, which will be the new default. Save UI can see folders in the save directory which is quite useful for grouping files together. Someday it will be possible to create and edit folders in the game, but for now you can only do that through windows.



I have added two new ways that you can navigate using your mouse. Using Shift + Left Mouse Button and the Right Mouse Button.


Building long stretches of straight rails was harder and more cumbersome than it should have been. Now, it is barely an inconvenience, just hold Alt and rails will attempt to be built in a straight line.



Most of you did not know, but you can bind keys 0-9 to specific structures, trains and more importantly, to build items. I always bind 1 to rails, 2 to rail signals and 3 to rail chain signals which streamlines rail building. Having key X as the delete mode toggle means that I do not need to lose my focus when solving logistic problems. Now these keys are bound like that by default. Later down the line I am thinking about a radial menu to compliment this system.


Upgrading trains was not possible during Beta. I quickly added it due to the feedback and this resulted in a less than ideal UI design. For now, I tried to only improve readability with some help from Izuna Neko in the Discord community.



Same name stations worked by allowing a train to use any station that has the same name as the destination station. However, a train would always look for a path in the direction of its specific station. This meant that other stations were simply optional if the train could not get where it wanted. Now, all same name stations will be treated equally allowing for better distribution of trains.


Just wanted to add here that tooltips will be less annoying whilst selecting what you want to build.



You could lock specific people to specific wagons during the Beta. It is very useful when you want only craftsmen to board the first wagon and laborers in the second for example. Now you will be able to lock wagon goods, allowing trains with the same wagons to transfer multiple cargo.


Lastly, I wanted to clarify how the new signal segment features work. In general it will work the same as before, having a single block between signals. All rail networks created in the past will provide the same results. The difference now is that a signal block can be divided into smaller pieces if conditions match. The goal of this feature was to address the lacking parts (compact rail systems) without changing anything else.

After some Beta analysis and prototyping I came to a conclusion that the solution is to split signal blocks between two rail pieces that cannot have any signals. A rail cannot have signals if there are multiple rail pieces in a single tile. This covers all of the situations where you would want to place signals.



Originally I thought of making a new kind of signal that can be placed in such places, but this creates problems. The biggest one is that players will have an even harder time learning the game. Then there is the problem of having to make signal placement manual in places where you always want to have one. Splitting signal blocks solves all of these. Newer players do not need to know about this feature, but more advanced players can optimize their intersections with more tools under their belt.

Now for the limitations. Trains will respect signal block rules, which means that a train will never stop in the middle of a signal block unless it is at its destination. Under the hood, it works similarly to how chain signals work. The train will reserve all parts until the next signal no matter how far away it is. It is very efficient in small places, not so much in larger ones. These blocks are limited in the size to 64 rail connections (~32 rail pieces) and up to 6 sections. Like everything else, this is open for modding.

After several weeks of playing I am more sure that this was the correct choice. It adds another level of depth that is fun to solve and optimize. It is like a fresh coat of paint after so much playtesting.

-------------------

And this is it for now, all of these features need to be properly tested and translated in time for the Early Access launch. You will be able to view the full changelog during this time period in the game covering ~80+ changes. There are many features I still want to add, but for now my focus will be mostly on bug fixing and balancing making to ensure that you get a quality product!

As always, please join us on Discord and I hope you're looking forward to July 28th!

Now that the demo is over, we’re extremely keen to keep players and our community in the loop on how the game is being improved upon. Ernestas, solo developer of Sweet Transit’s focus is finishing content graphics and balancing the Early Access end game. However, due to the amount of feedback, he will focus much more on features as well.

Keep in mind that the Early Access release will only have around 50%~ of the total content that is planned for the 1.0 release, with many systems still in development and some far from finished. Examples such as there being no trading, proper warehouse management, story, or events currently. These elements cannot be added unless the base game is working fully as intended. Our goal is to have a good foundation and build upon it over time. Improvements and balancing will come out together with new content until the final vision is realised.

With all that being said, please see some specific notes and feedback below from Ernestas himself:
“Hello everyone. Thank you for checking out the demo in the Steam Next Festival. The feedback and discussions both on Steam and Discord were fantastic, and gave plenty of food for thought. On-going feedback is always welcome as long as it is constructive. Most of the issues/features that were raised will be addressed in the Early Access release. I will share the more interesting parts instead of just dumping the changelog below.


There were many players having problems starting the game. Sweet Transit is not an easy game even for more experienced players as it encourages different kinds of problem solving. But there is still an issue that the game is not clear enough in some cases on how to solve these problems. It certainly does not help when people tend to skip the tutorial.
There are many changes being made already, here are few:

• Automatic route wait conditions.
  
• New situational advices such as introducing distribution centre or explaining why your current train will not load coal without gondola wagon.
  
• Ability to see which train is blocking the path.
  
• Increased small station road range.
  
• Removed train depot build time and now you can store trains there

The demo and the latest build had different signal block systems which caused obvious errors with me juggling between the two versions. During Beta people expressed that they wanted to have more compact rail systems. One option was to create path signals instead of block ones. But that would only trivialize logistics leaving only the city building as the sole challenge.
I decided to split signal blocks in places where no signal can be placed. This allows multiple trains to use the same block and opens up a layer of depth for optimization. The split happens between two rail blocks that cannot have any signals.




During the demo, people expressed that there was no reason to have no wait conditions. And it is true. From now on all new destinations will have a new condition attached to them automatically. I call this condition "Until done" as the train will wait only until it has something to do at that station. There is new "Until full of fuel" condition as well.
Conditions "Until full" or "Until empty" will now take the goods or people filter into consideration.
I plan to try to tackle multi-action destinations. So that you could load/unload/swap workers at the same time. Further to this wait conditions will most likely be minimized by default to improve readability.


In the Demo, village stations could share workers as they were only referencing residentials when counting the available people. Watching the demo I noticed that people expected that workers will pick one of the stations. I redesigned village station logic to allow this. Now people physically move to stations and wait there. By default they will choose a station with smallest number of workers in it. The biggest improvement that comes from this is the ability to imitate "tram" system by transferring workers from one village station to another.


Stations will automatically name themselves based on who they are connected to. If that is a distribution centre with Sawmills, then it will be "Sawmill 1". If it is a village named "York" with 2 stations already connected, then it will be named "York 3" and so on.


It was a hassle to manage routes after removing and redesigning your stations. Now routes will automatically find a new station if the old one is removed. A new station will be selected either if it has the same name or a new station is built in the same location.


Some people expressed that the train pathfinding had problems. This can be true as the train only recalculates paths when starting a journey, on a blocked chain signal or when some rails in the path are destroyed. Now path recalculation happens midway as well if the destination is reserved by another train.




I have added a space counter for signal dragging to make the perfectionists life easier.
Requirement Signals
Requirement signals have few additions as well:
- Recalculate - A train will recalculate its path when passing this signal.
- Influence - To positively or negatively influence train path calculation.
- Travelers - Limits further path to trains with travellers.


Build distances are changed from circles to squares. This should help to pack and plan everything more efficiently.




The game seems to not tell why you cannot build in certain areas. To make those errors clearer now they will float away grabbing your attention. Going forward more will be added.


It was hard to specialize villages when you need production structures to store fish, clothes and so on. Now residences will store goods that they need. Having a village that does not produce anything, just imports will be possible.


Village decorations no longer require the need for a road or any other connection. The decoration system is one with the least development time associated right now. Later down the line it will be more "tactical" in how you want to use it instead of randomly placing it everywhere.




I have added ability to disable production facilities. This will allow to plan bigger farms and factories without worrying that workers will occupy them or upkeep brings you down.
Coal Mine and Sawmill are now always visible in the production tab with tooltip on how to unlock them. This should help new players in figuring out what they need to do.


Most of the UI needs some work and it will come in time. Features are regularly being added leaving UI outdated and unintuitive. While I try to keep it up to date, there is only so much I can do alone with my limited skills and time. If anyone has some ideas on how it could be done better feel free to discuss it with me in Discord. This way, those changes will come sooner as it will save me time in design.
Graphs, unlock tree and other statistics windows are planned with the first Early Access update. A full list of what to expect will come later.



Thank you for reading and for all of your help in trying to help to improve the game. Sweet Transit journey is just getting started. Personally, I am quite excited to see what this game becomes with so many good ideas all around.”

[h3]Hello Sweet Transit Fans![/h3]

We’re excited to now share with you the next steps for Sweet Transit! Before we get into when everyone can next play Sweet Transit, I’m sure you’ll want to know what we learned during the Beta, and what the biggest takeaway were.

A note from developer, Ernestas Norvaišas:

Hello,

Firstly, I would like to say thanks to everyone who took part in the Beta for Sweet Transit. The Beta was quite the success in my eyes. For me personally the biggest point of interest was seeing how you all enjoyed the game. I was very happy to see so many different playstyles and approaches to problem solving.

The biggest take away would be how different the difficulty level was in my eyes compared with those of new players. As an experienced self-proclaimed best Sweet Transit player, I’m always looking at ways to add this little bit of extra spice to make the game more interesting. This is not a bad idea, but for new people one other extra thing to balance is not an easy task when introducing this genre. This reinforces the perspective for the future that listening to only experienced genre-fans might not be the best thing when regarding the accessibility of new players.

Map generation is another topic that I found interesting. People enjoyed playing mostly on flatlands, removing the difficulty provided by the terrain. The world is designed to be uncomfortable, not having the perfect place for expansion. I personally do not enjoy the map being just a visual thing that does not contribute to gameplay, but because of the feedback, the majority of the new map generation presets will be much more casual. Hopefully later, once players get more hours under their belt will find enjoyment in challenging themselves with difficult terrains as I do.

I am very excited to see how the game evolves and becomes better. Multiple new ideas and possibilities are already in the list thanks to you all. There are no precise plans on how version 1.0 will look, just broad strokes at this time. This approach will allow me to listen to feedback and mould the game based on what people enjoy, rather than what sounds good on paper.

Below are a list of specific changes for those interested...

[h3]Main Changes:[/h3]

• Distribution Centre: Making ways to connect multiple production facilities was previously planned, people in the past expressed that it would be nice to have such a facility. Seeing people playing the beta with their own unique styles proved that this structure should come sooner rather than later.
  
  
• Train Upgrading: Finally, there is an easier way to upgrade trains. Now you can upgrade specific trains, route trains or all trains that match specific wagon/locomotive setups.
  
  
• Balancing: This is usually a very delicate and never-ending issue in games. I have addressed the so called "Death Spiral", making sure that there is mostly always a way to bounce back. All "Death Spiral" saves that were provided to me were personally beaten and resolved. On top of that people debuffs are now a little bit more lenient, allowing for more mistakes. Inhabitants leave your villages much slower as well, to provide you a chance to react to the mess you may have made. But as before bad planning is still the enemy of all.
  
  
• Map Generation: Map generation controls have been updated to be more predictable. The current fragmented map generator preset will be left for more experienced players and by default an easier one will take its place. Finally, you can now copy the whole map string containing its settings and share it with others should you wish.
  
  
• Signalling: This was the most talked about subject, as expected. I will not add path-based signals, that will divide community by adding easier, but less interesting ways to play. Solving problems with block signals allows for much more control with a bigger sense of accomplishment. However, I will address the issues of not being able to build compact rail networks in time.
  
  
• Accessibility: While this is always evolving, people expressed multiple issues relating to accessibility. Now ranges are on by default, tutorial tips provide more information, more navigation options are added and much more smaller tweaks have been added throughout the game.
  
  
• Pathing: Now you will be able to debug why the train cannot find its path. This should help all players to find those pesky wrong direction looking signals. It will work by visualizing the pathfinding, this way you will be able to see how the train is planning to make its way to the destination.
  

[h3]Sweet Transit Playable Demo
[/h3]
We’re happy to say that on June 9th at around 6pm BST, we will be launching the brand-new demo for Sweet Transit. To download this demo just head over to the Sweet Transit Steam Store page and you can download it there. This will be available for everyone to play!

This demo features a host of improvements over the Closed Beta, but we would like to state that due to on-going development work on the later parts of Sweet Transit, alongside the public availability of this demo, that the breadth of content available will be a smaller than that in the Closed Beta and all the changes listed above may not be implemented in time. The demo content showcase will also allow us to obtain more focused feedback session on the tutorial, and introduction to Sweet Transit, whilst also introducing people to what Sweet Transit has to offer. Please note that we will be opening our Discord Channels and Forms once more and encourage feedback about the new changes.

[h3]Steam Next Festival
[/h3]
The demo will also be heading into the Steam Next Festival on June 13th through to June 20th, this will allow even more people to find out about Sweet Transit and allow us some unique featuring on Steam. Let your friends know and encourage them to download, and wishlist, it’s a great help to us.

With the demo launching, as well as the Steam Next Festival inclusion, you might be asking, when is Sweet Transit coming out?! Well, all things come in good time! A little patience will be rewarded.

[h3]Wishlist Sweet Transit[/h3]
https://store.steampowered.com/app/1612770/Sweet_Transit/

Sprite Sorting

First of all, I wanted to thank you all for the support and positive comments. I am reading all of them even if I am not replying. It gives me great joy seeing your expectations and hype for Sweet Transit.

2D in games is usually seen as an easier choice and most commonly trivialized by people. My goal with this post is to show what I have been working on in the past week and shed some light on the reality of working in 2D.



In 3D games sorting is done by pixels depth in the GPU, seeing which point is closer to the camera. Sometimes CPU needs to sort some transparent objects or for optimization. It is a very powerful and convenient way to do it like that. In 2D games all sprites are transparent and the sorting needs to happen manually in the CPU. This sometimes gives unexpected issues that you would never have in 3D.



Sorting in 2D is done not by pixel, but by image or sprite. This leaves a lot less space to work around. Still, it is done using depth. It is easiest to see in a side-scrolling game where you have the foreground always on top of the background. Isometric games like Sweet Transit uses screen position to determine what is on top. Objects on top of the screen are behind objects that are on the bottom.



In 3D games graphics most often are limited by the graphics card. There is a limit of how many polys you can pass through a GPU and still have 60 frames per second. At the moment Unreal Engine is pushing this to the limit with its Nanite Virtualized Geometry. However, in 2D PC games, your graphics card is rarely an issue. There are cases with overdraw and having relatively slow GPU with 4k screen will drop fps. Most often CPU is the limiting factor in how many sprites you can draw on your screen. Before sending everything you want to draw you need to gather objects from the screen and sort them accordingly. This is no easy task even with the modern CPU. Right now in Sweet Transit there are on average 40-60k sprites per frame.



Layering is used to mitigate the workload. Tiles and water are in separate layers than trees, trains and structures. On top of that, the screen is divided into several horizontal strips, that are rendered and sorted in different threads. When merging only the ends of these strips need to be sorted instead of the whole collection. There are other tricks used such as reusing GPU indices, vertices, limiting draw batch prices.



The most common problem an isometric game has is sorting two images at the same height. Or when a lower image needs to be below the higher like the train image below. For a person, it is clear what should be on top of what, but a computer has no idea. There are several solutions online, but the priority was performance and making a solution as cheap as possible.



I decided to slice up the sprite into several parts. At first, I did an automatic system where you define how many slices should happen and the game does the rest. However, that proved not enough because a wagon usually has several layers on top, like a tint mask, lights, cargo. The automatic system calculated sorting offset based on how far the sliced sprite is from the center and none of the layers were the same width.



I have tried calculating offsets based on the parent sprite, so that wagon will always be below its cargo, but that only meant I could not share cargo graphics between wagons. The only reasonable option was to define exact slice positions and offsets. Now when the game slices sprites it calculates slice positions based on the wagon position with defined offsets, rather than the sprite itself.



Working on bridges added another problem, that there is not enough space to sort multiple wagons. In a typical train under bridge scenario we have a bridge behind the train, the train, and a bridge in front of the train. This in itself was not a problem, but when you also have another train on top it adds a lot of layers that need to be sorted in a small position without invading outside objects.



At first, I added the top world layer, which meant that everything above a certain height needs to be cut off and rendered separately. This did the trick, I could sort the bottom train separately from the top one. But it was far from the cleanest solution. Rendering would require ~30% more sprites and modders would have an overhead making sure that taller sprites are sliced correctly, without no real guidelines apart from "Does it work in all cases?". On top of that sorting trains on a ramp proved very problematic, because it was the only transition from the bottom layer to the top. Even when the ramp had ~10 layers it would have some clippings.



The final solution I came up with is using another pass when sorting. First sprites are sorted based on depth and after that based on flags. A sprite with a train flag goes below a sprite with a bridge flag if rectangles intersect. The idea is if the bridge is sorted correctly, then moving a locomotive sprite above a correctly sorted bridge sprite would yield no problems. The only downside is a performance hit, but with drawing fewer sprites it should not feel that much.



After multiple iterations and errors, it worked. But like with everything in game development it is not that easy. It turns out that there are some ugly side cases. For example, a sprite with a train flag will search for sprites with a wheels flag to move them under the train. If the train is moved above or below the bridge then the wheels should come also to sort correctly. The problem was that there would be multiple train sprites intersecting the wheels, and in some cases wheels would go under the wrong train sprite.



I had to play with sorting distances and underline logic of how the second sorting pass works until most of the problems were fixed. For the wheels I had to prioritize the closer train by checking the wheels sprite center intersection, gladly it was the fix, sadly it took me a whole day scratching my head and experimenting to find it. I find that usually, the easiest solutions are the correct ones in programming.



Solving these issues feels like using duct tape for every problem. I would love to add proper locomotive headlights in the night, but it brings me shivers thinking about how I would have to solve it properly. At the end of the day if sorting is done properly, then people won't notice and take it for granted. That is in its own way a compliment.



After all of this, it seems that 3D would be an easier choice for this type of game. However 2D sprites can have much more details while still keeping system requirements relatively low and having many detailed trains on a screen is what I am after. I hope you have learned something interesting today!