[HN Gopher] Show HN: Tramway SDK - The Unholy Union Between Half...
___________________________________________________________________
Show HN: Tramway SDK - The Unholy Union Between Half-Life and
Morrowind Engines
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.
Author : racenis
Score : 390 points
Date : 2025-01-07 16:22 UTC (6 hours ago)
(HTM) web link (racenis.github.io)
(TXT) w3m dump (racenis.github.io)
| whalesalad wrote:
| Just wanna say the website aesthetic is legendary. Very on brand.
| lawlessone wrote:
| makes me feel like a kid again.
| bigstrat2003 wrote:
| 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.
| whalesalad wrote:
| dude it's period correct just hit ctrl/cmd and plus and zoom
| in like the rest of us.
| 999900000999 wrote:
| 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
| racenis wrote:
| I just realized that I had forgotten to actually add the
| license file to this repository. Added it now.
|
| The license is MIT. Thanks for noticing.
| d_k_f wrote:
| An MIT license file was added (or edited) a minute ago in the
| repo :)
| 0xdeadbeefbabe wrote:
| I like the name. It's the SDK that gives the name meaning anyway.
| CodeCompost wrote:
| This sounds pretty cool! I like the name too, I would keep it
| like that.
| andai wrote:
| 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.)
| racenis wrote:
| I would say that it is way too early for a game jam.
|
| The webassembly builds seem to work fine. A basic project would
| take up around 20MB and takes a couple of seconds to load in,
| so it's not great, but then again I haven't done any
| optimizations for this.
| pelagicAustral wrote:
| Can this be used as an alternative to Hammer to develop HL
| maps/mods?
| amlib wrote:
| It showed trenchbroom being used to make maps and I don't think
| that can be used to develop goldsource maps, so most likely
| not.
| to-too-two wrote:
| Damn this looks sweet! I'm gonna check this out. Cool project!
| robertlagrant wrote:
| I replayed Half-life 2 recently and was struck, even without
| high-res texture packs, how amazing the game still looks today.
| GrantMoyer wrote:
| 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.
| gmueckl wrote:
| 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 wrote:
| There's been a rumor going around that developers move away
| from prebaked lighting primarily because it complicates their
| workflow.
| gmueckl wrote:
| 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.
| potato3732842 wrote:
| 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.
| prettyStandard wrote:
| You might enjoy "Black Mesa", HL1 remade with the HL2 engine.
| Played it during the pandemic. No Regrets.
| vkazanov wrote:
| Black Mesa is how I remember the original game. Worth every
| second i spent with the game!
| royaltheartist wrote:
| 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
| robertlagrant wrote:
| Definitely. A hyper-talented team combining new physics-based
| gameplay, art style and rendering technology made something
| just amazing.
| tombert wrote:
| 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.
| gaudystead wrote:
| 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."
| Narishma wrote:
| 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?
| rideontime wrote:
| This website rules.
| TehCorwiz wrote:
| Did anyone else find the Design Patterns page? It's a score board
| with a goal at 100%. I love this so much.
| fidotron wrote:
| I was looking for ages and still haven't found this.
| gield wrote:
| https://racenis.github.io/tram-sdk/patterns.html
| fidotron wrote:
| Thanks!
|
| That is legitimately hilarious. This whole thing is like
| some massive appeal to pragmatism.
| prettyStandard wrote:
| You have to click on "Enterprise Mode" to find
|
| > Design Patterns Used
|
| > 82%
| humptybumpty wrote:
| 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."_
| rootnod3 wrote:
| 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+
| diggan wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mlekoszek wrote:
| Ontologically, it implies the existence of Turbobloat
| 3000.
| refulgentis wrote:
| 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.
| adinisom wrote:
| 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.
| p1necone wrote:
| > 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 wrote:
| 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.
| fidotron wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| jameshart wrote:
| 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 wrote:
| 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.
| bombcar wrote:
| 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.)
| andrea76 wrote:
| Can it run on a MS-DOS machine with 640 KB of RAM?
| 0xEF wrote:
| > 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.
| csh602 wrote:
| 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.
| tsumnia wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| jjslocum3 wrote:
| Yes! In programming speak, you're talking about levels of
| abstraction.
| stevage wrote:
| 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.
| derefr wrote:
| 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 wrote:
| 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 wrote:
| _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 wrote:
| 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.
| whoknowsidont wrote:
| 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.
| notnaut wrote:
| 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.
| bowsamic wrote:
| 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
| danbolt wrote:
| I think every developer finds footgun issues with various
| tools for their aims. Or, I know developers that express
| similar sentiments towards Unity (or Unreal, proprietary
| engines, etc.).
|
| When a game team is successful, it can often stem from
| having picked tooling and workflows that enabled them to
| be productive enough and avoid enough pitfalls. That's
| going to change from project to project and team to team.
| dingdingdang wrote:
| Are there any Godot FAQs or documentation with "blessed"
| paths for the various mainstay gamedev needs?!
| notnaut wrote:
| Man maybe I should have started with unity but I'm such a
| fucking hipster I just never go with the popular thing.
| Ultimately happy I don't have to worry about the
| licensing BS and I still get to claim hipsterdom, but
| it's clashing with my desire to work in ways that make
| sense to my poo brain.
| jameshart wrote:
| 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.
| LordDragonfang wrote:
| > But what if all that you really want to make is just a lowpoly
| horror roguelite deckbuilder simulator?
|
| Is this a reference to Inscryption?
| desireco42 wrote:
| 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!
| amlib wrote:
| 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.
| racenis wrote:
| The oldest computer that I have tried running this engine is a
| HP laptop from 2008, running a 32-bit version of Windows XP.
|
| It seemed to work fine, but I did have some issues with the
| Direct3D 9 renderer. The renderer works fine on other
| computers, so I have no idea if it's a driver bug (Intel tends
| to have buggy drivers) or if it's a bug on my part.
|
| The biggest problem with using old hardware is drivers. Older
| drivers will only work on older operating systems and it's
| difficult to find C++20 compilers that will work on them.
| davikr wrote:
| 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.
| OCASMv2 wrote:
| Still waiting for bevy to get an official editor.
| mathnode wrote:
| In my youth I cut my teeth on the quake 2 sdk. And even without
| a 3D suite and a c compiler I could get creating. When the Rage
| toolkit became available, almost none of the community were as
| besotted with eagerness as they had done before. It was a 30GB+
| download with some hefty base requirements. While rage could
| run on a 4 core machine, not many gamers at the time had 16
| core Xeon's and 16gb of ram! The worst the HL2 modding scene
| had to contend with was running Perl on windows.
| jheriko wrote:
| 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!
| 999900000999 wrote:
| >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.
|
| Both are effectively magical sandboxes where platform support
| is someone else's problem.
|
| Unity is still pretty great, but it's chained to a company that
| has no real business plan to sustainability.
|
| Unreal is okay, but developers aren't using it right. For any
| bigger project you should customized the engine for your needs.
| Or at the very least spend some time to optimize.
|
| But we need to ship and we need to ship now.
|
| Blame the developers not the tools.
| pmichaud wrote:
| 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 :)
| Baguette5242 wrote:
| Don't understand shit, but congrats on the website. Is this React
| 19 ?
| bnetd wrote:
| Based.
| divs1210 wrote:
| 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.
|
| [1] https://www.youtube.com/watch?v=fBQKi6vGX8U
| gleenn wrote:
| 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 wrote:
| 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.
| dmonitor wrote:
| 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.
| poglet wrote:
| I could be wrong however I believe all listed games can be
| run in full screen at modern resolutions.
| mlekoszek wrote:
| " _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 wrote:
| "Screen resolutions from 320x200 to 800x600."
|
| Still, higher resolutions were not just invented because of
| Turbobloat.
| plussed_reader wrote:
| But also a convenient excuse to sell more ramm and disk space
| 'for the textures'.
| shermantanktop wrote:
| 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?
| mlekoszek wrote:
| To an absolute hardliner for appropriate technology,
| probably -- but simplicity isn't necessarily all-or-
| nothing, and (IMO) helping people pull off cool things
| with simpler tools isn't so bad.
|
| https://en.wikipedia.org/wiki/Appropriate_technology
| shermantanktop wrote:
| Sure, but we're not talking about how to irrigate a field
| here, we're talking about being limited to 600x800
| resolution when playing a game.
|
| Some people were teenagers when that was the best you
| could get, so I'm guessing they see it as a "good old
| days" baseline that they can be principled about while
| indulging their nostalgia.
| lukan wrote:
| I remember that was the best I can get and I was thrilled
| for it at the time. But then I was even more thrilled
| when Far Cry came out. Then Crysis ... why would I go
| back? Now you surely can argue, that nowdays the
| creativity got lower in favour of just more textures, but
| I like to have both.
|
| Still, for a simple game limiting to 800x600 for
| performance and dev reasons - why not? But for me it
| means I see no use case for myself.
| mlekoszek wrote:
| I can see that, but I think calling it _just_ nostalgia-
| driven is judging a book by its cover.
|
| First off, I want to say you can totally have a design
| ethos that covers game engines as much as irrigation
| systems -- Lee Felsenstein explicitly cited Ivan Illich's
| notion of 'convivial technology' as an influence on his
| modems. And Illich mostly talked about bicycles.
|
| What I see in this project is a specific kind of
| appropriate technology -- 'toaster compatibility' --
| mixed with conscious adoption of old methods and
| aesthetics to serve and signal that end. Which is cool,
| IMO.
|
| HTMX uses similar techniques in trying to 'bring back'
| hypermedia and reduce dependencies, although I think
| they're after a different kind of simplicity. And of
| course, their Hypermedia Systems book makes similar nods
| to 90s-software aesthetics: https://hypermedia.systems/
| 6510 wrote:
| It is enough to make gameplay the main challenge?
|
| https://i.chzbgr.com/full/9632128256/hDF15F98F/cat
| dclowd9901 wrote:
| I would argue refrigerators provide a lot more utility
| for most people than high poly counts.
| Yossarrian22 wrote:
| I think I've gained more utility from being able to look
| at 3 spreadsheets at once than I've gained from my
| refrigerator(not if we're counting the refrigeration of
| the supply chain for food and medicine then that wins out
| by a landslide)
| Suppafly wrote:
| >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.
| lukan wrote:
| "This is like the conspiracy that women's pants don't
| have pockets to sell more purses."
|
| Oh my god, this explains everything!
|
| (btw. I recently learned, that the 9/11 inside job
| conspiracy evolved. Nowdays the standard theory is, that
| there were not even planes in the first place, just bombs
| and smoke)
| cess11 wrote:
| Still less weird than what actually happened, that Bush
| Jr and Cheney went to the 'international community' and
| made obvious lies and then invaded two countries and
| killed and displaced millions upon millions of people and
| got away with it.
| Ericson2314 wrote:
| Textures are bad, but screen resolution is good.
| pandemic_region wrote:
| 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 wrote:
| "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 wrote:
| 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.
| jameshart wrote:
| 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 wrote:
| 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.
| golergka wrote:
| > 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.
| klibertp wrote:
| Woah, it's cutting it close - just 3-5 aren't used! The Rust
| port might be on the horizon :D
| dicytea wrote:
| Time to cook up a PR.
| bityard wrote:
| I don't know anything about game programming but I quite approve
| of your sense of humor.
| jonny_eh wrote:
| > Btw, the name is probably temporary
|
| It's announced, and the name is fine, so it'll stick :)
| smcl wrote:
| 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 wrote:
| 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.
| irskep wrote:
| racenis, what program did you use to draw the header graphic?
|
| I dream of a Mac port, but it's beyond my skills.
| wizzwizz4 wrote:
| 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.
| ppage wrote:
| love the revolving toilet
| pyrolistical wrote:
| 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
| superconduct123 wrote:
| 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
| amjoshuamichael wrote:
| 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.
| spencerflem wrote:
| 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.
| zeroq wrote:
| 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)
| bombcar wrote:
| 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 wrote:
| 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.
| the__alchemist wrote:
| 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.
| racenis wrote:
| There's literally nothing preventing you from dragging the edge
| of the engine window and resizing it, or calling the screen
| resize function from the C++ or Lua API.
|
| That bit about 24-bit color and 800x600 resolutions was mostly
| meant to be a fun nod to promotional text that you could find
| on the backs of old game boxes.
|
| The default renderer for the engine is meant to emulate what
| you could achieve with a graphics card that has a fixed-
| function graphics pipeline.
|
| I'll do more modern renderer later, for now I am mostly
| focusing on the engine architecture, tools and workflows.
| the__alchemist wrote:
| Great info! That answers my question entirely.
| 0xdeadbeefbabe wrote:
| Why aren't more people commenting about Dr. Pepper?
| 6510 wrote:
| 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.
| thetoon wrote:
| That would call for a Wii port ;)
| stevage wrote:
| Wait, so what is the bit about Morrowind and Half life? Doesn't
| seem to be mentioned anywhere.
| HeckFeck wrote:
| 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...
| purple-leafy wrote:
| 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...
___________________________________________________________________
(page generated 2025-01-07 23:00 UTC)