Hello everyone, I would like to see if there is any interest in this little project that I have been working on for the past few years.
Could be relevant, seeing the direction in which the mainstream game engines are going.
I didn't really like any of the already existing options, so I tried to make my own and it turned out to be easier than expected.
It's sort of like a low-budget Unreal/Source, but with open-world streaming support and it is free and open source. Very old-school. But optimized for more modern hardware. Very fast too.
Still not production ready, but it seems like it is mostly working.
I want to finish a few larger projects with it to see what happens.
Btw, the name is probably temporary.
"A thing should be a thing. It should not be a bunch of things pretending to be a single thing. With nodes you have to pretend that a collection of things is a single thing."
Just want to say this line was great, very Terry Pratchett. Feels like something Sam Vimes would think during a particularly complex investigation. I love it and hope you keep it moving forward.
Haven't gotten a chance to mess around with it, but I have some ideas for my AI projects that might be able to really utilize it.
I'm starting to believe there is an external force that drives down the quality of game engines over time. In most tech, the things that catch on are the things that are the easiest to develop curriculum for. The shape of a node-based editor like Unity is uniquely suited to explaining over a number of classes. (Source: I had to learn Unity at my University) On the other hand, an engine like raylib can be grokked in an afternoon, so a university-level raylib class wouldn't work. So you have all these amateur game developers and programmers coming out of diploma mills, and all they know is Unity/Unreal, so companies hire Unity/Unreal, so universities teach it, etc. See also: Java being popular. Then of course, all these companies have wildly different needs for their Unity projects, so Unity, being a for-profit company that serves its customers and not a single disgruntled programmer, has to conform their engine. So you end up with 'turbobloat.' (amazing term, btw)
The Half-Life and Morrowind engines are in a unique situation where they're put together by enthusiastic programmers who are paid to develop stuff they think is cool. You end up with minimal engines and great tech, suited to the needs of professional game developers.
This seems like something that sits in between a raylib and a Unity. I haven't used it, but I worry that it's doesn't do enough to appeal to amateur programmers, but it does too much to appeal to the kind of programmer who wants a smaller engine. I could be very wrong though, I hope to be very wrong. Seems like the performance here is very nice and it's very well put together. There's definitely a wave of developers coming out frustrated from Unity right now. As the nostalgia cycle moves to the 2000's, there's a very real demand to play and create games that are no more graphically complex than Half-Life 2.
Anyway, great project. Great web design. Documentation is written in a nice voice.
I wholeheartedly agree with the turbo bloat problem. Machines are so much more powerful nowadays, but most programs feel actually slower than before.
Very cool project. And the website design is A+
> Most Unity games look like very bad, even with fancy shaders, normal mapping and other techniques.
This seems to be an increasingly common point of view among those of a certain age.
It is definitely the case that the art of a certain sort of texture mapping has been lost. The example I go back to is Ikaruga, where the backgrounds are simply way better than they have any right to be, especially a very simple forest effect early on. Some of the PS2 era train simulators also manage this.
The problem is these all fall apart when you have a strong directional light source like the sun pointed at shiny objects, and the player moves around. If you want to do overcast environments with zero dynamic objects though you totally could bypass a lot of modern hacks.
I replayed Half-life 2 recently and was struck, even without high-res texture packs, how amazing the game still looks today.
As someone currently working with a little team trying to make low-poly games using Godot - this is awesome!
> Also when creating things with nodes, you have to go back and forth between node GUI and code.
> All of the mainstream engines have a monolithic game editor. It doesn't matter how many features you use from it, you still have to wait 10 minutes for all of them to load in.
These notes really resonated; the debug loop even with Godot, using minimal fancy features, felt a lot slower than other contexts I've programmed in. Multiple editors working around a single data file spec is also a cool idea! In finding that a unified IDE makes it easier for different developers to create merge conflicts, I could see having editors of a more specific purpose may also help developers of different roles limit the scope and nature of their changes. Keen to see how the engine progresses!
You reference "Turbobloat" and engines being "bloated" - which is to some extent fair. But it is maybe worth describing what that means to you - what features you consider "bloat" and which you have omitted from the Tramway project. To some the inclusion of an RPG framework may be considered bloat, for example, yet there is one present in Tramway.
> This article will cover the usage of the framework for beginners who are either scared of C++ or just bad at it
I'm in the latter camp and want to thank you for your "Getting Started" Page. The teapot appeared and I understood things I did not think I would understand. I do not have time to finish your tutorial at the moment (due to only having 30 whole minutes for lunch), but I want to, which says more about how entertaining and accessible it is than anything.
Did anyone else find the Design Patterns page? It's a score board with a goal at 100%. I love this so much.
It only supports up to 800x600 resolution? For real? I know people like low res games and this is targeting old hardware but that is surprisingly low to me given the touting of how optimized this is.
Can you make it a bit less photorealistic? I'm afraid that people would confuse reality with the games created with it and it could pose a danger to society.
Do you plan to create some videos showing the process of setting up a basic example?
Very cool! There need to be more options for developers with lower-end boxes, for gamers with low-end hardware. Unreal Engine 5 is a lost cause nowadays without 64GB of RAM, Unity is a mess and there need to be more options than Godot.
Good. This is exactly what I've been complaining about for decades now...
I also have my own engine although it needs some refurbishment. I've never quite found the time to polish it to a point where it can be sold. It also runs on tiny old devices, although if you limit yourself to desktop hardware, that means anything from the last 30 years or so. It also has a design that allows it to load enormous (i.e. universe scale) data by streaming with most often an unperceptable loading time... on the iPhone 4 in about 200ms you are in an interactive state which could be "in game".
Unity and Unreal are top-tier garbage that don't deserve our money and time. The bigger practical reason to use them is that people have experience and the plugin and extension ecosystems are rich and filled with battle tested and useful stuff.
bespoke big company engines are often terrible too. Starfield contains less real world data than my universe app, but somehow looks uglier and needs a modern PC to run at all. mine runs on an iPhone 4, looks nicer and puts you in the world in the first 200ms... you might think its not comparable but it absolutely is, all of the same techniques could be applied to get exactly the same quality of result with all their stacks and stacks of art and custom data - and they could have a richer bunch of real world data to go with it!
I don't know anything about game programming but I quite approve of your sense of humor.
You said it's compatible with hardware from 15 years ago, but one of the examples have the graphical complexity of half-life from about 25 years ago, could this engine be optimized further to run on hardware from that vintage or at least closer to? Would be pretty cool making games that can run on a Ryzen 9950x 32 thread monster but scale all the way down to a 1Ghz Pentium III and a Voodoo 3.
Just wanna say the website aesthetic is legendary. Very on brand.
This is really cool. You should organize a game jam for it.
How is the wasm support? My main issue with Godot was large bundle sizes and slow load times. (GameMaker kicks its ass on both, but I never got the hang of it.)
From the perspective of someone who's dabbled in 3D graphics, and has made an engine for 3D visualizations for my science projects:
What is blocking this from high resolutions, and dynamic or smooth lighting? The former is free, and you can do the latter in Vulkan/Dx/Metal/OpenGl etc using a minimal pixel and fragment shader pair.
> But what if all that you really want to make is just a lowpoly horror roguelite deckbuilder simulator?
Is this a reference to Inscryption?
Neat project!
By the way, to see a great example of how a modern game can be made using the classic Half Life engine, look at the fan made game Half Life: Echoes [1].
It actually looks pretty decent, and the gameplay is top notch.
> It does what Godoesn't.
> I am not reinventing the wheel, I am disrupting the wheel industry.
I am laughing out loud
> When all of the patterns get used, I will delete the project and rewrite it in Rust. With no OOP.
https://racenis.github.io/tram-sdk/patterns.html
Love it.
> Btw, the name is probably temporary
It's announced, and the name is fine, so it'll stick :)
Love the entity init->use->yeet cycle. Fantastic terminology, may steal it.
void Entity::Yeet() {
yeetery.push_back(this);
I love the retro aesthetic of your website - it perfectly matches the spirit of the project. The detailed documentation and transparent roadmap on GitHub are excellent. It's clear you've put a lot of thought and effort into making this accessible for developers. Great job on the presentation overall!
This looks really cool, great work. One thing I want to preregister though: I bet against the whole Entity subclass thing. 60% of the way through the first serious-business project, you're going to RUE THE DAY. I'll look forward to seeing what people do :)
This sounds pretty cool! I like the name too, I would keep it like that.
This website rules.
This is a really cool project, and I love the writing style.
I am also in the early days of writing a very primitive 2.5D Raycasting engine [0] (think Wolfenstein3D) and have just got to texture mapping. Very fun
Its open source and written in C, a pretty small and easy to follow codebase so far
[0]- https://github.com/con-dog/2.5D-raycasting-engine/blob/maste...
Could call it Mega McBloatface(?)
The demo(s) should be linked from the page so that HN can complaint that the game is to hard.
https://racenis.itch.io/sulas-glaaze
https://racenis.itch.io/froggy-garden
It runs well in Firefox on my low end laptop.
Can you add the rule:
@media (prefers-reduced-motion) {
.animated {
display: none;
}
}
to the page, please? no_gifs.css is alright, but I need to visit the page (and run JavaScript) before I can find and click it, and by that point the damage is done.The writeup, demos and proofs of concept, along with transparent roadmap/todos on the GitHub page are top notch. Great presentation. I definitely see myself trying this.
This is evidence of a great moment in modern indie game dev: the power of fun and simple prototyping.
This is fantastic, actually. I love that this will let us create games in the late 90s FPS style but with all the niceties of modern hardware. Now if only I had any skill in 3d modelling...
Typo, "Trawmay"
> Everyone always says that you "shouldn't create an open-world RPG", but that's just because they have never tried using the Trawmay SDK.
Love it <3
I have very similar, strong opinions about game engines and I think this is a great project. I am definitely going to mess around with this after work today.
Makes me wonder how far can we go with simple but high quality light maps.
It a practical way to bring global illumination to the masses without real time ray tracing
I saw "fixed function pipeline" and immediately think of RTX Remix. This could've been raytracing modded in to add Turbobloat lol
I think a project like this is a good idea with the popularity of retro 3d games and "de-makes" now days
Using a modern engine seems overkill
I fucking love this!
Hope some initial tutorials become available. I’ll gladly contribute some but I need a little guide to get started.
Wait, so what is the bit about Morrowind and Half life? Doesn't seem to be mentioned anywhere.
This is great! I'm wondering if there's anything on the roadmap for multiplayer support?
racenis, what program did you use to draw the header graphic?
I dream of a Mac port, but it's beyond my skills.
Can this be used as an alternative to Hammer to develop HL maps/mods?
I like the name. It's the SDK that gives the name meaning anyway.
Damn this looks sweet! I’m gonna check this out. Cool project!
Why aren't more people commenting about Dr. Pepper?
Can it run on a MS-DOS machine with 640 KB of RAM?
Don't understand shit, but congrats on the website. Is this React 19 ?
That would call for a Wii port ;)
love the revolving toilet
I can't decide if this article is satire.
License?
You've obviously put a lot of effort into this, but I'm always lost at how people publish something open source and forget to actually put a license on there. Since now it's technically closed source, hypothetically if you become a monk in the woods next week no one else can fork your code
"Some might say "just get a better computer". This is why getting a better computer is bad:
1. Affordance: A lot of people, especially from 3rd world countries are very poor and can't afford to buy hardware to run Turbobloat.
2. e-Waste: Producing computer chips is very bad on the environment. If modern software wasn't Turbobloated you would buy new hardware only when the previous hardware broke and wasn't repairable.
3. Not putting up with Turbobloat: Why spend money on another computer if you already have one that works perfectly fine? Just because of someone else's turbobloat? You could buy 1000 cans of Dr. Pepper instead."
Took the words from my mouth. What a great project. Please keep posting your progress.