site banner
ArjinFerman  Tinfoil Gigachad  7d ago (text post)   316 thread views

Tinker Tuesday for November 26, 2024

This thread is for anyone working on personal projects to share their progress, and hold themselves somewhat accountable to a group of peers.

Post your project, your progress from last week, and what you hope to accomplish this week.

If you want to be pinged with a reminder asking about your project, let me know, and I'll harass you each week until you cancel the service

2
Top Bottom Old Controversial Comments
Jump in the discussion.

No email address required.

Do you have some idea on how to achieve this? I always loved the idea, but any time I took a stab at it, I ran face first into a wall. The minimalist approach is to have the entire game world happen off-engine, and than output the results as scene objects of any particular engine. That's simple enough, but then you inevitably run into stuff that the engine already has good to go out of the box (say, collision detection, including stuff like "is the mouse pointer over an object"), that would have to be rewritten in the backend from scratch, or the whole idea of separation would have to be abandoned because in the end, you're still using the engine internals.

I swear all these engines are deliberately designed to make "engine agnostic" projects impossible, so if you come up with some elegant way to do this, I'd love to see it.

No, I'm afraid my engine-agnostic is probably your strongly-coupled. There's just a few points that I try to consistently follow to make things easier for myself in the long run (but more difficult in the short one, and performance suffers, too).

  • Don't use engine-specific data types except for when directly communicating with the engine. (The casting here is a major source of performance loss, but that's a hit one must choose to take.) Example: Use your own Custom.Vector3 class or struct instead of UnityEngine.Vector3, and only cast to UnityEngine.Vector3 when assigning a value to a transform. Maybe even be cheeky and cast implicitly, but that opens up some black pits of anti-optimization.
  • Any call of an engine function should be wrapped by a non-engine-specific method, and those wrappers should be somewhat centralized (in as few files as sensibly possible) so as to limit the points of maintenance in case of engine switching. Example: Don't call UnityEngine.Physics.Raycast(...) everywhere in your code, but instead have your own Custom.Physics.Raycast(...) that in turns calls UnityEngine.Physics.Raycast(...). Now when you switch engines, you only need to adjust your Custom.Physics class to completely migrate your raycasting capabilities instead of making changes in every single class that ever used a raycast.
  • Use as few engine features as possible. This is fairly trivial for me because I hardly even do graphics, but your mileage will vary greatly if you want more out of the engine you use.

IMO, for someone who actually wants to leverage a great breadth of a given engine's potential, it makes no sense to aim for engine-agnostic design. It's a lot of hassle and performance cost for a type of damage control that doesn't even come into play unless something goes horribly wrong - and that really shouldn't happen in the first place for a well-designed, well-scoped project. The only reason why I drone on about it is because my projects are the vague, un-designed, tele-scoping, lifelong obsessions of a hobbyist with too little concentration but too much persistence for his own good.

What is this place?

This website is a place for people who want to move past shady thinking and test their ideas in a court of people who don't all share the same biases. Our goal is to optimize for light, not heat; this is a group effort, and all commentators are asked to do their part.

The weekly Culture War threads host the most controversial topics and are the most visible aspect of The Motte. However, many other topics are appropriate here. We encourage people to post anything related to science, politics, or philosophy; if in doubt, post!

Check out The Vault for an archive of old quality posts. You are encouraged to crosspost these elsewhere.


Why are you called The Motte?

A motte is a stone keep on a raised earthwork common in early medieval fortifications. More pertinently, it's an element in a rhetorical move called a "Motte-and-Bailey", originally identified by philosopher Nicholas Shackel. It describes the tendency in discourse for people to move from a controversial but high value claim to a defensible but less exciting one upon any resistance to the former. He likens this to the medieval fortification, where a desirable land (the bailey) is abandoned when in danger for the more easily defended motte. In Shackel's words, "The Motte represents the defensible but undesired propositions to which one retreats when hard pressed."

On The Motte, always attempt to remain inside your defensible territory, even if you are not being pressed.


New post guidelines

If you're posting something that isn't related to the culture war, we encourage you to post a thread for it. A submission statement is highly appreciated, but isn't necessary for text posts or links to largely-text posts such as blogs or news articles; if we're unsure of the value of your post, we might remove it until you add a submission statement. A submission statement is required for non-text sources (videos, podcasts, images).

Culture war posts go in the culture war thread; all links must either include a submission statement or significant commentary. Bare links without those will be removed.

If in doubt, please post it!


Rules


Recommended Posts And Communities

Recommended Realtime Chats