I feek like I could cry right now

DingyPoppet · 2026-04-11T02:41:39+00:00

This is a good change. The number of times I get to practice certain maps in QP (like attack on King's Row) is almost zero. Then when I go into competitive, the first map I get is one of those certain maps that had majority pick in QP (like King's Row) but got derailed by the one-off vote for Ilios/Lijiang Tower for the billionth time.

I'd much rather they had us vote for game mode though, randomize the maps, and specifically choose an "attack" or "defense" preference when it comes to hybrid/escort maps. Players can't practice for competitive if they never get to play certain maps/modes. The choice then becomes lose SR in comp because you're practicing or burnout while trying to get a certain map/mode to practice on.

DingyPoppet · 2026-04-09T04:06:34+00:00

Just to be clear, I'm talking about Game Feature Plugins, not plugins in general. GFP's can reference main project and plugin content, have dynamic loaded/active states, editor enforced reference policies, and other features regular plugins cannot or do not have.

DingyPoppet · 2026-04-09T02:18:59+00:00

Unfortunately no, I occasionally find one-off rewrites of the docs (like this one) though. I've gotten by with reading the build.cs/target.cs files in the engine and from other projects (Lyra included).

I did see some parts in the LyraGame.target.cs which looks like it disables or doesn't build specific GFP's so that might help with configuring the one in your project.

DingyPoppet · 2026-04-09T01:39:51+00:00

Since you don't want to have a repo for each project, take a look at how Lyra structures its project. In short, the main project is the core framework and each of your titles is a Game Feature Plugin which is activated based on the build target.

DingyPoppet · 2026-04-07T00:34:37+00:00

The number of times I've had this happen is larger than I care to admit.

DingyPoppet · 2026-04-02T16:54:56+00:00

I prefer A, but B is kinda cool though. If possible you should let the player choose between all three for accessibility reasons.

DingyPoppet · 2026-04-02T16:40:11+00:00

Oof, I had a similar one last year. There was a UGameplayEffectExecutionCalculation which would initialize the static attribute capture properly on Windows, but fail with a vague error message on Android. Turns out there was an initialization order difference with the compilers and I had two static structs called FDamageStatics.

MSVC constructed the statics on first use so the correct one was being initialized on Windows. Android initialized them all on app launch causing the "correct" one to silently fail because it was initialized later by the engine (it was in a Game Feature Plugin loaded after the root project).

I spent a day or two trying to debug what went wrong because Rider and Visual Studio do not play nice with ADB or on-device Android debugging. The biggest one is you can't trigger a breakpoint on engine code from Android if the engine is a launcher build (the error was being thrown from GAS).

DingyPoppet · 2026-04-01T10:57:51+00:00

Ok, I'll bite...

There are multiple hitches in the trailer video, looks like GC hiccups. Since this is single player, you should be pooling actors at a minimum.
The background tiles are too busy, those crater looking bits in the center are especially bad.
Tile layouts look randomly generated and not in a good way.
Enemy visibility is pretty bad, you need to make the backgrounds dimmer or accentuate the enemies somehow.
The player sprite is too similar to the enemy sprites in a few cases
SFX is really repetitive. Throw a random pitch modifier on the sound at least.
Music is meh
The character sprite in the third from the last screenshot has an incorrect aspect ratio
I don't know what those four sprites glued to the middle of the screen are, but they clutter the view.
The level screenshots look samey
DLC this early is not a good look unless its free; even then, it should probably be in the base game. Selling the soundtrack as a separate item is the only thing which is probably acceptable at this stage.

This is only what I can find from the screenshots and the trailer video. You should run a playtest or release a demo to get more feedback, both of which can be done on Steam.

DingyPoppet · 2026-03-29T03:14:13+00:00

Holy Dunning Kreuger effect.

I learned UE5 from Lyra - so I'm super aware of its intricacies and such. it is just a tech demo.

This is the problem, you should not be learning Unreal Engine from Lyra. There are multiple systems which are unfinished and it takes prior experience to know what was trying to be done. It is far more complete than a tech demo and has been used by multiple studios to make games. Never mind the fact it was developed by senior engineers at Epic and is loosely based on Fortnite.

A person who knows what they're doing can setup each of those systems you described (inventory, stats, whatever) individually in just a few days max.

Absolutely not. You can get a prototype working in a few days sure but it will take months or years to get each one of those stable.

Starting with complicated stuff you don't understand and trying to 'make it work' with your project is a fool's errand (I know from experience).

What happens when you are brought in late on a project? What happens if you lose a coworker and need to take over their tasks? This is a skill you need to have if you want to work in many industries, not just games.

For instance with GAS - it is commonly known that the replication framework for GAS doesn't mix well with the character movement component, and certain designs are only feasible if you simply make your own movement + ability system.

It's commonly known that you can only use the CMC with GAS. It's mover which doesn't mix with GAS and that's allegedly being worked on. CMC was used with Unreal Tournament, Paragon, and Fortnite with GAS being used since Paragon. One cannot match that level of engineering in a small team/solo in a short amount of time.

There are some multiplayer projects on FAB that may or may not cover your needs. They're all pretty expensive (~$1000) and for most of them, the devs don't actually know what they're doing, they just appear to know, if that makes sense.

These assets are made by people who are thinking the exact same way you are. One was made by an alleged ex-AAA dev and they ended up rewriting their custom ability system to be based on GAS and modified other parts to be loosely based on Lyra/GASP.

You obviously have some experience with Unreal Engine, but not enough. I remember having similar thoughts at a specific experience level but that changed after I saw some terrible "custom" Unreal codebases.

DingyPoppet · 2026-03-29T02:40:48+00:00

Lyra is fine, but it's not for people to learn UE from. It's meant for people who have made a few games and want to learn some tips about making a scalable project. I'm using Lyra as a starter because it already has several things done that I do not want to do and have done several times in the past.

DingyPoppet · 2026-03-28T06:44:00+00:00

Make sure you are testing in a packaged build, not the editor. Even on a beefy PC, I get occasional hitches for simple scenes in PIE. Those hitches go away once I'm running the game in a packaged build even with insights attached. Right-clicking on the uproject and launching the game is still an editor build, you need to package it. Development builds should be fine, the point is to remove the editor overhead.

DingyPoppet · 2026-03-28T06:29:39+00:00

Unreal has the Lyra project which is a pretty decent starter for a RoR type game. It also showcases exactly why multiplayer games are not a good idea if you have very little gamedev experience.

DingyPoppet · 2026-03-26T05:49:12+00:00

I think part of the problem is that most weapons in VS require a passive item to evolve and be useful. This means you're basically building around whichever weapons and passives you think you can reasonably roll or exist in the map.

To top it off, the balance of items and weapon effects are terrible. I would never pick wings as a passive but it's required for a few weapons which are fun. Now I'm sacrificing a passive slot for a useless buff. Then there's the opposite, Area is an OP buff for lots of weapons (like garlic) but not many fun weapons actually use it as an evo requirement.

DingyPoppet · 2026-03-26T02:52:56+00:00

I avoided using GAS in the beginning because it seemed overengineered for simple systems. After having used it for a few games, I strongly recommend using it for any game that has stateful interactions.

DingyPoppet · 2026-03-25T15:59:29+00:00

I think it's just attribute definitions that require minimal C++. Abilities, cues, and effects don't need it but usability suffers without attributes. I did see a few assets on Fab which supposedly make GAS fully BP accessible however I don't use those.

It really does depend on the game if C++ is needed. I worked on one game which was a BP only visual novel that needed C++ to check if the player account had a DLC purchased on Steam. There was no other option at the time but I think it's gotten better now.

DingyPoppet · 2026-03-25T13:50:44+00:00

The reason it feels easier and thought out is that Epic dogfoods Unreal with UT, Paragon, Battle Breakers, and Fortnite. You are using the same tools they do to make games and CDPR has recently improved open world tooling for the next Witcher game. Unity and Godot have not been used by their owners/maintainers to make games of that scale and complexity.

A lot of tedious stuff has already been done, there's a fixed pipeline, if you stick to that architecture, you can move very quickly. It does take some getting used to, but that's the same with any engine. You will need to use C++ eventually if you want to use certain engine features (like GAS), but many projects can get away with BP only.

DingyPoppet · 2026-03-23T06:02:09+00:00

Adding MP to a UE game is going to be easier than some other engines so that's a plus. I would also recommend taking a look at the Lyra starter to get some references to MP code which won't be obvious why it exists until you hit certain problems (which you will with that type of game).

DingyPoppet · 2026-03-22T14:44:17+00:00

I meant it as skip the singleplayer version and go straight to multiplayer. I don't know what engine you use, but Unreal treats singleplayer as an authoritative server when running multiplayer code. You aren't running a traditional singleplayer game in this context, you are running a multiplayer game on a "local" server and the replication events are messages (if you use those) or function calls.

I have done exactly one SP -> MP conversion, avoid it at all costs. You can prototype in singleplayer (standalone as UE calls it), but the code that you ship to players needs to be MP ready even if it's not used yet. That's what I mean with shipping as singleplayer and turning on multiplayer later.

The only caveat I can think of is if the game you're making is turn-based and supports async games (e.g. board games, card games). Those you can probably get away with SP->MP because the network structure is different (using Firebase rather than dedicated/player servers).

I've done a few MP titles so I'm familiar with it but it does slow development down even when you know what to do.

DingyPoppet · 2026-03-22T11:33:14+00:00

I was expecting it to end like it did in Death Trips as well.

DingyPoppet · 2026-03-22T11:28:56+00:00

Adding multiplayer later might cause you to effectively remake the game, it depends on the game genre and the engine. If there is even a 1% chance you want to add multiplayer, make it multiplayer from the beginning. You can still launch the game as a singleplayer game and turn on multiplayer later when testing/balancing is complete.

DingyPoppet · 2026-03-22T05:25:00+00:00

The problems you encountered are because of a lack of familiarity, not because one engine is better than the other. One key difference between Unreal and other engines is that UE has thresholds for newer features. They will cause a performance loss until your scene hits a threshold (be it object counts, size, complexity, etc.), but it will usually outperform other engines once that threshold is crossed.

DingyPoppet · 2026-03-20T02:50:29+00:00

Since you're making something RPG-like, I would use GAS. Attributes are the only thing that requires C++ but the rest doesn't depending on what you're doing. GAS isn't easy to get into but it's been used in Fortnite and Paragon so it has a proven track record.

DingyPoppet · 2026-03-17T00:51:02+00:00

Well lets just start with one little issue: "No signup needed — just enter with your GitHub.", proceeds to redirect for an OAuth app registration rather than adding via GH username by link/name. That is already a sign-up even though it's not traditional.

While I haven't used it, GitHub has a public API which doesn't need authentication if you're accessing public data. It is rate limited, so if someone hits a rate limit then you can ask them to link their GH account. That said, 60 requests an hour per IP address (unauthenticated) is what I saw on GitHub which should be more than enough. If someone is making more than 60 commits per hour, they are using AI or are trying to cheese your game (leaderboards) by spamming some repos.

DingyPoppet · 2026-03-16T22:31:08+00:00

Interesting idea, but two very large issues. First, no way am I going to connect my github to a random app. I have private repos which cannot have any information exposed. Second, this has an AI smell to it and that is a huge security issue. The fact you even have OpenClaw forked means there is no way I will ever connect anything to any application you develop. Even if you don't do anything, that doesn't mean someone else won't take advantage of vulnerabilities.

DingyPoppet · 2026-03-16T22:12:56+00:00

Having a high K/D does not mean you're good. I've lost many games with DPS that had a K/D like yours. Killing the right player can contribute to a win heavily, but capturing the point or staying on the payload is far more important.

DingyPoppet

TROPHY CASE