Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines

Important:

This was just a joke from the site, I actually took serious!

There is no 800x600 limit.

But also a convenient excuse to sell more ramm and disk space 'for the textures'.

Is that a hard wired limit? I know nothing about game engines, so I'm a bit in the dark why it would only support up to that resolution. Is this about optimized code in terms of cpu cache aligned instruction pipelines etc?

Requires a 15 year old card (so, 2010.) Six years after Half Life 2 but looks like Half Life 1, which shipped with a software renderer (no GPU needed at all!)

I fear the turbobloat is still with us.

The whole post in tongue in cheek, it just means "features the game you're making doesn't need (like modern graphics with advanced shaders and super high resolution requiring the latest graphics cards)".

If you're making a game that needs those features, obviously you'll need to bloat up. If you're not, maybe this SDK will be enough and be fast and small as well.

> after some time.

This is doing a lot of heavy lifting in this sentence.

What you're talking about is called the embodied energy of a product[0]. In the case of electronic hardware it is pretty staggeringly high if I'm not mistaken.

[0] https://en.wikipedia.org/wiki/Embodied_energy

Agreed. Type systems are nearly always "temporal" yet are too simply designed to address that.

"Temporal" to mean that at any given slice of time during a running application all objects have a signature that matches a type.

Yet most programming languages only allow compile-time analysis and "runtime" is treated as monolithic "we can't know at this point anything about types"

I think maybe it is intended as a critique of systems where the individual parts don't compose or scale particularly well, where it feels sort of hollow to call it a "system" because of how uncoordinated and inefficient it is at the "single things" layer.

I think the point is that a body is obviously and intuitively a thing, and doesn't need any pretending. Whereas take something like a marketing brand that has been spread too thin over a bunch of disparate products, everyone has to pretend really hard that it is one thing.

The thing about nodes is a joke like around 80% of the text.

Yes! In programming speak, you're talking about levels of abstraction.

And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD

(I'm just glad someone got the reference)

In a node-based engine, everything is just a graph of mostly ready-to-use nodes, all you do is create nodes, parent them, delete them; behavior can be attached to specific nodes. There may be no clear boundary where an entity "begins" and where it "ends", because everything is just a bunch of nodes. I'm not sure why the author is against it, in a proper engine you can quickly prototype mechanics/behaviors by just reusing existing nodes/components, and it's very flexible (say, I want to apply some logic to all child nodes recursively -- no problem; or I want to dynamically remove a certain part of a character -- I just unparent the node), and often such engines allow to test things without stopping/recompiling the project. On the other hand, OP's engine apparently requires you to do everything by hand (subclass Entity in code) and recompile everything each time. Basically, a node-based engine is about composition, and OP apparently prefers inheritance.

I’ve been trying to learn godot for years and I’m not doing so hot. This chatter feels very relevant to my struggles but I’m not the best with software design, so what do I know? I was in a tizzy the other day and spammed my thoughts out about it, I hope it’s relevant here.

trying to wrap my head around using scenes vs. nodes in something simple like a 2d platformer.

Platforms:

My thinking: I'm gonna be using a ton of platforms, so it'd make sense to abstract the nodes that make up a platform to a scene, so I can easily instance in a bunch.

Maybe I'm already jumping the gun here? Maybe having a ton of an object (set of nodes) doesn't instantly mean it'd be better off as a scene?

Still, scenes seem instinctually like a good idea because it lets me easily instance in copies, but it becomes obvious fast that you lose flexibility.

So I make a scene, add a staticbody, sprite, and collision shape. I adjust the collision shape to match the image. Ideally at this point, I could just easily resize the parent static body object to make the platform whatever size I want. This would in theory properly resize the sprite and collision shape.

But I am aware it's not a good/supported idea to scale a collision shape indirectly, but to instead directly change its extents or size. So you have to do stuff based on the fact that this thing is not actually just a thing, but several things.

This seems like a bad idea, but maybe one way I could use scenes for platforms is to add them to my level scene and make each one have editable children. Problem with this is I'd need to make every shape resource unique, and I have to do it every time I add a platform. This same problem will occur if I try duplicating sets of nodes (not scenes) that represent platforms, too. Need to make each shape unique. That said, this is easier than using scenes + editable children.

Ultimately the ‘right’ way forward seems to be tilemaps, but I wanted to understand this from a principles perspective. The simple, intuitive thing (to me) does not seem possible.

When I ask questions about this kind of stuff, 9/10 times the suggestion is to do it in a paradigmatic way that one might only learn after spending a lot of time with an engine or asking the specific question, rather than what I would think is a way that makes dumb sense.

The problem is "a thing is a thing" only gets you those exact things with those exact thing-behaviors.

Sharing behaviors or making things look or act like a little bit like this other thing becomes an absolute nightmare, if not out right impossible, with "a thing is a thing."

There's a reason graph based systems or ECS is basically the corner stone of every modern engine. Because it works and is necessary.

Oh, absolutely. I maintain the engine for my video game and it's ultra-minimal tailored to my needs. That leads to better performance, and a much slimmer build size. (currently sitting at ~900KB for the optimized build of a nontrivial game, assets bundled separately). It's also a better development experience, imo.

My argument was mainly about these more generalized engines, like raylib, 'Tramway', or Source.

There are new games that still use (modern forks of) the Doom engine!

https://store.steampowered.com/curator/42392172-GZDoom-Games...

It's like with cyberpunk if they didn't use red engine which is horrible bloatware they could've finished the game in half the time with half the people and it would run on a 10 year old laptop in 60 fps. /s

Another thing related to this that I found kind of interesting, is this post [0] (unfortunately on twitter) of the developer of Caves of Qud, where they fully ported their game from Unity to Godot as an experiment, showing that they seem to have built the game around a single node, essentially just using Unity (and then Godot) as the presentational layer, similar to a simple graphics library type thing, basically ignoring the whole node system of either engine.

I wonder if this kind of architecture might also be a pretty good approach. The fact that they were able to port the game to another engine within a day is pretty impressive.

[0] https://xcancel.com/unormal/status/1703163364229161236

I don't think that the developers of Slay The Spire were taught by complexity loving professors, no. But education does more than influence the people at universities. Education informs norms, traditions, and styles that permeate through industries. An example from outside tech: the music notation app Finale found a strangle hold on the education market, and now it's one of the standards for notation, despite being the worst option (source: have you tried Finale?).

I've never played the game, but my understanding is that Slay the Spire largely impresses on a design and artistic front, not a technical one. Its engine requirements were not based on feature set or code quality, but on what developers knew. So they probably picked Unity because it was ubiquitous. Education starts the problem, and then devs who need something common they care hire for continue the problem. I don't blame devs for this, it's the right choice to make and obviously Slay the Spire is great, but I am saying that this is a force that drives down the quality of game engines.

I’m curious, what was/is the reason? I would like to learn more about the tradeoffs people are experiencing.

Doesn't Slay the Spire rerender every card's render target every single frame? It runs like dogshit on the Switch for no good reason, given how graphically simple the game is compared to other titles on the platform.

Well... I recommend you to try an old Amiga 1200 . You will find a big surprise how this 20 Mhz machine it's highly responsive, and boots faster that any current machine with Windows 10/11. However, it would not look fancy to our current eyes.

I took it to mean "increasingly bloated over time relative to hardware, phased in a funny, irreverent way." It's a vibe thing, not a definition thing.

I don’t think it is a real word. “Turbo” means “very” or more accurately “extremely,” but is typically only used in a positive context, e.g. turbocharged. That makes the turbobloated neologism ironic and funny.

Because of that factor, I'm not quite sure what's going on with the article or comments here altogether.

If you gave it to me in a cleanroom and told me I had to share my honest opinion, I'd say it was repeating universally agreeable things, and hitching it to some sort of solo endeavor to wed together a couple old 3D engines, with a lack of technical clarity, or even prose clarity beyond "I will be better than the others."

I assume given the other reactions that I'm missing something, because I don't know 3D engines, and it'd be odd to have universally positive responses just because it repeats old chestnuts.

If bufferbloat is increased latency caused by excessive use of increasingly available RAM, then turbobloat is increased latency caused by excessive use of increasingly available CPU.

Certain vintage hardware had a "turbo" button to unleash the full speed of the newer CPUs. The designers blind to the horrors of induced demand.

It's not the 90s anymore. Using basic linear fog with ultra-realistic assets would just look terribly out of place.

The point about Lumen stands though. Baked lighting would have been much better in this case.

It's worse than that, in the Silent hill remake, everything is being rendered behind the fog too, yes you read that right, they render a whole town with complex gemetry to hide it with fog after so you see none of it.

I don’t think that is what people are getting at, since they uniformly want more texture detail.

There are a lot of technically polished Unity titles that get knocked because they look like very well rendered plasticine, for want of a better description.

For example, there was an argument on here not too long ago where various people pushing the “old graphics were better” (simplification) did not understand or care that the older titles had such limited lighting models.

In the games industry I recall a lot of private argument on the subject of if the art teams will ever understand physically based models, and this was one of the major motivations for a lot of rigs to photograph things and make materials automatically. (In AAA since like 2012). The now widespread adoption of the Disney model, because it is understandable, has contributed to a bizarre uniformity in how things look that I do think some find repulsive.

Edit to add: I am not sure this is a new phenomenon. Go back to the first showing of Wind Waker for possibly the most notorious reaction.

> Ironically as we've gotten hardware with more VRAM and higher bus speeds we've decided to go with bigger textures instead of more of them. The same with normal mapping, instead of using normal mapping alongside more subdivided models we've just decided that normal maps are obsolete and physically modelling all the details is technologically forward way.

This right here is precisely what I alluded to in another reply as the motivator for generating meshes and PBR materials from controlled photography. Basically you now have enough parameters per texel, which interact in distinctly unintuitive ways, that authoring them is a nightmare, hence people resorting to what you describe.

Easier to market "more resolution" and "more polygons" than masterful use of uv mapping.

There's been a rumor going around that developers move away from prebaked lighting primarily because it complicates their workflow.

Still baffles me how unnerving the Ravenholm level is even today. It's got a creepy, unsettling vibe, 20 years later, entirely due to really decent art direction.

Definitely. A hyper-talented team combining new physics-based gameplay, art style and rendering technology made something just amazing.

Great! I really liked the intro, with the Socialist state-style architecture and processes, and that degrading infrastructure contrasting strongly with the sleek, modern weaponry held by the oppressors. I could've just walked around that world and been pretty happy with the game!

Black Mesa is how I remember the original game. Worth every second i spent with the game!

I don't think there's any official way to play the original 2004 version (or even the Source 2006/Episode One version either). The Xbox version is probably closest but they used palettised textures for the Xbox version - something that no PC version of Source ever supported - probably to get it to run okay.

Fair question - no, I just played whatever's on Steam, on Linux. Maybe the textures are higher quality, but I remember the physics-based gameplay fresh as when I was playing in 2004!

I'm not very familiar with Unity and it's limitations / difficulty of this task. What challenges did you encounter and how did you solve this problem?

Understandable, but the main thing was - you lean a lot on the idea of "TurboBloat" being this universally understood concept. And I think many people might have a vague feeling that a lot of modern software is slow and "bloated", but you may want to be clear on what you consider "bloat".

The RPG engine was just an example of why it may not be such a universal thing, I'm not saying it's bad - but clearly you think that is not "bloat" whereas to some it might be. So it's maybe better to head this off at the pass and just write a little paragraph with some examples of bloat you have observed in other engines that you have consciously avoided in Tramway.

https://racenis.github.io/tram-sdk/patterns.html

You have to click on "Enterprise Mode" to find

> Design Patterns Used

> 82%

Minecraft is a bad example. It uses low resolution textures, but the screen resolution is as big as your display. I'm not even sure what the maximum is.

i've been doing this for decades and my bedroom work had never done anything but put unreal and unity to shame. from top to bottom i can not understand the ignorance of their design from a simple "a programmer is making this" standpoint, it comes from a legacy of "a rookie wannabe with too much money had a good shot and too much promotion"

unreal is fucking awful, its a masterclass in how to not make:

* components

* hierarchies

* visual scripting

* networking

* editors

* geometry

* rendering

* culling

* in-game ui

* editor ui

* copy-paste

* kinematics

* physics integration

* plugin support

* build system

its just a tower of mistakes i learned not make before i dared to even enter the industry

it is fantastically and incredibly bad.

unity is a bit similar but they add c# complexity to the mix and in the beginning that was a much bigger disaster, especially going with mono. .NET was an enormous misstep by microsoft and remains so, although it improves over time they could have just not gotten it so incredibly wrong to start with.

i could go on.

i definitely blame the developers. of the terrible tools, i couldn't make that badly at most points in my career including the super early days in some cases.

they are also hard to fix because of the staggering depth of the badness.

if you would like more specifics feel free to poke, its more about not typing a wall of text than the cognitive load of knowing better, which is around zero.

oh... and the garbage collection is garbage that enables incompetents to make more garbage. never needed or wanted it. i had one hard memory leak to deal with in my life in native code. and a fucking zillion in their shit fest.

EDIT: i shit you not, it has not learned my first lessons from being an 8 year old trying to draw mandelbrot sets in qbasic.

You can use modern MSVC or Clang with an old C runtime/Windows SDK. It's a pain in the ass since new compilers are way stricter with what they compile, so you get a bunch of warnings, but it will work.

Lots of people don't think super wide text is pleasant.

dude it's period correct just hit ctrl/cmd and plus and zoom in like the rest of us.

Seems pretty entitled if you ask me.

>too early for a game jam

All the more reason! Then you'd fix it faster ;)

Great info! That answers my question entirely.

Time to cook up a PR.

It's the same GIF that's used in the polish milk soup song video.