Live data from Hacker News

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

racenis.github.io

151–160 of 254 posts

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

#151
post #55

" 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 repairabl…

"Screen resolutions from 320x200 to 800x600." Still, higher resolutions were not just invented because of Turbobloat.

Important:

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

There is no 800x600 limit.

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

#152
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!

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

#153
post #85
post #19

Earlier quoted context omitted.

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 ou…

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

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.

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

#154
post #148

> 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…

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…

> 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.

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

#155

Earlier quoted context omitted.

You might enjoy "Black Mesa", HL1 remade with the HL2 engine. Played it during the pandemic. No Regrets.

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

Great game - definitely doesn't work well on linux, natively or via proton. Just in case any linux gamers were thinking of buying it.

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

#156

Just wanna say the website aesthetic is legendary. Very on brand.

Except that it would be way better if it wasn't arbitrarily limited to a tiny column. I have a large screen, use it please. Don't make me dig into the developer console to undo your fixed width in order to have a pleasant reading experience.

Seems pretty entitled if you ask me.

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

#157

I replayed Half-life 2 recently and was struck, even without high-res texture packs, how amazing the game still looks today.

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?

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.

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

#159

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 a…

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.

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