Category: Games🎮

  • 2022-25 Stunt Rally 3 🏁

    2022-25 Stunt Rally 3 🏁

    ⏱️Overview

    The continuation of our Stunt Rally game using latest Ogre-Next rendering engine.

    📂Sources

    Available here.

    Forum topic with key progress steps and few screenshots.

    SR website has Videos, Gallery, Download, etc.

    ✍️Motivation and progress

    Intro

    Well it’s probably time I write something about how this goes, it’s been months already.
    I took about 5 years break from old Stunt Rally. I was occasionally playing and enjoying it, but also ignoring any flaws, and thinking hard not to get into developing it again more (well that’s also the way for any commercial software).

    Forum Q&A👥

    In January 2022, I started thinking of checking out the new rendering engine Ogre-Next and posted on Ogre forum my topic with many questions to get more knowledge about it’s state.
    I has been developed (and used) since years (probably 2015 or so) but I haven’t seen few key features like: Gui, fog, old plugin for grass, no demos for particles or water etc. Old Ogre had plenty. Ogre-Next had many, but not the very broad palette of game related components.

    Terrain Demo⛰️

    Shortly after I gave it a try and started a small demo (sources here) with nature scene. I was quite surprised by performance, how high and smooth Fps was with lots of vegetation. Contrary to old vegetation plugin we still use in old SR, which was also the worst thing, causing lags and delays while driving. But back then even fog wasn’t part of engine and had to be added with some knowledge. Luckily new Atmosphere component for fog and sun was made not long after.

    No Gui

    Since there was no working MyGui fork (was earlier) and all else was difficult, I didn’t move much further.
    Even though Ogre-Next is still technically Ogre, about half of everything in code changed. Even using terrain was completely different as the system was new. It was good since it has better performance but it also meant a lot more trouble to use it and later port Stunt Rally stuff into it, and we have an editor for it too and own custom blendmap I made with noise.

    Continued

    Half a year later in October 2022 I got back to my terrain demo, which was based on Ogre-Next terrain sample.
    Sources for it are there and I even made a gallery, it looked cool.

    Gui🪟

    I also managed to build MyGui with Ogre-Next (forum topic) and with some help continued its fork, after some trouble later, it was fixed and started working well. This was likely the key point to start porting SR, while also knowing particles work, and my demo works smooth with better Fps and no lags for vegetation.

    SR3 start🚗

    I then started porting SR still in Oct 2022 and calling it SR3 (3.0 was also latest Ogre-Next version). First by disabling almost everything in old SR code and making it build with Ogre-Next. Then by slowly restoring stuff one at a time and I mean really slowly.

    Restoring stuff🌐

    It took months and literally almost everything was causing trouble or not working at first in Ogre-Next. It’s like normal developing, I mean I code then test and fix it to work (yeah the old way, no unit tests, seriously). On top of that, there were few annoying new bugs due to how Ogre-Next works and needed something extra to fix, what was already working normally in Ogre before.

    Fast forward⏩

    In Feb 2023 MyGui started working and could be used in SR3.
    Worse still, during my endless forum topic we found many bugs in Ogre-Next too. It’s like half of my problems end in one. A bit disappointing TBH, but that’s the way with software nowadays. It’s buggy and needs updates constantly. Which brings me to support aspect. If it was great I wouldn’t mind. And mostly it was, but lately I’m waiting 1-3 weeks for response and have many ongoing issues and unanswered questions. It’s a pity that it’s just (putting all contributors aside) mostly a one man’s project. Kind of like with SR too, especially after that one year when there were more programmers.

    Water🌊, Effects

    Last major features were: water and effects (like SSAO), probably the biggest thing. Worse still, it wasn’t developed by me, but mostly by scrawl (and others) back in 2013 or so. So I had to redo another thing in Ogre-Next by myself now. It was difficult but good learning experience. HLMS shaders, are big, complicated, have lots of code and variations, and yeah it’s much more difficult than just using a shader editor and putting together blocks or just installing a water add-on.
    We still are missing a few essential ones like: soft particles and HDR with bloom, that old SR had around 2013 already.


    📊Other engines

    Well this section might be of use and have some info. Not just SR3 history like above.
    Meanwhile I did think about other engines and shortly looked at 3 of them. There is a big list on wiki too. And I did recently write a tutorial page on CG graphics its Engines section could be better too.

    This is my personal view, and let’s keep in mind that I did look at them after SR was already made (took 5 years) and it has its own track / map editor made by me. It is FOSS too.

    Unity

    Bit older than UE I guess but also a huge hub for commercial stuff. Even the tutorial mini game had paid crap one could buy for it. That’s really the first thing that pops out instantly for me. I do hate commercial stuff. I guess you could find something “free” but its like looking for free money in city, roughly for me. It will only be a free commercial for paid stuff.
    Sure you can find stuff made already like rivers, vegetation and what not but given that this has a price, it’s instantly not for me. And it never has any other license than “you can only use it for Unity”.

    UE5

    This thing certainly got on my nerves. Turns out I don’t even have a PC for it.
    I started by trying to download. Nope, you need to get full sources with deps and then build them on Linux. I tried few times before I realized this needs over 100GB to complete IIRC. Yeah my SDD with OS is still just 128GB and the one new I got has just 512GB and doesn’t really have that much free space.

    Whatever, the next thing was a real killer for me. When it finally started (after building for hours) it showed a tiny logo with a tiny text showing that it needs to build shaders, over 4000 of them. I can’t even. And it did compile them on like 6 CPU cores for 30 minutes. Seriously WTF.. and I don’t even use this term. I don’t know for sure, but it wasn’t just once that it had to do this. I remember few times that “building all shaders” time waste, possibly even on each new project created or so.

    Well then I realized my PC (with 12 year old CPU) isn’t even in same era, UE5 would need you to first spend a lot of money for PC with latest hardware.. to probably still take a long to even start.
    Needless to say it is also a huge hub for commercial add-ons etc.

    If we look at SR which has over 200 tracks already and on average 1 of them is just 5MB, not GB we can see the huge gap. One demo in UE5 was 100GB.

    Godot

    I was pleasantly surprised to find waterways plugin for rivers and also seeing it’s MIT license. Feels like the proper way of doing stuff for FLOSS software and games like SR3. Would be nice to have it in SR for sure, but at least I can learn from it and even use sources if I ever find the time for this.
    Well, getting back to Godot, it’s big, I don’t have much of experience. It has its way of doing things and may be even extended. But let me sum this all up next.

    Common

    So let’s end this quick look around. Each game engine has lots of stuff. And I can’t even judge how long would I need to learn it, to estimate how long it would need, to port SR to it (any engine). And how would loading tracks look in it, or how much more complicated editing them would be. I’m pretty sure it’d be a waste of time and effort.
    As for game simulation, I guess I could build as a DLL or something to run in it, but that just doesn’t feel right at all. I mean what for, so that I could use engine’s features sure, but I’d need to waste a lot of time (in total) for starting it, clicking everywhere, etc. Lastly learning its issues and their solutions. Every big engine has something specific to it and problems with some things for sure.
    Meanwhile I already had a lot of code written to do what and exactly how I wanted it to be, e.g. editor for creating SR tracks.

    🟢Ogre-Next

    ❔Is it good for you?

    Obviously it depends. It is a rendering (by rasterization) engine only. So contrary to the game engines listed above, you don’t get anything beside rendering, i.e. no physics (e.g. bullet), no sound (e.g. openal), GUI, scripting, network etc.

    It is for advanced users / programmers.
    This means you need advanced programming skills to use it fully. Right now I also believe it means you need to find bugs in it yourself too. Surely there are some still and the more I use it the more I find. And I’d expect it to have none OFC, sadly that’s not possible.

    There is documentation for it, but I can’t say it is covering all topics you might need. Some features I needed later had solutions that needed to be found in older forum topics. This wasn’t easy since they’re old and I don’t know if it’s still valid and there is also plenty of unneeded text in posts.
    And support? Yeah it’s nice and great when it happens but otherwise you’re left alone with it.
    I also can’t say it’s popular. Seems it was much more earlier around 2010 and also the Ogre 1.x version is still more popular.

    Good things last, it surely has many features, modern ones too like few types of GI, HLMS shaders, etc. It is low level, meaning it can give you more control and optimization. But I don’t have any comparison here, I haven’t used any other just older Ogre.
    Surely there are others, eg. bgfx.

    ✅Why I use it

    The biggest reason is really simple. I made SR in Ogre so moving to Ogre-Next sounded like least effort. Surely old Ogre changed and I got myself stuck to shiny material generator which again scrawl wrote back in 2013 or so. Meanwhile RTSS shaders got better in Ogre, and lately even got auto instancing.
    I decided to skip all that and make a bigger step, biggest possible for better hardware and that was using latest Ogre-Next. Even with few things or components missing. It also featured auto instancing by itself which I liked most, secondly the new terrain has less batches too (more performance).

  • 2024 Unreal Engine 5 tryout

    2024 Unreal Engine 5 tryout

    ⏱️Overview

    I’ve spend over 1 month in total, exploring the Unreal Engine 5.3 on Linux and gathered some opinions about it. I’ll say upfront: I don’t really like it and this version is not even fully working on Linux. And no: I will not make or port Stunt Rally to it, I know for sure now. This isn’t a strict tutorial, but my gathered experience, many complaints, with some useful links.

    📂Gallery🏞️

    Short gallery with showcase here.
    Long gallery with many more things shown and including visible bugs.

    ✍️Motivation

    Well I have been using Ogre rendering engine since about 2007. Over a year ago moved to OgreNext, which is even less popular. I can simply say there is just one person (the developer) who is able to, and does usually answer my questions, or fixes issues.

    Naturally at some point I wanted to get at least a basic knowledge of other engines. Since they’re so highly popular and have big forums and communities. And get my own opinion, also regarding what’s best for Stunt Rally (rendering only since we already have simulation and even own track editor).

    I made 3 initial choices due to highest popularity: Unreal, Unity, Godot.
    I did already check them in 2022, and wrote a little in my Rendering “tutorial”. But ultimately for me, Unity died a sudden death due to their freaking license changes (which shocked lots of developers and made them move). I did check out Godot and so far its best demo for terrain and nature, and it didn’t seem too great at performing there. Which seems also a popular opinion that it doesn’t handle big 3D scenes that well.

    So, the goal was not really to move SR to any of them. It was to assess if that’d be even reasonable, and logically prove that it’s not (even only for rendering purpose). Last and quite important reason was to learn “the other side”, new effects and technologies, and know what would be possible to achieve in SR too (someday).

    📜Earlier try

    I did try UE on my old PC. Back then in 2020, UE5 had to be built from sources on Linux. Took me like 50 GB of space to download. And few tries to finish, as there was no info (and I had a small SSD). Then few hours to even build. Lastly at start it took 30 min to compile over 5000 freaking shaders. So ugh, yeah, clearly my PC was too old for UE5. I did try later after I bought a new PC. It does still need 5 min for shaders now. And that’s needed when major options are changed.
    Still, my impression is that most people would need to buy a new PC to use UE5, unless they already got a new gaming PC. It is really demanding on hardware.

    🔍Observations, Issues

    Of course, these are specific to me, using it on Linux. Also to what I was testing: for Stunt Rally try, so in 3D, mainly for driving cars, on gravel and for stunts.
    Also I didn’t spend years using UE just maybe over 1 month total. I could be wrong, or assumed something using my anti-commercial logic, or just didn’t care to investigate longer.

    I list here all my issues I had using UE5.

    • UE is a big commercial hub, feels like a shop. Not for true FOSS projects. Lots of assets, meant to be used for Unreal projects only. Nothing is CC Licensed. They also have own binary file format for everything, only .ini readable for options. I did import e.g. trees from .fbx (which can be exported from Blender) but that needed more work, making materials later.
    • Aimed at Windows and making big profits. Obviously if someone paid for Windows, they’re more likely to pay for its software. Linux is the least popular so least supported.
    • Not meant to be used on Linux only. Nothing can be downloaded, as this needs the freaking Launcher application which has only msi installer. Even their demos don’t support Linux, e.g. this and that. Thus IMO they don’t fully support Linux, just wanted to add it to platforms list, as only the engine works but not the rest of their ecosystem. The Quixel Bridge is also not working at all. I don’t care about that integration, to add assets directly to project content. I’m a fan of simple download buttons or repositories. But big companies progress by buying other companies and so “improving”, which is also a way to be more monopolistic.
    • Editor GUI. IMO it’s utter garbage and a mess. I wouldn’t enjoy using it daily. There is a “magical” way to scale whole GUI. But no real options to choose font sizes, icons, themes or other visual stuff. Seriously, in such a big editor, used by so many people every day? Sounds like a joke to me. I can’t take seriously any* programs which don’t allow user to (at least) change their theme and font size. *even small, but except my own. I have made my own themes for every software I used for longer.
    • Tons of properties, written in same tiny, plain text, no idea which important, no icons for settings or e.g. even colors or bigger fonts for more important/significant ones. No way to bookmark properties or settings to know which I want to remember easily. Should I like write them on paper or something like in middle ages, or remember all that? Some have tooltips (white) with decent text, some very little. At least the worst stuff is bottom in properties usually. And the (rhi) statistics texts are even smaller and less readable. I made my own Fps and statistics bar in SR and it has few detail modes now, medium size font, and even coloring from value, if it’s red that’s bad.
    • Editing terrain. Seriously cumbersome. If you ever seen or used Stunt Rally Track Editor, it should be pretty clear what I mean. Sure, I wrote it myself so it has what I find best already. I mean using just mouse wheel to adjust brush size and force. Also having keys that increase those. Then plenty of terrain brushes to choose from. All brushes using floats and computed for needed size. I could go on. We made over 200 tracks just using those tools. Seems like UE doesn’t care much about such tools. There are some other software programs (big and commercial too) that will make a terrain which you can import instead of editing. BTW I saw no way to import raw float heightmaps which we use since years for best quality.
    • Gizmo. Well it may be my personal hatred for that thing. But how am I supposed to drag that one axis if it’s covered by another. Probably need to focus, rotate around or use ctrl, meh. We don’t have a gizmo in SR editor, yes it may not be obvious how you’ll move etc, but you’ll always be able to do it, directly from anywhere.
    • Physics. I’ve seen some opinions on internet that it got worse in UE5 (has Chaos), from UE4 (had PhysX) if I got it right. So far I had plenty of sudden car jumps because of what looked to be normal wheel force from contact, getting weirdly high. Also had some sudden object jumps, flying far very quickly. All not looking good or real, seems like an unstability. I did increase substeps and decrease interval to get better simulation at high speeds, and I did surprisingly fix that wheels wobbling suspension. I could drive even over 600 km/h in big glass pipe loop and 450 in smaller one. That’s probably the only thing better than in SR with Bullet physics, but I’m still using old version and didn’t try new in years.
    • As of UE 5.3 which I tried, I was not able to turn on Nanite at all, and neither HW ray tracing. And those are UE’s biggest, prominent features. I used Debian 12 and AMD GPU with Vulkan. Saw some post that 5.4 could fix it, maybe.
    • Lumen software reflections. Man, those look laughable. I guess most would use HW ray tracing now or in few years. But I’d rather have my own cubemap rendered and used for other parts too. Instead of looking at Screen Space Reflections (a recent disease) or those blobs (done by Lumen software reflections) when screen space didn’t cover. Plus I’ve never seen car underside reflected properly here. Lastly I tried adding reflection captures and thoses didn’t work. Could be my fault, whatever.
    • Many effects are iterative, updated partly over time, and so they work best when not moving. E.g. volumetric fog lit from car lights, is moving inside car when driving. Reflections also have some noise, changing pixels. Global Illumination with Lumen, also does fluctuate and spread unevenly over time. Sure, it’s new technology and best if it didn’t melt GPUs doing impossible today. But it feels to me like these are just targeted for those indoor furniture designs and static shots, not games.
    • Many things even vehicle parameters need that Compile pressed after changing, then running to test. Really not convenient. The default vehicle simulation is completely nonsense. I guess it could be good for basic arcade games. That’s to be expected. Can’t touch dedicated C++ code for vehicle simulation like VDrift or even RoR with deformation. I found an older UE4 vehicle simulation, whole made with blueprints. Is good to learn from, didn’t feel great to drive though, but I’ve spend not much time with it.
    • Lots of thins are still done from console with typing commands. I guess no need to add them to that pile of unrecognizable settings list yet, probably translated though. But on the up side, there are plenty of options to customize for sure.
    • Crashes. Last but not least. IDK if it’s just because I use Linux, or Vulkan, or AMD, or their drivers. Doesn’t matter, either way I had many UE crashes. Luckily I didn’t loose much, seemed to be at end mostly. Still, not a good sign, not for stable software, not for daily use. Also seems to me like UE is favoring NVidia GPUs or maybe they have better hardware ray tracing, IDK and don’t have time to investigate. Ah and trying to start profilegpu did reset my PC instead.
    • Whenever you change key options it will be building over 5000 shaders again, which takes for me 5 min. And Package project at first takes like 30 min, but later it does much faster even less than 1 min. There are slow downs of like 5-15 sec whenever you save a material etc, there are structures in UE that need to be rebuild and this a slow delay when editing.

    🎛️Blueprints

    I’m kind of in the middle with this topic. Both good and bad.

    Quite a lot of stuff can be done using Blueprints. There are games made just using them.
    But then you’ll be dependent on them, which means no full control over what’s happening, and just doing what others tell you to do their (commercial) way. There is no avoiding blueprints, even with C++ code.
    Another thing is that the list with blocks in blueprints is again huge. Here even a video with main ones. So usually you’ll have to type more to find a block. Even if + or * etc is enough to get simple operations, that’s still just ridiculous for me as a programmer to put a block and connect those lines to it, instead just typing + in code.
    But yes, they’re easier to understand for non programmers. Still, I felt like I didn’t know how to do anything at all, when I was starting with blueprints. So it’s not like those were easier to start, just less to set up (no external IDE, compiler).
    Lastly big, complex games would require a lot of code, which in blueprints means few times more clicking connecting, picking blocks, to me it feels like slow playing with toys instead of developing. And then area is huge, also hard to find stuff, lots of moving around and zooming. Sure there are comments, same as in code. But much more code can fit in text editor. And it doesn’t go both vertical and horizontal (when done right). Doesn’t need zooming. I find code easier to navigate (definitions, references) too. All can be done faster by keyboard.

    There is a cool webiste with lots of blueprints here.
    One good part for blueprints (similar to scripts) is their safety, since they show errors, won’t break, etc. While code can crash, corrupt memory, loop infinitely etc. And could take more time to build and test too.

    ☑️ Good parts

    At least at start, because I seem to end them with a view that’s not good.

    • A lot of stuff working already. But as the saying goes: if something is good for everything it’s also good for nothing (i.e. not great for anything particular). Also if you wanted a change in their sources then it’s a huge amount of it to even grasp (like 50 GB total). And more games using UE will mean more will look the same due to its technology.
    • Plenty of (free) Plugins. Even fancy things like Niagara (3D smoke and fluids simulation, rather not for my/current hardware). But Water is still Experimental (yet essential), and I had some bugs with it (underwater fog was bad at times, even white flashes, then after publish it was at random level above sometimes). Very many plugins are also in Beta and version 0.1. Seems like it’s still too early. IDK maybe UE5 is still too young. I’m obviously only considering free plugins.
    • Useful modelling tools included. E.g. video. Can quickly edit and draft a scene with basic models, already inside UE. For me not needed, as we already have our assets, and tracks made.
    • Many possibilites to generate and place stuff (meshes, vegetation etc) with PCG. Still, those are rather new UE features. Which I’d expect much earlier. E.g. someone using UE4 didn’t have them, years ago. And frankly, in Stunt Rally we had automatic vegetation placing and road generation with LODs since the beginning in 2010.
    • Can move camera with W,S,A,D and Q,E, that’s cool, even bookmark places. But I didn’t find a way to change the speed by keys, and sliders don’t allow any values just predefined, IDK.
    • Plenty of debugging view modes and visualizations. Well the rendering engine is very complicated and “heavy” (high HW requirements) so these will be needed to optimize, probably even if you don’t want to. A very good (but older UE4) video series pipeline bottlenecks, passes.
    • Seems like Visual Studio is again default for C++ but at least VS Code is supported. So my setup with clang and VSCodium won’t work. And OgreNext supports clang officially. UE C++ is also in its own style. Quite old, not even similar to new C++ versions. All variables used and methods use big letters. Video here. Yes it’s a matter of preference (or getting used to) but yeah I dislike this too.
    • Many resources to learn from. Still those are commercials for Unreal and their addons etc but if you filter this out and ignore, then there can be plenty of useful, or universal information to learn in general.
    • UE is definitely huge and complex. With high popularity and big community it’s easy to find solutions to problems. But that doesn’t mean less problems. Actually I found many topics on forum which didn’t solve anything and seemed like unnecessary distraction, like from people not knowing English not only UE. Surely it was easy to find out why I got gray models after Packaging, but why on Earth weren’t shared wrap samplers the default, causing this issue. I think there is a lot of detail to be known to get UE working for any project.

    ⏳Summary

    Well definitely you can learn a lot, not only from using UE in practice, but also from that big number of videos either in their playlist, or lots of other videos from creators around UE. There is also a decent amount of documentation. This can help when starting or using UE, but also for getting information on various subjects around rendering or games etc (just at a smaller fraction).

    So it was a cool experience, completely opposite to mine. I mean using an advanced rendering only engine, built from C++ sources. Not just installed, and already with most needed tools. There is a gigantic gap or difference between those. And not only in software size and thus difficulty, but also in the community. It’s a complete opposite too. In UE (or Unity, Godot etc) you can simply even put your question in youtube and find a video (or few) with answer. When I was searching for UE vehicle tutorials there were even few playlists with that.

    Still, it’s not reasonable to change rendering or game engine far in production. Only possible at start. And SR is and already was far in production, having my own coded features, even when those engines weren’t available, that popular or so feature full. So clearly just because of that I won’t really be able to change engine. And neither would I have patience to spend 2 years or so, right after I’ve spend over 1 year to move “just” from Ogre to OgreNext.

    UE is big, and very commercial, so Windows, NVidia, Visual Studio are default, if not only option here for all things to work. So definitely not for me as a Linux only developer. I think they also use some telemetry, I’m not sure, but I saw urls, sent to their website from UE, as warnings in log, when I didn’t have internet.

    Lastly there are plenty open source engines, e.g. listed here, or new list here, also tools here, and a big collection of engine related links here with lots of libraries and sources.

  • 2024 Rigs of Rods tracks

    2024 Rigs of Rods tracks

    ⏱️Overview

    This is a notable but short entry, not much of a project, rather a contribution.
    I developed an Exporter code in Stunt Rally 3 Track Editor allowing tracks export for Rigs of Rods (also FOSS game).
    BTW also gathered many (CC licensed) assets from SR for use in RoR.

    📂Media

    Downloads
    for RoR tracks are in this topic. Also require assets from here.

    📷Screenshots
    gallery from many tracks start here on RoR forum topic. Also older WIP here.

    ▶️Video here
    Shows drive in RoR on one SR track and at end (somewhat outdated) Gui for Export in SR3 Track Editor.

    Documentation here.
    Explaining differences and how to use SR3 Export for SR or own made tracks for RoR.

    🔍Details

    I first noticed some interest in this topic. It also has a lot more detail in my posts, screens, and RoR bugs listed too. There wasn’t a lot of interest, so it was actually much more a challenge for me to try. And well it consumed me for like 3 weeks. A lot of C++ coding (76 kB in total) for that Export functionality and even my hands started hurting after (was too much typing late into nights).
    The Export also allows others to create tracks for RoR using our SR3 Track Editor.

    Finally 130 tracks from SR are available in RoR, so about 55% from 229. Is quite significant at once I think. It was also a lot of fun to drive SR tracks in RoR simulation and BTW learn about RoR code and people involved. Of course I got back to developing SR3 after.

  • 2010-15 Stunt Rally 🏁

    2010-15 Stunt Rally 🏁

    ⏱️Overview

    Stunt Rally is the game I started in Dec 2009, having first release in Apr 2010 and last (2.6) in Sep 2015. It was my biggest project by far, I developed it for 5 years almost continuously.

    Update: I started developing again after about 5 years break, and continued with new version 2.7 and moved to newer Ogre-Next in upcoming Stunt Rally 3.

    The game works on GNU/Linux and Windows. It features its own Track Editor. Simulation for cars comes from VDrift and rendering using OGRE 3D engine, more info here.

    I’m proud of what it became, but most importantly from the people I met, who contributed to this project, especially developers and track creators. The experiences gained and things learned with this project are significant. And it was a lot of fun.

    🔍Detail

    I created the 📖SR presentation book, it has 196 pages with lots of screenshots and explanations of the whole project (until version 2.6).

    You can read and see more on Stunt Rally website.

    There are few gameplay Videos and a huge Gallery (about 2000 screenshots) with a fun development gallery of same size. You can find complete documentation and even Track and Vehicle browsers.

    So, the game’s documentation will tell you everything about the game, track editor and tools.
    But it won’t tell you the history behind it. While the presentation book covers whole project (both the game and editor) in general, this post tells how it all started.

    That’s why I made this page. It’s also my dearest project and I get very sentimental every time I play it or even look at screens or videos. So I think it deserves it, and could be informative.

    📜History

    Around Dec 2009 I started looking for open source racing games, from which I could use the simulation code. My previous projects from 2008 and 2007 already showed me the limits of using only physics engine’s included car demo’s code for games. So PhysX and Newton Dynamics respectively. Bullet had its own car/vehicle demo too, so I knew it could only be fit for a basic arcade game.

    I was aiming at a simulation and wanted the most complicated code. After all I was playing Richard Burns Rally already for a long time (on keyboard), liked WRC (on gravel and from 2004-6 mostly) and actually despised any other car simulation games for being too simple (maybe RBR fans of that time know what I mean).

    Open source racing games

    There were actually just 3 games: some old code from Racer, TORCS (now SpeedDreams) and VDrift. I played them somewhat, then compiled all and tested. After that and decided that VDrift is the best, simulation code was quite sophisticated.

    The projects I didn’t consider were: SuperTuxCart (too basic, and for kids) and RigsOfRods (not a racing game, just a sophisticated vehicle simulation, but also using OGRE).

    VDrift was also still actively developed at the time. And I liked their move to also use bullet. That was simply needed to have any collision with environment.

    I edited the .car file a lot to find if it is possible to use VDrfit for gravel rally, later posting the results. It was good and fun, I played VDrift somewhat with my setups (gravel, wet, ice) since the original game was quite unplayable for me.

    Compiling VDrift and adding OGRE

    The beginning part was the most difficult. I was at the time just Windows programmer (but really liked GNU/Linux thanks to this project). So compiling a Linux project on Windows in Visual Studio wasn’t easy. When I finally managed to do it (IIRC after 2-3 weeks), I started tinkering with it, removing code I don’t want, etc. Still using the OpenGL renderer.

    Then on side, I started a simple OGRE app with just few models on scene. Later connected both. Getting the VDrift meshes to show right was a bit work (different x,y,z axes, 3D models). But without it, I wouldn’t see anything, so it was crucial.

    Once all worked I made the first release pack in April 2010. Was Windows only and most likely it wouldn’t even start without proper MSVC framework installed and such.

    It had only 1 car, VDrift tracks and no GUI. I compared the performance and started a topic on VDrift forum. It was terribly bad because of their tracks having thousands of meshes. So using OGRE for VDrift would be a bad idea. But that wasn’t my point. I knew OGRE already and in my previous attempt had a big terrain with good look and performance. I knew what I wanted in my own game and how to do it now.

    What happened next was fast (given only my free time) and needed a lot of coding and testing. But it was easier than the previous part. You can check the screenshots of funny situations from versions 0.1 to 0.5 in the first development gallery.

    Terrain

    I quickly added tire trails and particles, since they were already in OGRE and it was easy. Trails were never in VDrift and particles weren’t great. At the time VDrift moved to using bullet and that was perfect, since it was needed for any car collisions with environment. Then I added the Terrain component and tweaked code to have proper fitted heightmap triangles in bullet world too.

    Next I added PagedGeometry (I knew it already) to have some jungle vegetation, that came with Ogitor (same project we had textures from, for a very long time).

    Later I also added MyGUI. The options looked quite similar to my previous project, but this GUI system was much better and there were already more tabs.

    Also included 2 more cars. Then made the 0.2 release pack in Jun 2010, and started the topic on OGRE forum.

    Road

    Since there was no road plugin for OGRE, I started coding my own. Based on a Catmull-Rom spline, which is probably the easiest to edit and most intuitive, it just interpolates between points.

    Terrain already had its own LOD (level of detail) system. Road surely needed one too, to not quickly produce extreme counts of triangles visible. I thought of just 4 LOD levels for each road segment (auto generated in code), and a simple distance to camera check to pick one accordingly, showing less triangles further. Picture here. It wasn’t the easiest code to write, but I’m glad that I did it. It became the base for road and was extended few times later. Nothing else would fit so perfectly as own written system.

    📖Presentation

    I focused on creating the SR presentation book, which covers not just our history but the whole project with all of its aspects and implementation.
    The presentation has 196 pages with lots of screenshots and explanations.

    ⏩Fast Forward

    • 📜History of added features in each release in Old changelog.
    • 📈Statistics. Showing releases and data increases.

    What came next is summarized below in short points, in more detail than on presentation.

    Key steps of project:

    1. As described on previous pages the start was in Dec 2009 when I found VDrift and experimented with its car settings.
    2. I created the project on Google Code in 2010 to hold releases.
    3. My first release was in Apr 2010.
    4. Then came first issues.
    5. The game ran only on Windows at start. I suspected it would be rather easy to port to GNU/Linux (since both VDrift and OGRE did work).
    6. I was doing screenshot galleries on each release and game video every few. In a year I made nearly 10 releases (“Release quickly, release often”). I didn’t have a repo.
    7. After a year in Mar 2011 two guys (scrawl and Tapio) have joined and did quickly port game to Linux. Also added CMake build system.
    8. Also in Mar 2011 I created repository. Initially was Mercurial, because Google Code didn’t have Git. But then we quickly moved to GitHub (in Apr 2011 or so).
    9. At the same time we started using IRC on freenode to quickly communicate,
    10. Translations was surely one good thing done by new guys at start.
    11. In version 1.0 (Jan 2011) my track editor was ready and fully functional. I made a series of tutorials on how to use it. I was developing it further too (only I did that).
    12. Game was featured on freegamer blog, first with version 1.0. It did boost game’s popularity. Every time a post appeared after too.
    13. Since version 1.2, we started uploading the Releases to Source Forge. Google Code and its 100 then 200 MB limit were a problem. At that point it only was for homepage and issues (that view was very nice and customizable though).
    14. At some point the game was also added on playdeb, and on lgdb. I think those were (or are) the biggest Linux gaming sites and they helped with game’s popularity too.
    15. Scrawl did many things in the game. A lot of related to input (for controllers), post process effects, shaders, split screen, water in 1.5, etc.
    16. In version 1.5 we finally finalized multiplayer, done by Tapio. I was doing the Gui part. It took him a year to finish it, but I was glad anyway, since I could do other things at the time. I posted on Vdrift forum. I think, VDrift project was developing more slowly then.
    17. Scrawl did a wonderful task of creating a material generator once, and then even a second version called shiny (as a separate library for OGRE). And this thing made us reach a great look with nicely coded shaders (generated for both DirectX and OpenGL) at a higher level. I loved using it.
    18. Scrawl and Tapio were mainly active for about a year. Then I was developing alone again.
    19. We started a forum for the project, somewhat later in version 1.8, Nov 2012.
    20. Forum was great on freegamer, since there were many users already.
      It attracted the greatest people, artists creating tracks (and even sceneries) for the game using my track editor that I was also developed with the game. The best being: rubberduck who also made many buildings and objects, and Wuzzy.
    21. I guess I should also mention Calinou. He was always on IRC and had an opinion whenever I asked. This is already a useful skill. A couple of his many tracks went into the game.
    22. At some point I found out the greatest Nobiax CC0 textures and replaced all tracks terrain look, also implementing own blendmap with noise (for mixing them). There were a few such revamps of all tracks (big artistic task, bit tedious), for shaders, waters, skies. Terrain was the biggest.
    23. Project’s website was done very late in 2015, more info about it here.

    ⚖️Contributors

    There were few other people e.g. a guy who let me use his IRC bouncer. Tapio was later doing translation syncs, until I someday finally learned that. He was also hosting multiplayer game list server on his PC for years. Scrawl did later a VM setup and was making GNU/Linux binary packages on each version release. There were also few people translating the game to other languages than English (9, 5 of them fully).
    Finally, I can not forget to mention all those artist sharing their CC-BY 3D models on blendswap, also textures, vegetation, objects, and even 0 A.D. buildings. I was gathering all authors and website urls in txt files in our data/ directory each time I added something (later visible in Credits page in game).
    Naturally all the open source libraries used (including OGRE and VDrift) have to be mentioned here too, since without them the game would be completely different.

    All that was great and helpful. I want to thank all who contributed to this project.

    ➡️Break

    I was constantly developing Stunt Rally for 4.5 years. I was thinking of finishing the development a couple of times.

    I first ended developing in Nov 2014. But I returned after about 9 months for 3 more, rewriting sound system, replay files, adding pace notes and more.

    I announced development end on 19 Sep 2015. It was version 2.6, the 26th since start.

    Lastly, I have to add, it wasn’t just the 5 years it took to create all this. I took many years before that, of me learning from my projects, and having more experience every year doing so.

    Update: It wasn’t the end, but a few years break. I resumed the project 6 years later as Stunt Rally 3 since 2022.

  • 2007-08 Stunt Rally attempt

    2007-08 Stunt Rally attempt

    ⏱️Overview

    After getting more familiar with OGRE and reaching limits of Stunt Playground fork, I started doing my own project (2007-2008).

    📝Implementation

    It took previous camera code and put Ogre’s terrain component to a good use. Additionally familiarizing myself with PagedGeometry for grass and later for trees too.

    It was using fmod for sound, PhysX for physics (with NxOgre). Those were used by me at work, so it was easier. Of course I wouldn’t recommend any of those two, aren’t open source.

    🔍Detail

    Total sources were just 86kB at this stage.

    You can see Stunt Rally‘s Fps bar here in left bottom corner. Surprisingly the project still starts in 2016. Must have been the time when I finally learned not to use Debug all the time, and leave some Release builds for my future self.

    🛠️Editor

    At the same time I was also experimenting with Editable Terrain Manager to have an editor for terrain, and with RBGui which looked a lot cooler and better for me then.
    There is the first [Cam – Edit] toggle bottom left, same like in earlier Track Editor versions from Stunt Rally and a brush tool window too.

  • 2006-07 Stunt Playground fork

    2006-07 Stunt Playground fork

    ⏱️Overview

    Somewhere around 2006 to 2007 I was learning OGRE in practice by forking an existing project. It was Walaber’s Stunt Playground, original video looked quite different. Is on website, but the sources aren’t available anymore (he’s gone fully commercial).

    📜History

    OGRE was very popular at that time, had many plugins, so it was the best choice of engine for me. Its version was 1.2.1 (Dagon) then.

    GUI was made using CEGUI and physics with Newton Dynamics through OgreNewt. Both of which I didn’t continue to use later since their limitations.

    📊Features

    The game had few cars, dynamic objects, an editor for placing and moving them, loading/saving maps, replay and sound systems.

    Tracks were exported just like objects, which posed a big penalty having no level of detail on them. Plus tedious editing in 3D modellers (not in own editor) and lastly not allowing an optimized terrain, grass or trees.

    ✍️Motivation

    Back then it also had open sources, great to learn from and not too big (180kB total). Compiling them was also not too difficult for me at that time. I learned a lot by modifying the game and it was a perfectly fitting experience that moved me forward in the direction I wanted to learn, without too many obstacles.

    ➡️Next

    The static tracks got me into looking for terrain editors next. And I eventually developed my own track editor years later.

    Now, if you know Stunt Rally 😉, you can probably already start spotting something similar. Well the camera system is greatly based on this one. And particles like sparks and dust I developed then are nearly the same.

  • 2004 Frogs III 🐸

    2004 Frogs III 🐸

    ⏱️Overview

    This is the 3rd and last version of my Frogs game for 2 players. Programmed in Delphi.
    Done on college, subject was Programming (I think). I’m glad I could use my existing experience to pass it easier and more creatively.
    Previous 2 versions were in DOS and Turbo Pascal, shown here. It had exactly the same game style.

    Gameplay

    Player controls a frog, jumps to reach and catch flies with tongue. After game time, the player who had more flies wins (or there is a tie).
    It could be a slow and tricky game if flies were appearing rarely, or a fast game with lots of flies. Still, splashing flies made them fall down. Catching a falling fly would make the frog loose 3 and vomit. This was pretty hilarious.

    The screenshot is composed of few, but this is shown.

    📊Features

    Sadly, it had no sounds at all. A huge flaw compared to earlier Frogs II, which was even more hilarious with funny sounds.
    It featured:

    • Nice looking menu (my own logo art)
    • Many options, for:
      • Flies – max count, increase over time, width and height of appearance, resistance to water)
      • Frogs – jump height, resistance to water (made jumping harder), tongue speed and idle time
      • Game – game, time, showing a counter (of flies, particles, etc.)
    • Lots of particles for:
      • Water splashes (like 500 was already enough for big ones)
      • Vomit (this even had extra keys to test)
    • Waving grass blades
    • Water changing direction and look, depending on direction of frogs landing in it (e.g. always dropping from 1 side made water more fuzzy and moving faster).
      Strangely this doesn’t work at all now. But anyway I’m surprised this game still starts and works 15 years later.
  • 2003 Shooter 🚀

    2003 Shooter 🚀

    ⏱️Overview

    This is my first game in C++. Done as a project on college, subject was C++ Programming, I think.
    It was a top down space shooter and had just 1 level. Without game end, just no more enemies.

    🔍Implementation

    It was using purely Direct3D9 calls for rendering and WinAPI for Window.
    I drew the textures myself, not many.

    Player ship had 4 weapons, auto gained with game progress: main 2 dots, small lasers, main thick lasers and side dots.
    There were 6 enemy types and the layout with their movement paths was already quite nice. Enemy weapons were actually just 1 type of orange dot. One ship fired a dot, auto directed at player. Others fired 2 to 4 dots in certain directions.

    ➡️Comments

    I’m glad I managed to create a game (2nd actually) at college, where the major was basically Industrial Software for Metallurgy. It was still my main hobby back then. Since I had experience in games I wanted more to use it and develop. Was also quicker, easier and more fun to make a project for that subject.
    Code looked cryptic, I was still coding in my own way of not doing a single space if not required, and using 1 letter abbreviations for keywords and types.

  • 1997 Last DOS Games 🚁

    1997 Last DOS Games 🚁

    ⏱️Overview

    Here I will gather 2 last games I made in DOS. Each of them also featured an editor, for creating (drawing) maps.
    Still in resolution 320×200 (256 colors) and in Turbo Pascal 7.0 with parts in Assembler. This was on PC with Pentium 120MHz. I tried 640×400 later, but it was too slow.

    🚗Car game

    📜History

    The first game I just called Porsche. Poor name, it’s a brand name, so it can’t be used. But I was a kid and had a model and a poster of such car.
    On the most bottom left screenshot there is a first, starting version of this game.
    This is what’s left. Very sadly, I have lost the final version (had no others) about 1 or 2 years after.
    But I won’t forget how we played it, in the summer of 1997 with elementary school colleague(s).

    📊Features

    Game was for 2 players only and had split screen. Cars were in center, map moved below. Similar way to my earlier 2 Planes game here.
    Maps had 3 sizes (square, in pixels): small (250 x 250), medium (450) and big (700). Due to only 640kB memory big maps didn’t start in IDE, so I could only test the game on medium.

    It was a simple, rally type driving with lots of sliding (especially in winter and autumn).

    The final game had 87 tracks in 7 sceneries: Forest, Jungle, Desert, Winter, Australia, Autumn, City (latest new: Mountain).
    About 18 of them were actually just circles, ellipses and rounded rectangles. These were real fun to play with many laps.
    I still have all our track prototypes drawn on paper. They lasted way longer than any of my PCs.

    There was an editor for creating tracks, where I would draw road:

    • straights and turns,
    • bridges or dips
    • jumps (car flew for a while without control, longer with more speed at start)

    Then place trees (also all of 9 types of vegetation at once), water, etc.

    There were also few graphic attractions like:

    • staying tire trails
    • dust behind cars (on deserts)
    • screen blur effect in autumn (with more speed), kind of like rain.

    Next, gameplay features were areas, with:

    • water
    • mud (slowing down)
    • grease (less control and random turning)
    • ice (no control)

    These were already present in my earlier game from 1996.
    Water puddles in autumn were even more slippery than the wet road.

    Then were some funny things:

    • stacks of tires – didn’t damage car, but bounced it back and sounded funny
    • blocks of hay – helping on road, or side, by slowing car down, e.g. before sharp turns
    • hedges – were along road, safe, didn’t bounce or damage car
    • sharp bushes damaging car (possible on road)
    • city tracks could have crosswalks with people (few pixels), you could smash

    Game featured sounds of course. The collision detection was quite basic (bad) but worked. The car just bounced back after hitting anything (trees and such), in the opposite direction it hit.
    We had simple damage slowing down cars. Tracks had repairing areas, car didn’t need to stop just drive over them.

    So the screenshots on left, with car in center, show actually the next version Porsche II, which was started later but never finished.

    🚁Shooter

    The second game, a top view scrolling shooter, again I poorly named Rambo II. Was meant to have similar jungle style to that movie.

    I did the basic start of game, 2 enemy planes, 3 weapons for player’s helicopter, animating water (palette), sparks on hit, and explosions.
    And the editor for map was quite good. I was drawing terrain levels, then few algorithms were adding noise, blurring few times to make it look like foliage (grassy hills). Then I could put rivers, with increasing width, starting from tiny streams. Rivers had auto added rocks on sides. On screen there are 2 types visible, clear blue and olive.
    There was also a separate tool, visible in the middle, just for putting enemy ships and picking their paths in places on the map. It was possible to move the map (in time) to show where ships will be.

    Once I showed this project in class (technical high school), I didn’t have to do anything, besides attending. It was very cool.

    ⏳Conclusions

    Since the loss (of Porsche with 87 tracks) was a result of my stupidity, I’ll gather the faults that led to it, with what I learned to do below:

    • HDD fail (the worst failing Seagate 1GB). I then even bought a second of same type (was cheaper) and it failed later too.
      Well today I’m checking for fail rates of HDDs before I buy and I don’t go just for the cheapest.
      For some time I made backups on CD/DVD/BR, some lasted more than HDDs. But now I don’t, recorders cost the same as HDDs. Eventually all HDDs fail, and I think I had maybe 2 every 5, lasting longer than I needed it. Now I have one HDD more, just for backup (of important data).
    • I made just one backup copy, on floppy disks, using a freaking self extracting RAR (binary exe). Without the 1st I can’t extract any later.
      I never used self extracting type after, and also forgot about RAR after I found out 7zip, which is also supported in DoubleCommander.
    • I have overwritten the backup, the first 8 of 23 parts. I shouldn’t ever do that. There were several ways to avoid this. Worst is that it was actually a suggestion from, well the stupidest teacher I had. The one who also said “you can overclock your CPU, no problems” and my motherboard died after. Later he even ended in jail for stealing huge money sums, also some from students.
      So yeah, as the saying goes: “never follow advice from people who you wouldn’t trade places with”.
    • I never made any copy of the source code during. It was 65kB for game and 68kB for editor.
      This is so small, that I should have copied it every day. Later I started just making archives often, from just my sources.
      And since I started with github I have repositories of my main projects there.
    • I would even loose everything from DOS (my projects in Turbo Pascal) with that stupid HDD, if I didn’t copy it all to my friend. I think it was my idea, so he could learn from it. He kept it and then I could restore it back.

    Finally, I used few concepts of this car game and many actual tracks in our 3D game (started 13 yeas later) Stunt Rally. And since Stunt Rally was really well made and its track count reached 176, I don’t miss my 1997 game so much (which took 2 or 3 weeks to make). While Stunt Rally had (over) 5 years of development, and I wouldn’t make it so only by myself.

  • 1996 Tracks game 🚘

    1996 Tracks game 🚘

    ⏱️Overview

    This was my first 2 player car driving game. Well a car being here a 6×3 pixels solid color rectangle.
    Done in that great 320×200 mode, with a static view of whole track on screen. I wrote it in Turbo Pascal 7.0 in 1996.

    It was also very successful, I played it at the time with my elementary school colleges (even few visited).

    💡Implementation

    It had very basic 1 tone PC speaker sounds. And all moving graphics were blinking badly (no V-sync). I think I didn’t know how to change palette R,G,B colors yet, so it only had default 256 palette colors. But it did feature some pixel effects like leaving tire traces and palette rotation for water animation (and teleporters).

    The later tracks were at night. A cool idea that wasn’t really that great due to that blinking. Cars had lamps (a triangle) that lit (changed colors) in front of them. One track was a total labyrinth in night and one even had a lighthouse with rotating light.

    📊Features

    It had 52 tracks, in just one scenery. But they featured plenty of attractions:

    • Car damage
      It was simply decreasing car top speed. After some damage taken, a spanner icon (for your car only) would appear in a random place. If picked it would repair damage.
    • Bridges
      Actually not easy to implement in a 2D game. I implemented them with special colors, reserved for detection and making car shift level (go dark under bridge) on bridge edges.
    • Jumps
      Those gray to white areas, making cars jump (become uncontrollable) and land after some time, depending on car speed when entering.
    • Areas with:
      • Water – Simply but nicely animating and making a splash sound when entering, slowing car.
      • Mud – Slowing cars down a lot.
      • Grease – Vigorously turning car in random directions (each frame), quite funny and with sound too.
      • Ice – Car wasn’t controllable on entering and was spinning in circle until it left ice.
    • Teleporters
      Those pink-magenta blinking pixels. There could be pairs of them on track. When entered it would instantly place car in other place. They made some pretty funny and odd looking tracks possible. E.g. the track with 6 circles, you basically didn’t know where you’ll land.
    • Moving barricades
      Closing and opening in a place on track requiring to be quick to pass or blocking road and making you wait until it opens again.
    • Rubber road borders
      In red-pink color. I think the idea was to make some places not damage your car.

    🔍Details

    Since nearly all roads had borders, that was the main difficulty to slow down or quickly steer to not hit borders and take damage. Hitting a border stopped cars immediately in place (bad but easy to implement). This required cars to be steerable even without moving and around the edge not center.
    I was detecting collisions (and areas) by reading a pixel from image. Hitting other car was possible and funny (it gained speed).