Game Development

1- left and right buttons ✔️ 2- down button ✔️ 3- volume button ❌

/rant

Thats it i opened instagram and after not opening for 2 years, all i can see is stupid AI crap. there is nothing else, i search for game dev tag, still ai crap.

this is feeling like dead internet.

I decided i will not include anything from AI in the game i develop, i will make it fully old school.

I wanted to make a silly video after the idea popped in my head. It took about 5 minutes.

I'm working on a project that's scaling up a bit fast in term of files and content. As such I need a way to keep these files organized.

The godot documentation recommends keeping resources and assets close to their scenes. I used to do the opposite, separating assets by type and linking them in my scenes.

Now, what the docs recommend is good but how to avoid duplications when you need to use the same resource at multiple places?

Say you have a gunshot sound, your player can use it, your enemies too.

Option A (the docs way):

/enemies/cowboy/gunshot.ogg
/enemies/cowboy/cowboy.tscn
/enemies/turret/gunshot.ogg
/enemies/turret/turret.tscn
/player/gunshot.ogg
/player/player.ogg

Here I have a redundancy of gunshot.ogg, so if later I want to edit the sound, I have to remember to swap it at 3 different places.

But on the other hand, the scenes are better "packed" for reusability on other projects and it "feels right"

Option B (my way):

/gameobjects/player.tscn
/gameobjects/cowboy.tscn
/gameobjects/turret.tscn
/sounds/gunshot.ogg

Here my naive way reduces redundancy, if I want to update the gunshot sound, I can just replace the one under /sounds/. The project is smaller which is also a (very) good benefit.

However, if I want to make another game, reusing those scenes is a pain because I'm dealing with missing resources and finding who needs what to work.

Is there a middle ground method, some Option C I'm not seeing?

Thank you for reading ^^

https://vitorga.itch.io/keep-it-up-right-web-version

It's just a part of the whole bee movie meme genre. Please let me know if you enjoyed it. Reddit sucks so I made my account to share here instead. I coded everything myself, and did all the assets, beyond what I get from cc0 sources.

Not sure how far I'll go with this but I'm having a lot of fun so far. Shoutout to https://opengameart.org/ for all my temporary assets.

So far I've got dialogue via Dialogue Manager, NPCs, factions, enemies with different weapons projectiles & hitscan, and 8 directional sprites. Not bad for 2 days work.

For context, I am creating a HOI4-style strategy game set in the Cold War. The battles will likely be turn-based rather than involving maneuvering troops on the map.

A large part of the Cold War involved various proxy conflicts between the two global superpowers, the Americans and the Soviets. If I make it do that the player is only able to intervene in these proxy conflicts, things like "mega-factions" (the sort you see in games like HOI4 that are a pain to deal with) would no longer be a problem, and it also means a lot less work for me to add all the different factions joining in to create a huge WWIII.

However, if I limit the player to only intervention in other countries, that would limit the alternate history scenarios the player can take, and it would also mean that many countries could effectively become NPCs. I could implement a civil war mechanic, where certain focus paths will lead you to a civil war between two or more factions within your country, and you could seek intervention from the major powers. This would help countries in Latin America, Africa, Asia, etc. to be more fun to play if there was no direct war mechanic.

Finally, if there was a direct war mechanic, how should the game react to the Americans and Soviets being in direct conflict? Should the game end once a nuclear weapon has been fired, indicating that nuclear annihilation has occurred?

https://codeberg.org/ZILtoid1991/pixelperfectengine

Originally the editor was a completely separate project, but due to massive architectural changes, it got left behind. So later I decided to put it into the engine's repository. Then I had the thought:

Why shouldn't the editor be a direct component of the engine? It would even allow in-game editing of levels in the game. Then it can be individually turned off

However this makes me give a few more dilemma. Should I just use the engine's newly added high-resolution overlay capabilities to show the windows on top of everything? Should it be a separate window? Should it be an option for both?

I'm not a game dev so please forgive me if this is the wrong place for this type of question but I'm looking for some resources to try and understand why games take so long to compile.

For context, I've worked with former game devs who've mentioned that builds can take anywhere from 4 to 6 hours to complete - even with a distributed architecture - depending on the hardware. That shit blew my mind. They said it has something to do with compiling shader permutations but didn't go into anyore detail. That said, I have a very primitive understanding of what shaders are but I mostly work with infrastructure and optimizing build systems.

Like I said, I'm not a game dev, im just curious. I appreciate any insight or resources you throw my way. Thanks!

Great video with some tips I have not heard before concerning seemingly trivial decisions that cause serious issues as projects get larger.

The creator is an experienced programmer but seems brand new to making videos. That said, apart from an annoying number of calls for action ('leave a comment...'), it is well produced, especially for a first crack at the craft.

This is really good if you're wondering what a publishing company's contract might look like. They published it to give gamedevs an idea of what they should expect.

They're also celebrating funding 24 different games! I wonder when those will start coming out.

i spent some time this week building a small wordle clone and integrating it into my app.

the process was actually pretty fun. the main parts were building the word validation, handling the tile states (correct letter / wrong spot / not in word), and making sure the guesses update instantly for the each player. the UI took a bit of tweaking too so it feels responsive and not laggy when revealing the tiles.

the interesting part was fitting it into the rest of my app since it’s more of a social space with rooms and games (we already have mafia and spyfall). so the wordle game had to work cleanly alongside those without breaking the flow of the rooms.

it’s still pretty simple right now but it works well and people have started playing it.

if anyone is curious, you can check it out here: The Hideout

Hi everyone,

Recently I’ve been experimenting with different image-to-video and AI video generation tools, and I kept running into the same issue: it’s actually pretty hard to quickly test rendering speed, performance stability, and output consistency across different setups.

So I built a small free tool to help with that. It’s mainly designed to run simple performance tests and see how different models or configurations behave under load.

The site is here: https://volume-shader.net/

Right now it’s pretty minimal, but it lets you run quick tests and compare how different image-to-video pipelines perform. I originally built it just for my own workflow, but figured it might be useful for others who are experimenting with AI video generation or rendering pipelines.

If anyone here works with AI video tools, diffusion models, or rendering setups, I’d really appreciate any feedback on what kind of metrics or tests would actually be helpful. I’m thinking about adding things like:

frame generation benchmarks

latency comparison

GPU utilization tracking

batch rendering tests

Totally open to suggestions. If you try it and something feels confusing or missing, let me know and I’ll improve it.

Thanks!

A few years ago I decided to fix my biggest gripe with Unity's InputSystem: there is no intuitive and fuss-free way of determining which UI, character controller, popup, etc. should be receiving inputs at any given time.
Sure, the Action Maps are a great baseline for handling this since they let you assign a set of inputs to each given system; but you still have to make sure to enable and disable them at the correct moment. This can be easy in a small project, but when you have dozens of systems and UIs to contend with; it can get kind of messy.

So I started working on a system that sort of "automatically" handles all the mess for me and handles the complexity on its own.
After a few years of working on it when I felt like it in my spare time, I'm officially taking InputLayers out of beta:

You can get InputLayers for free on the asset store.

What is InputLayers?

The short version is that it's a system that lets you assign input actions to layers that "stack" priority. So when your popup comes up on screen, its layer is added to the top of the stack; and as long as no other layer takes its place, only inputs from that layer will be taken into account.
There's a bit more depth to all this, with layer priorities that prevent less "important" systems from taking over higher priority ones; but at its core; it basically lets you set things up using a single configuration window; and then never have to worry about if your character will keep moving when your main menu is open, or whatever other similar conflict you can imagine.

Video overview

I go over the core idea in a little bit more detail in this video: https://youtube.com/watch?v=bXEuzpbGlCI

Sample scenes

I've included a few sample scenes that cover most of the basic use cases. Their code is a bit complex if you're unfamiliar with UI Toolkit, but I've mostly isolated the fussy stuff so you can concentrate on understanding how the actual InputLayers stuff get handled.

Documentation

I've set up the documentation over on GitHub for ease of access; and so that people can post issues they may encounter easily.

Creating a good (and successful!) game is beyond challenging, especially in our trying times. What's been your experience with balancing different aspects of your own projects?

I am creating a strategy game similar to Hearts of Iron IV that is set during the cold war. Each nation will have their own focus trees, and technologies need to be researched as well. The twist is, rather than maneuvering troops on the ground, war will instead be turn-based, like Pokemon battles. My issue now is I need to plan out how war will feel like, whether it's one large battle or many smaller battles.

Having a large battle makes things much more strategic as you pretty much have to play the long game and think far ahead, but the main downside is that it can be long, boring, and it would stop you from doing anything else for several in-game years. One potential solution for this is perhaps you could temporarily leave the battle screen to do other stuff, but you would become vulnerable if you don't manage your army (perhaps generals and such could be unlocked as you go along to automate some tasks? That would turn the game into one of those idle games though, and those usually aren't very fun)

Having many battles that pop up could be a good alternative, as then you could do your focuses, research, and stockpile equipment between battles. It also makes the battles less boring/tedious as each battle could be unique in some way with various different challenges, whether that's taking a fort on a hill or crossing a fast river. There would probably be a war score meter of some kind, that ticks up when you win battles and goes back when you lose them.

The problem with this one is that I'm not sure how to transition the player from non-battling to battling, it would probably involve the use of events, where you could either go on the offensive (gain a temporary attack bonus but become vulnerable if you don't succeed quickly), stand strong with defensive (gaining a temporary defense bonus), or retreat (losing war score but preserving your equipment stockpiles). This might be annoying as it would stop whatever the player is doing. Perhaps this could be solved with a ticking timer that begins ahead of an enemy attack (and you have to select/plan an option ahead of time, and if you're late your nation is considered unprepared for an attack by the enemy and you get negative modifiers)

I'm also unsure how involving other faction members, allies, etc would work. Should they be similar to Pokemon Double Battles where each nation gets to do something each turn, should it alternate (so nation 1 of faction goes first, then nation 2, 3 and so on and it loops around), should there be different "fronts" with different nations competing in them, etc. And how would I deal with the really large factions with 10+ members each (like NATO or Warsaw Pact)

Hey all,

the last weeks I have been working away at the Godot Object Compiler, a Unreal Header Tool-esque code generator for Godot GDExtensions.

It allows you to annotate classes and it's members and generates the necessary bindings to register properties, functions and signals to the Godot engine.

Internally it uses a tree-sitter parser and generates a simplified AST so the generators can query f.e. the field and parameter types and automatically create the correct variant type and property hints.

Here's an example how what that can look like:

#include "characters/chicken.generated.h"

GODOT_CLASS();
class Chicken : public CharacterBody3D {
	GODOT_GENERATED_BODY();

public:
	void _physics_process(double p_delta) override;

        GODOT_SIGNAL();
        void goc_goc(float p_volume);

	GODOT_FUNCTION(AnyPeer, CallRemote, Reliable);
	void jump_the_fence();

	GODOT_FUNCTION(ScriptVirtual);
	int pick_food(const Ref<Food>& food);

	GODOT_CATEGORY("Behaviour");
	GODOT_GROUP("Movement");

	GODOT_PROPERTY();
	float speed = 10.0f;

	GODOT_SUBGROUP("Jumping");

	GODOT_PROPERTY();
	float jump_height = 2.0f;

	GODOT_PROPERTY();
	Ref<Curve> jump_curve;

private:
	GODOT_PROPERTY();
	TypedArray<Food> food_in_belly;
};

GODOT_GENERATED_GLOBAL();

The available property hints, usages, variant types, base classes etc are also parsed from the linked godot-cpp headers so it won't break when something changes upstream (to an extent of course). I'm currently testing with the 4.5 branch.

It's still early days, but if you have same feedback I'd love to hear it :)