News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

Creating a Simutrans-Clone to learn programming

Started by hiddentrainfan, June 11, 2016, 12:55:53 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

hiddentrainfan

deer team

i heard simutrans was originally devised by hajo to learn programming
i want to repeat that and learn programming by creating a similar game

i know very little yet so i want to ask programmers about there opinion

you think it possible to create a game of similar depht to simutrans using some c variant and unity?
actually i only want unity because i heard simutrans uses most resources for showing the screen since it does not use GPU
so it is a limitation i want to avoid, by programming just what the game does and using unity to display it via GPU

if you created simutrans from scratch, but you know you still want a grid and no 3D or at least 2D capability, what would you make different from the start?

where do you recommand to begin? i would first plan everything, like how tracks and roads and planes work, before even programming but i dont want to end because nothing gets done except for some notes so i would like to start with something simple to do parallel to planning maybe just landscape creation and anything the game does itself without player interaction?

big thanks for helping me out!

Ters

Simutrans isn't an easy thing to make, and I am not sure if using big existing libraries for graphics will make it easier or harder. Then again, I seem to have a below average motivation span.

The biggest problem with Simutrans is that code for game logic and graphics are mixed together. Every frame, the drawing step asks every object on tiles that might be visible to issue the basic drawing commands to the graphics back-end. There are easily thousands of such basic drawing commands per frame.  When zooming out, there can be tens of thousands, many over a hundred thousand. That is not good for performance.

A typical modern hardware accelerated game will first of all not tell the GPU to draw each basic primitive individually each frame. Sending them in batches is better, but the best solution is to store all the geometry in VRAM at the beginning, and then just issue draw commands. The basic geometries rarely change, but can be animated with basic parameters, like how much is the left knee bent, that transform the basic geometry into the proper shape on the GPU during rendering. Simutrans has a few changes happening in the landscape, such as ocean waves and some building animations. But when a hill is raised or lowered, you need to update the basic geometry on the GPU. In Simutrans, various tools simply alter the data in RAM and assumes that the renderer works straight of that each frame. That won't do when using the GPU. The renderer needs a way to know that a particular part of the landscape has changes so that it needs to update the geometry in VRAM.

Vehicles generally move around, and as long as they are just represented by a single textured square, there is probably little to nothing to gain by saving their geometries in VRAM between frames. When using the GPU, you therefore need to treat vehicles differently from the static landscape. Simutrans draws vehicles together with everything else, since it uses a slight variation of the painter's algorithm to ensure things don't appear in front of things they are behind (there are a few "unsolvable" bugs in Simutrans here).

DrSuperGood

You might also find it beneficial to hack around the simutrans source code a bit. You might end up creating a feature or adding something to simutrans that others find useful and so it ends up making it back to the source code.

Simutran's graphics are not as slow as you might think. Most of what GPUs are designed to accelerate are not really used in Simutrans.

prissi

Indeed, if you want to create a transport game with 3D then some engine will be useful.

However, that has been done too, in Schiene und Strasse (which may become OpenSource soon) in 2002 and more recently in Transport Fever (which used independent objects).

If you want to do this: It took Hajo two year to get something usable (using about 2h an evening), and I would guess that is not an unrealistic number for you too.

DrSuperGood

Creating anything 3D capable of the scale of gameplay Simutrans has is likely going to require quite a good understanding of programming and computers in general. Large expensive 3D environments are very hard to create, especially if they look visually pleasing and feature filled (not flat deserts).

For example look at Supreme Commander, it had massive scale but this came at the cost of the terrain being mostly devoid of features when zoomed in vaguely close and most of the map area never seeing anything happen in it. Supreme commander 2 added more details to terrain but in doing so they greatly reduced the scale so the maps felt small. Sure computers now are on average more powerful than back then but not that much more powerful, especially processor wise.

An older game which is much more similar to Simutrans was Railroad Tycoon 3. That supported some pretty large scale maps however that also came at the cost of maps having very low feature count (buildings in the hundreds rather than thousands range) and trains using a simpler simulation model (no signals).

Ters

A modern computer should be able to do 3D maps with the same scale and detail level as Simutrans if the buildings and trees are kept simple enough, and the vehicles aren't too detailed (or at least have proper level-of-detail control). Some reduction of the level of detail might be required for the outermost zoom level. Most games I have seen, including RT3, have a terrain grid with a finer resolution than the typical object size. It is not so in Simutrans, where objects are smaller than or equal to the tile size, with multi-tile objects actually being multiple tile-sized objects.