Making a game that mixes Auto Battler and RTS
▲ 4 r/AutoBattler+1 crossposts

Making a game that mixes Auto Battler and RTS

Right now it only has a working title — Autobattler. I haven't come up with anything better yet.

It's a fantasy setting that combines elements of RTS and Auto Battler genres. The core idea is simple: over the course of a match, players build up their base. The base produces an army. The army automatically marches out to tear down the enemy base, fighting the opposing army along the way. Destroying enemy units and buildings earns you currency, which you spend on new buildings. Whoever destroys the enemy castle first wins.

You don't control your units directly. That strips out the micro but keeps the pace of an RTS: you're thinking about strategy, not tactics. The challenge isn't firing off a unit's ability at the right moment or pulling wounded units out of a fight - it's figuring out how to adapt your army composition to your opponent's.

Heroes are special units. They're named, unique units that level up over the course of a match and grow stronger than regular units. A hero that dies isn't gone for good - they respawn. Each hero type is limited to one instance per player per match.

Players also get global abilities that can be used anywhere on the map. A well-timed ability can flip even a hopeless situation in your favour.

What's done

The core gameplay loop is in, along with a handful of buildings and units.

There are a couple videos of the actual gameplay:

What's next

The next milestone is releasing the game as a free "early access" build on itch.io, with a basic set of mechanics and a 1v1 PvP mode. That's my way of testing whether players are actually interested in the project.

Heroes, unit abilities and global abilities won't be in by the time it hits itch.io, but I'll be adding them gradually.

There's only one race in the game right now - humans. I'd like to add others for variety, but I don't have the resources for that yet.

I'm also working on deepening the economy: adding one or two new resource types and the buildings that produce them.

This is the first post about the project. I'll keep writing as I have things worth sharing.

youtu.be
u/MaxKarabin — 11 days ago

Passing data between GameState instances during seamless travel — what's the right pattern?

I'm making a MOBA game as education project. Basically, this is a dedicated server setup, but I want to support host setups as well.

I need to pass some data from Lobby (LobbyGameState) to the actual game (CombatGameState) on seamless travel. For PlayerState this is straightforward - I've overridden the CopyProperties method. But GameState doesn't have equivalent.

I've looked at the common solutions in the internet and I'm not quite satisfied with any of it:

  1. Store the data in GameInstance/GameInstanceSubsystem. It seems like antipattern as GameInstance has a completely difference lifetime. The passing data should live maximum during travel (or even less), but GameInstance lives while application lives.
  2. Save the data to disk (Json, Database, etc.). I don't see why I'd pay the I/O cost for data that only needs to live during transition. In fact, the data lifetime is even bigger than GameInstance's one.
  3. Pass the data inside the travel URL. I found that solution as the most promising. The URL survives server travel, I can access it in GameMode::InitGame. But it's still it's not quite obvious how to encode and fetch collections from there.
  4. Also Gemini advised to inherit the AWorldSettings class and override SeamlessTravelTo method. But fast documentation research revealed that this method does not exist.

None of these feel like the right answer. Is there a cleaner pattern I'm missing?
I would appreciate any thoughts on this.

reddit.com
u/MaxKarabin — 2 months ago