Show HN: Tramway SDK – An unholy union between Half-Life and Morrowind engines
244 comments
·January 7, 2025mlekoszek
"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.
lukan
"Screen resolutions from 320x200 to 800x600."
Still, higher resolutions were not just invented because of Turbobloat.
lukan
Important:
This was just a joke from the site, I actually took serious!
There is no 800x600 limit.
plussed_reader
But also a convenient excuse to sell more ramm and disk space 'for the textures'.
shermantanktop
Hard to know how to respond to that. This could be applied to virtually all technology changes that benefit users but also make money for someone else.
I assume you use a refrigerator and not a hole in the ground with ice. Have you been manipulated into giving money to Big Appliance?
Delk
A higher rendering resolution doesn't require higher resolution textures, and a higher source resolution for textures is what would require more storage and more RAM. (I think a higher rendering resolution does require more video RAM though.)
Of course after some point a higher rendering resolution starts giving diminishing returns if the resolution for the source material isn't also increased.
Suppafly
>But also a convenient excuse to sell more ramm and disk space 'for the textures'.
Except different companies sell different things. This is like the conspiracy that women's pants don't have pockets to sell more purses.
Ericson2314
Textures are bad, but screen resolution is good.
wetpaws
[dead]
pandemic_region
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?
lukan
"Is this about optimized code in terms of cpu cache aligned instruction pipelines etc?"
That is what I would assume, but so far I did not found a reason explaining the limit. Might also just be like it, because the author likes it like it.
Narishma
They say that but the engine seems to require an OpenGL 4 GPU while the graphics look like something that could be done on a Voodoo card.
lupusreal
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.
vanderZwan
Ok, so one the one hand we have one of the most universally acclaimed PC games in history, with a team of amazing programmers and artists behind it and a 40 million dollar development budget, and which represented the cutting edge of what was possible at the time in terms of squeezing every bit of performance out of a machine. On the other we have a one-person hobbyist project that is trying to make a statement about consumerist expectations for more, more, more.
If you're sincere about that comparison then I think you're missing the point.
Being able to run something on fifteen year old machines is still plenty anti-turbobloat. And I suspect the 2010 requirement has more to do with the fact that it's pretty difficult to debug software for 1990s hardware that you don't have (or lack proper emulation for).
And if you go back far enough one reaches a tipping point where supporting old hardware can get in the way of something running on new hardware, especially if we're talking about games, unless we're really careful about what we're doing and test on real hardware all the time. Not very realistic for a one-person side project.
jameshart
What is ‘turbobloat’?
From context, I interpret it to be ‘graphics tech I don’t like’, but I’m not sure what counts as turbobloat.
taberiand
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.
null
speedgoose
Manufacturing and shipping a new computer can be worth it long term. Improvements in performance and energy consumption can offset the environmental impact after some time.
Of course for entertainment it’s difficult to judge, especially when you may have more fun on an old gameboy than a brand new 1000W gaming PC.
vanderZwan
> 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.
speedgoose
Yes it can be. Last time I did the maths for one of my use cases. It was a matter of a few years, when replacing a few old amd64 boxes by a single Mac mini.
tsumnia
"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.
tines
In isolation, isn't the quote prima facie so bad and so wrong though? We think of collections of things as single things constantly. A human is a collection of body parts, body parts are collections of chemicals, chemicals are collections of molecules, molecules are collections of atoms... and yet at each level we think of those collections as being single things. Not being able to do that is just... absurd.
The project looks awesome though.
CrimsonCape
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"
devin
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.
stevage
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.
jjslocum3
Yes! In programming speak, you're talking about levels of abstraction.
throwaway290
The thing about nodes is a joke like around 80% of the text.
jameshart
It sounds like the sort of thing Sam Vimes would say before being begrudgingly forced to admit, after being forced by Sybil to undergo some painful personal growth, that maybe, sometimes, a thing might need to be more than just a thing.
And that Vetinari’s entity component system might seem complicated but it works, damnit and it makes the city function.
tsumnia
And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD
(I'm just glad someone got the reference)
lelanthran
> And once Nobby says he likes Tramway, everyone realizes Vetinari was right all along XD
Well, except for Detritus
derefr
This quote is likely intended for people who've tried other solutions and disliked them, but as someone who's never used a game engine of any kind, I'd appreciate someone giving me an ELI5 of how "nodes" relate to "pretending that collections of things are things."
Is the problem here that using a nodal editor encourages/incentivizes you through its UX, to assign properties and relationships to e.g. a `Vector` of `Finger`s — but then you can't actually write code that makes the `Vector<Finger>` do anything, because it is just a "collection of things" in the end, not its own "type of thing" that can have its own behavior?
And does "everything is an Entity, just write code" mean that there's no UX layer that encourages `Vector<Finger>` over just creating a Hand class that can hold your Fingers and give the hand itself its own state/behavior?
Or, alternately, does that mean that rather than instantiating "nodes" that represent "instances of a thing that are themselves still types to be further instantiated, but that are pre-wired to have specific values for static members, and specific types or objects [implicitly actually factories] for relationship members" (which is... type currying, kind of?), you instead are expected to just subclass your Entity subclass to further refine it?
kgeist
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.
2muchcoffeeman
There may be no clear boundary where an entity "begins" and where it "ends"
Is this useful to not know where the boundaries are? Sounds like it can become a night mare.
danbolt
I think the paragraph after is really interesting:
“Also when creating things with nodes, you have to go back and forth between node GUI and code.”
You can see Godot’s Node/GDScript setup as a bit of a response to this argument. Or, they try to make the “going back and forth” as seamless and integrated possible with things like the $ operator and autocomplete.
That said, I do think at the end of day, the “thing is a thing” mindset ultimately prevails, as you have to ship a game.
notnaut
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.
392
I think you and I are at the same point in Godot progress. I have chosen to do everything in one scene and leave the code where I first put it when experimenting. It's my project, I'll find the code when I need to change it. Lots of crazy overabstraction on YouTube tutorials by people who are not software engineers but who think obfuscating working code makes them so. Let's sadly look away from why our industry gives them the impression that that's a good idea. I will finally have to learn separate Scenes when I give up on one level with teleports and shift to loading, which may be never.
I watch clickbait Godot tutorials on YouTube on 2x speed in my spare time. When I stumble into a problem that I suspect has been solved before, like your resizeable platform problem, I go to YouTube and see if I can find a reference. For your case, I think you're looking to create a Tool, maybe. You'd need to define your platform as a programmaticly sized node using either tile maps or that texture thing that lets you define the corners, the fill texture, and size from there.
But if it were me I'd lift the code for the platform out of the node that sizes it. Then you can just hand edit each platform, and link the platform to the controlling node (or whatever relation you see fit to use).
It's important to focus on the game over the infinite ways you could structure code in an environment of such high flexibility. At least coding your game with bitmaps in C you can't get lost in trifles, you'll just spend more time reimplementing and understanding the basics. See raylib.
Tanoc
I'm used to the old old school way of doing things, meaning you write shit in a text editor and then run it. There's no parenting system, no hierarchies, no inheritances, no massive trees of various classes/subclasses that you have to manage. Godot goes beyond friction and actively pisses me off because what should just be ten seconds of writing in a new text document turns into up to sometimes two or three minutes of interacting with the GUI because you have to create a new project, save it, make a scene node, create an object node, create a sub-object node, create an action node, create a container node, then you can start editing code, but only once you link whatever it is to that specific object instead of it being a general script you can re-use, because re-using it means making copies of the parent object and-- It's too complicated.
A lot of 2D game engines are near frictionless because they're just "write and save" style simple, and Blender Game Engine was actually great about translating this to a UI, and more importantly a UI dealing with 3D since every object in the viewport could just have it's own little code block attached to it just by clicking it. It was no different in function than saving the .py file in a new folder, really. This method Unity "pioneered" of everything having to be part of a giant tree in the asset manager is such a slog and makes keeping track of anything during iteration a nightmare. I still prototype in BGE sometimes because every other 3D engine sprawls too quickly and has so many unnecessary steps.
If somebody could just write a text-only "write and save" style editor like LOVE2D but for 3D (and support it for longer than two months) that would be amazing.
bowsamic
Honestly this is the kinda stuff that put me off Godot. A million ways to do things and they all seem bad or feel like they’re going to shoot me in the foot later. Somehow I never had these issues in Unity
whoknowsidont
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.
taneq
Unfortunately everything is a collection of things pretending to be a single thing, even single things. The best we can do is pretend, or avoid finding out.
amjoshuamichael
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.
bombcar
The other thing to remember is the games and the engines built together handle each other - Doom couldn't have a floor above another floor (engine limitation because of CPU limitations) so the level designers created tricks to make it feel like it did.
When you're designing both you can take advantage of features you add but also avoid the ones you can't do well - or even change the art style to "fit" the engine - pixelated angular mobs fit Minecraft quite well, but once they start getting more and more detailed you're in an "uncanny valley" where they look worse and more dated than Minecraft - until you finally have enough polygons to render something decent.
amjoshuamichael
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.
zeroq
A guy who worked on Bioshock (lead design?) said in an interview:
"At work if we want to experiment with a new idea I have to assembly a team, and spend at least a month before we have something we can work with. Meanwhile, at home, I can make a whole Doom campaign in one evening."
(quoting from memory, sorry)
cpeterso
There are new games that still use (modern forks of) the Doom engine!
https://store.steampowered.com/curator/42392172-GZDoom-Games...
lyu07282
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
wtetzner
I think it's more acknowledging the gain in development efficiency you can get by working on something with lower fidelity.
spencerflem
I love library based game dev, like raylib or libgdx, but there is a reason that games like slay the spire moved to unity and then godot for their sequel.
That is to say, I don't think people are using Unity because they were mistaught by complexity loving professors.
__jonas
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.
amjoshuamichael
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.
spencerflem
No, they started with a code only framework (my beloved LibGDX) and then moved to Unity/Godot for the sequel for pragmatic reasons. See my other comment.
Being ubiquitous was part of the decision, yes, because it means there are many high quality plugins instantly integratable which is a huge time-saver.
__jonas
I’m curious, what was/is the reason? I would like to learn more about the tradeoffs people are experiencing.
spencerflem
This is mostly on switching from Unity to Godot: https://caseyyano.com/on-evaluating-godot-b35ea86e8cf4
But also features this brief comment on game libraries:
"More than a Game Library: Having worked in SDL and LWJGL I’d like a bit more handholding. A few in-house APIs for loading/unloading resources, font stuff, and display handling please. I don’t want to write those; I want to make games!"
and some words on LibGDX in specific
"The reason we chose LibGDX for Slay the Spire was because it could do PC, Mac, and Linux. Yes, it runs in a JavaVM and it has all sorts of problems but it’s write once, run anywhere amirite? No. It don’t run on consoles and Mac and Windows updates constantly break it. "
All that said, I still love LibGDX, raylib, löve, and if I was going to make a game I'd use one of those because I think they're more fun. But I'm also not doing this professionally, on a deadline, and with a requirement to work on consoles
adamrezich
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.
spencerflem
I'm not sure. I can tell you that the port was done by a third party that needed to transpile the java code first to C# and then to C++.
inthebin
Games used to be crisp as hell, and now they run like shit, crash, and take 150gb to download, and 150 years to launch. If we played games for graphics, one of the most popular MMOs wouldn't be based on a browser game from 2002, in fact we wouldn't be playing games we would be playing real life.
Look at what Epic Games did with fortnite. They killed a competitive scene game that ran smooth for turbobloat graphics and skins.
dr_kiszonka
> and programmers coming out of diploma mills, and all they know is Unity/Unreal, so companies hire Unity/Unreal, so universities teach it, etc.
There is a similar phenomenon with ArcGIS.
matheusmoreira
Surely there's something good about Unity and its nodes if games like Kerbal Space Program can be made with it.
rootnod3
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+
p1necone
> but most programs feel actually slower than before
I feel like this is only true for people who happened to luck out with slightly overpowered hardware in very specific time periods.
As someone who used pretty average hardware in the windows 98/2000/xp era as a teenager even a low end modern laptop with an ssd running Windows 10/11/KDE/Gnome/Whatever is massively more responsive even running supposedly bloated webapps like vscode or slack.
Zardoz84
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.
doormatt
Loading times from floppies wasn't even remotely quick.
draven
> 20 Mhz machine
14 MHz !
diggan
I don't understand the term "turbobloat", never heard it before (and I've made games), the author doesn't define it and a quick search returns the submission article on Kagi, while nothing relevant at all on Google.
So, what does it mean? Just "very bloated"?
Edit: Reading around on the website and seeing more terms like "Hyperrealistic physics simulation" makes me believe it just means "very bloated".
pmichaud
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.
adastra22
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.
Sharlin
It’s funny that the "turbo-" prefix is simply derived from the word "turbine", as in a turbocharger works by means of a turbine, similarly "turbojet" or "turboprop" or "turbopump", but has turned into an augmentative prefix due to the connotations, and also because of the parallelization of "turbocharger" with the earlier term "supercharger", meaning a charger powered mechanically by the crankshaft.
adinisom
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.
null
refulgentis
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.
fidotron
> 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.
speeder
Yes. And the thing is, some modern games ARE overcast with no dynamic lights, and then go on to use Lumen of all things. This was the case with Silent Hill remake, and that thing runs very slowly, looks WORSE on PS5 Pro, the grass looks worse than in older games and so on.
Seriously, the plot of Silent Hill was invented to justify optimization hacks, you have a permanent foggy space called "fog space" to make easier to manage objects on screen, and the remake instead stupidly waste a ton of processing trying to make some realistic (instead of supernatural looking) fog.
OCASMv2
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.
realusername
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.
jameshart
Most good looking games built with Unity don’t ’look like Unity games’ so people don’t think of them as constituting an example of ‘what Unity games look like’. So the archetype for ‘what a Unity game looks like’ remains at ‘pretty rough’.
The ‘art’ of making stuff look good has not been lost at all. It’s just very unevenly distributed.
When a team has good model makers and good texture artists and good animators and good visual programming, it looks great, whether it’s built in Unreal or Unity or a bespoke engine or whatever.
fidotron
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.
Tanoc
There's an insistence that materials can overcome lacking texturing and normal mapping. It's not true, but it's a result of a lot of marketing fluff from things like Unreal Engine being misunderstood or misrepresented. Did you know that in Super Mario Sunshine, for "sharp" shadows the Gamecube was unable to render, that they actually used flattened meshes instead? In Delfino Plaza the shadows under the canopies near the Shine Gate are actually meshes instead of textures. Meanwhile the tile plaza that the mesh shadows lie on looks so nice because it's not one giant texture, it's actually several dozen 128x128px textures all properly UV mapped. In a modern game you'd get two brick textures and a noise pattern to blend them, and they'd all be 2048x2048px with the shadows being raytraced so they have sharper edges.
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. Less pointy spheres is one thing, but physically modelling all the cracks and scrapes on the sphere is just stupid and computationally wasteful.
fidotron
> 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.
OCASMv2
Easier to market "more resolution" and "more polygons" than masterful use of uv mapping.
bombcar
You can get something working quite quickly (especially with things like Unity) - but to get them looking amazing takes extra skill and polish.
Even a "2D" game like Factorio has amazing polish difference between original release, 1.0, and today.
(This can very obviously be seen with modded games, because the modded assets often are "usable" but don't look anywhere near as polished as the main game.)
robertlagrant
I replayed Half-life 2 recently and was struck, even without high-res texture packs, how amazing the game still looks today.
gmueckl
I think this is because of how extremely cleverly they picked the art style for the game. You have a lot of diffuse surfaces for which prebaking the lighting just works. Overcast skies allow for diffuse ambient lighting rather than very directional lights, which force angle-dependent shading and sharp high contrast shadow outlines. And the overwhelming majority of glossy surfaces are not too shiny which also helps out a lot. All of these are believable choices in this run-down, occupied, extremely dystopian world. And the texturing with its muted color palette pulls it all together.
kcb
There's been a rumor going around that developers move away from prebaked lighting primarily because it complicates their workflow.
gmueckl
Prebaked lighting is a rather crude approximation that only looks good in certain scenarios. Correct dynamic indirect lighting provides a much better integration between different scene elements and better spatial cues. Movable and static objects can share the same lighting model and you don't get an immersion breaking situation where e.g. the one door that you can open in a hallway stands out because it has worse lighting. It is an overall win, not just during production.
throwaway314155
That rumor didn't exist 20 years ago when Half Life 2 had come out. Pre-baked was the only way to go. Now we have performant ray-tracing.
royaltheartist
That's why I think really good art direction beats raw graphical power any day. Source was pretty impressive back in the day, but the bit that's stood the test of time is just how carefully considered the environments and models are. Valve really put their resources into detailing and maximizing the mileage they got out of their technical constraints, and it still looks cohesive and well-designed 20 years later
tombert
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.
robertlagrant
Definitely. A hyper-talented team combining new physics-based gameplay, art style and rendering technology made something just amazing.
GrantMoyer
Half-life 2 has received multiple updates to shading and level of detail since it was released, so it looks a little better than it did at release. Still, it was already a visually impressive game at release.
gaudystead
I just replayed Half Life 2 less than a week ago! I also caught myself thinking, "the levels may not be as detail filled as modern games, but the artistic direction both in graphics and level design is better than many modern designers with bigger budgets."
robertlagrant
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!
prettyStandard
You might enjoy "Black Mesa", HL1 remade with the HL2 engine. Played it during the pandemic. No Regrets.
vkazanov
Black Mesa is how I remember the original game. Worth every second i spent with the game!
throwaway314155
Great game - definitely doesn't work well on linux, natively or via proton. Just in case any linux gamers were thinking of buying it.
Narishma
Did you play the original Half-Life 2 from 2004 or one of the "remasters" (though they weren't called that) that comes every few years that updates the graphics and/or engine slightly?
robertlagrant
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!
jamesfinlayson
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.
null
nxobject
That's such a pity, I always wanted to play HL2 on DirectX 6 mode.
potato3732842
Yeah, it was great. They really pulled out all the stops when it came to cinematic quality on that one. They also did a lot of second order things like marrying the scenes to the plot that a lot of games don't well or at all.
mr_briggs
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!
gavmor
I am pretty proud of figuring out how to TDD a C# module without booting Unity for a hackathon last month.
Managed to contribute my bit from an underpowered netbook.
I had never written a line of C# before, but I'll be damned if I'm going to concede TDD from the CLI. I knew it could be done, and I made it work. Everybody thought I was crazy, though, and none of the sponsors' DevRel were any help.
And, of course, the biggest point of friction for us, that weekend, was our beefiest machine still had to boot and reboot the damned Unity IDE for a thousand years! Incredible the fetters some folks tolerate.
mr_briggs
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?
smcl
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.
racenis
That's why added it in as an optional extension. It is a part of the larger engine project, but it is completely optional.
I like the C++ principle of paying only for what you use.
smcl
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.
0xEF
> 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.
tiborsaas
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?
TehCorwiz
Did anyone else find the Design Patterns page? It's a score board with a goal at 100%. I love this so much.
humptybumpty
Linked from the home page:
”Design patterns used 82%.
When all of the patterns get used, I will delete the project and rewrite it in Rust. With no OOP.”
fidotron
I was looking for ages and still haven’t found this.
gield
fidotron
Thanks!
That is legitimately hilarious. This whole thing is like some massive appeal to pragmatism.
prettyStandard
You have to click on "Enterprise Mode" to find
> Design Patterns Used
> 82%
null
gleenn
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.
mathnode
Think of it as a fantasy console, like pico-8 which despite the extreme restrictions is home to some incredible content that of which exceeds many big studio engines. The imposed ceiling now allows a solo dev or a team to now concentrate on delivering gameplay and vivacious content instead of graphical gimmicks which eat resources both for the consumers and creators.
Nobody argues that FTL, Minecraft, baba is you, Stardew valley, RuneScape, or dwarf fortress are not a high enough resolution.
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.