Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

racenis.github.io

Post reply on HN
Print view View original

241–250 of 254 posts

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

#241

Post by spencerflem »

adamrezich wrote: post #229
spencerflem wrote: post #110

Earlier quoted context omitted.

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.

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.

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

https://pbs.twimg.com/media/ETkH_QvXkAAD2N7?format=png

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

#242

Post by adamrezich »

spencerflem wrote: post #241
adamrezich wrote: post #229

Earlier quoted context omitted.

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.

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++. https://pbs.twimg.com/media/ETkH_QvXkAAD2N7?format=png

Wow, that's wild—almost seems like it would've been less work to just rewrite it manually at that point!

But yeah, the more cards there are on the screen at once, the lower the framerate gets—very noticeably so, when you're e.g. looking at the view of your entire deck, or when you draw several cards at once. I just assumed it was some inefficiency that entirely unnoticeable on a high-end PC (250+FPS, no problem), but was very apparent on the Switch. I never would've guessed there would be something far crazier at play than I imagined!

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

#243

Post by throwaway314155 »

vkazanov wrote: post #188
throwaway314155 wrote: post #155

Earlier quoted context omitted.

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

I don't have a windows machine at all. And until I got myself a Steam Deck I only played linux-native games. So I definitely finished Black Mesa on my 15 inch Ubuntu Dell with a dGPU.

Fair enough I suppose. I had very severe crashing issues playing both natively and via proton. You'll find similar reports on protondb.

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

#244

Post by notnaut »

hnuser123456 wrote: post #230
notnaut wrote: post #137

Earlier quoted context omitted.

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.

I feel your frustration about spending years trying to understand the right way to use an arcane system. I don't know if this is the kind of response you were hoping for, but I urge you to just pick one method and try to develop past it, see how far you can get, see if it holds you back, if you needed to generalize better. Just brute force a couple approaches at random until you find one that lets you get shit done,…

I appreciate your response! This is basically how I have managed to finish small games in the past. Only issue is much of my intention on finishing those small projects was to find the 'right' way forward, when that clearly isn't an effective way of thinking about it.

I think my best bet is to apply the same mentality you're describing to larger projects, like you're saying. As long as I don't get too sloppy, refactoring will be a necessary effort when I actually hit issues that stall my progress.

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

#245

Post by 392 »

notnaut wrote: post #111
danbolt wrote: post #78

Earlier quoted context omitted.

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…

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

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.

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

#246

Post by jorl17 »

tsumnia wrote: post #25

"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, bu…

This quote looks like it could have been written by Alberto Caeiro, right before he would turn around and apologize for putting too much thingness into things, less they become less thingy in the eyes of us over-thingers.

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

#247

Post by sim7c00 »

technothrasher wrote: post #215
shermantanktop wrote: post #64

Earlier quoted context omitted.

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?

Somebody in rural Africa once told me, "one advantage you have living in a colder area is that you don't have to run your fridge for half the year!" I honestly didn't have any good answer for him as to why I do anyway.

haha this... had similar experience :'). for ice cubes? haha

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

#248

Post by sim7c00 »

Delk wrote: post #240
technothrasher wrote: post #215

Earlier quoted context omitted.

Somebody in rural Africa once told me, "one advantage you have living in a colder area is that you don't have to run your fridge for half the year!" I honestly didn't have any good answer for him as to why I do anyway.

Depending on what "colder" means, some days it'll still be too warm outside, or some days it will be freezing, or both. Neither is good for many foods or drinks you keep in your fridge. Of course this might still be micro-optimization from a rural Africa point of view. And a part of the reason for running the fridge is still just convention and convenience.

in rural plqces often they will also use alternate ways to keep things good besides keeping things cold, because its cheaper or more easily available than using a fridge. drying things, salting (pickle? not sure of the term sry) etc. so they have less usecases for a fridge than us (lazy?) ppl whi just throw a fridge at any such problem of food preservation

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

#249

Post by oniony »

doormatt wrote: post #143
Zardoz84 wrote: post #138

Earlier quoted context omitted.

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.

Loading times from floppies wasn't even remotely quick.

That's why, back in the day, we bought hard drives. I still fondly remember my first 52MB hard drive, which consisted of a huge plastic enclosure the shape of the Amiga that attached to the expansion port off the side.

I had this one: https://www.jaruzel.com/blog/amiga-500--fun-with-storage. The official Commodore one was much uglier and, from memory, only 20MB.

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

#250

Post by derefr »

kgeist wrote: post #65
derefr wrote: post #47

Earlier quoted context omitted.

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

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

I still can't really picture this. (And I've googled the concept to no avail. Is there a high-level overview anywhere? Even one specific to a certain game engine would be nice.)

I was initially picturing a DAW VST node graph, where nodes are all effectively top-level-peer specifications to build top-level-peer actors; and the connections between nodes represent dataflow relationships that should be established between the actors.

But is this behavior actually more like:

• a browser DOM, where the nodes (DOM elements) themselves have types — with live behavior that depends on their types and statically-configured attribute values — but where this behavior only comes into play when a node is parented into a live "document" (where you can build nodes or entire subtrees outside of the document, hold onto them + manipulate them, and then attach/detach them to instantaneously activate/inactivate them); where all nodes are containers for child nodes whether they like it or not; but where node types are free to decide what their children "mean" — i.e. whether the children participate in the document as they expect (like nodes under an HTML tag), or whether they are passivated, acting only as private information for the parent node to consume/reference (like nodes under an HTML tag, or under a Shadow DOM shadow-root)?

• the node graph acting as something like an AST in a Lisp, where a tree-walker component "executes" the graph by recognizing nodes as macro functions, and calling those functions, passing in their parsed-but-not-evaluated "raw" child-subtree ASTs, expecting to get typed entities back in return?

• or something else, that I don't even have a mental model for?

Post reply on HN