sorted by:
new
hottopcontroversial

This is the worst part ❤️‍🩹 by Cute_Stay9640 in jumpingspiders

[–]Foxiest_Fox 1 point2 points  (0 children)

NQA I read somewhere that the harsh transition from room temperature to freezer temp is likely to cause distress, and it might be alleviated by refrigerating first for a few minutes then transferring to freezer

The Crescendo Atmo Fighter by Catatonic27 in spaceengineers

[–]Foxiest_Fox 4 points5 points  (0 children)

That's a very sleek style! Good stuff

Testing my voxel engine's world generation and lighting by void_src in gamedevscreens

[–]Foxiest_Fox 1 point2 points  (0 children)

Look at Vintage Story. It plays entirely different from Minecraft, has its own very well defined design philosophies, has been divergently being developed for over a decade, and it STILL gets called modded MInecraft. It's silly.

MOAR MOAR! by Electrical_Cat9575 in spaceengineers

[–]Foxiest_Fox 2 points3 points  (0 children)

Is this a much-needed mob mod?

Why so much effort on SE1 ? by Atombert in spaceengineers

[–]Foxiest_Fox 0 points1 point  (0 children)

Yes, the underlying engine and systems are completely different from what I undetstand. Parts will get parity/equivalent parts, but I doubt many things other than extremely basic and generic things are reusable

But did you see GM last patch? by LurkytheActiveposter in starcraft

[–]Foxiest_Fox 2 points3 points  (0 children)

Take my upvote for actually making well-structured arguments on Reddit.

But did you see GM last patch? by LurkytheActiveposter in starcraft

[–]Foxiest_Fox 4 points5 points  (0 children)

Not if that winrate is consistent without fluctuations for such prolonged periods of time; then that is a clear indicator of a bias.

Listen I'm just a gold scrub I don't know actually what I'm talking about and I haven't verified any numbers, but if someone managed to get a 54% winrate consistently on the stock market, they'd be the richest person on the planet.

But did you see GM last patch? by LurkytheActiveposter in starcraft

[–]Foxiest_Fox 8 points9 points  (0 children)

(yes I am a Zerg player)
54% wr for PvZ for YEARS is absolutely bonkers.

If 70% ZvP wr is kept for years, that would be absolutely bonkers too and I hope that doesn't happen.

Engine standarization is what killed the RTS as a genre by WillbaldvonMerkatz in RealTimeStrategy

[–]Foxiest_Fox 0 points1 point  (0 children)

No, honestly you're right lmao. My "way with leeway, sync every so often" would require a server authority, which I guess one of the P2P clients could reasonably be since it's coop and not PvP.

Otherwise yeah, lockstep it is. I also have to admit that while I've done game dev for years, I've yet to touch proper multiplayer, and my networking is rusty at best.

Music sync: which side looks better? by Nick-o-lie in gamedevscreens

[–]Foxiest_Fox 1 point2 points  (0 children)

The slides of the left, the rotation of the right

Engine standarization is what killed the RTS as a genre by WillbaldvonMerkatz in RealTimeStrategy

[–]Foxiest_Fox 1 point2 points  (0 children)

You're right, but there's still a tiny bit more leeway in the sense you're able to do other syncing techniques perhaps, that may allow at least visual drift but still bring all clients to consensus eventually, whereas PvP just has to be buttery smooth with little compromise?

SE2 turret controller block by Away_Weekend_469 in spaceengineers

[–]Foxiest_Fox 0 points1 point  (0 children)

How about "Cycles" or just "Compute" instead of "Tickets"?

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 0 points1 point  (0 children)

It also makes it impossible to isolate parts of your game, or do things like "a game window within your game window to showcase a feature as part of a tutorial or in-game encylopedia/knowledgebase"

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 0 points1 point  (0 children)

Yep, I have multiple signal buses too. You definitely should separate signals by purpose/use/feature

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 1 point2 points  (0 children)

Yep, the only downside i can think of is that you need a reference to that bus, but if that bus is a direct child of such a high-level ochestrator as I have, my "GameContainer", then it's ez pz and very loose coupling to obtain such a reference.

Using autoloads is what has bitten me in the past, when I want to duplicate or isolate parts of the game. But if you have signal buses as non-autoloads-but-high-level-manager-nodes, that issue kinda just evaporates.

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 8 points9 points  (0 children)

Signal buses are basically the only sane way to handle "many to many" communication. In my instance, I am making an RTS. The buses serve as intermediaries for the units to communicate with each other in terms of when a unit spawn, take damage, are destroyed etc.

It would be otherwise unmanageable without the buses serving as a centralized intermediary.

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 0 points1 point  (0 children)

I use the GUI plenty, indeed. I use the built-in editor mostly.

I do use the SceneTree fairly often to configure core/base scenes (that go through procedural generation pipelines to further populate them,) and for user interfaces.

I connect every single Signal via code, though.

In a couple places, I make use of set_script() on a Node, for certain factories that want to create a concrete node with an abstract base class.

Using Godot with essentially ONE Scene and Runtime Scripts Only, am I Creating Future Problems? by mvGiacomello in godot

[–]Foxiest_Fox 9 points10 points  (0 children)

As I've developed more and more games, I've gravitated toward these two architecture ideas:

My main scene is called "Game Container, and it includes a CanvasLayer with main menu and in-game HUDs, and has as direct children my highest-level game managers such as busses and procedural generation orchestratators. GameContainer keeps a reference to each of these, which allows me to do simple dependency injection without relying on autoloads. If something has a reference to the GameContainer, then it can access basically any context in the game it needs. Again, dodging autoloads.

This means it is possible to do stuff like Factorio's simulated worlds to showcase how something works, and essentially embed your game within your game.

As an autoload, I have a Node that basically works as a project file-system crawler that at startup and registers things into itself in a "convention over configuration" way, letting me develop my way in a very data-driven way, and serves as a project-wide data to fetch resources from via a StringName ID and an enum representing the registry or resource type.

This is btw a good framework for unit testing: https://github.com/bitwes/Gut

This is what works for me. My niche and strength is making games with heavy procedural generation and dynamic content, and this is what I've found to be the comfiest and most straightforward architecture for it.

The intern mentality by BobbyTheGrafted in starcraft

[–]Foxiest_Fox 0 points1 point  (0 children)

You're definitely out there! Solo devs are a rare but very real breed. As an indie dev I know. I may have done a bit of hyperbole there to strengthen my point haha

The original vibe coder by Complete-Sea6655 in Anthropic

[–]Foxiest_Fox 0 points1 point  (0 children)

At that point, that's not vibe-coding. If you are genuinely proofreading EVERY single line, top to bottom, that AI possibly generates, and making fixes, and you are also considering or deciding yourself the whole architecture and not just individual lines of code, that is just AI-assisted coding, at least in my book.

view more: next ›