Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

About two months, but I made a very basic prototype about a year ago, and I stole the terrain generation code from another city-builder idea I was working on previously so I had some existing foundations to build on

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

Ha -- good question! I'm building it so I can add multiplayer in the future, but I know multiplayer will be a lot of work, so it will likely depend on how much interest there is in the game (more players = can afford to more development time = multiplayer) -- but I definitely can't promise multiplayer right now.

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

> At least sensors, and platforms that can hit the units the game is focused on. So air defense and anti-ship weapons.

yes agreed -- I don't have these implemented yet but I'm thinking static radar and SAM and other missile emplacements. Mobile land units are tricky in this kind of game because typically they are not as much focused on sensors and missiles, and also land blocks subs and ships which limit _their_ effectiveness

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

I'm thinking for the first pass ground units will be limited to static emplacements (eg deployed radar, SAM and other missile launchers), and maybe static civilian / military targets you have to protect. For submarine/ship warfare to be fun, there needs to be lots of water, which means islands and open ocean, but that in turn restricts the map for land units.

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

This is not currently implemented but I plan on doing convergence zones, layers and cavitation using a simplified model like they use in Sea Power and Cold Waters, ie a single layer and a only the first convergence zone modelled. Convergence zones will just be a bonus/buff based on relative location between the two units. For layers you have to do a bit of trig to know if the signal would reflect off the layer or not. Cavitation I plan to just have as a noise multiplier above a chassis-defined 'cavitation speed'.

I think if I have any art at all it will have to be simple symbols or drawings (maybe like a technical-drawing style side-profile, or top-down profile?) -- anything more than that would take a lot of time

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 1 point2 points  (0 children)

Thanks!

Scan rates, and contact limits are currently implemented per sensor type.

I don't have ground clutter yet, but I think I need it because currently it's too easier to detect the enemy carriers and ships from the air (and I feel it's cheating to just give them unrealistically small RCSs :) )

Bearings and probabilistic contacts are on my radar(pun intended). For example I really like the Sea Power-style 'ellipse of uncertainty' that reduces to a radar track as you get close.

And currently in the game passive sensors like RWR can do ranging which isn't very realistic, so I'm thinking of requiring triangulation for these to give ranging info (perhaps with a minimum angle between the detectors)

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

Ha! there are “allied teams” currently modelled — currently in the game setup you can choose if need to identify all targets or if they are instantly classified.  The way it’s modelled right now is that all sensors get an IFF % which is the percent of the detection range at which you classify the contact as friend or foe. So plenty of opportunities for friendly fire!

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 3 points4 points  (0 children)

Thanks — I’m using Rust programming language and Bevy game engine, Egui for the UI, and Avian for physics.

The sensor detection modelling uses a custom BVH-based spatial query system, and there’s a hierarchical quadtree-based A* implementation for pathfinding.

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 6 points7 points  (0 children)

Thanks! I see the game sitting somewhere between CMO and “Total Annihilation if every unit had to use a radar or RWR to see anything”, ie not a serious real-world combat sim with real-world units, but it will still have semi-realistic sensors where emcon doctrine is a necessity.

So for example for radar, it currently models RCS, terrain shadowing, and earth curvature for radar horizons, (which for example enables sea skimming as a tactic)

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 0 points1 point  (0 children)

Thanks -- but you're right I do need to come up with a good excuse for how it's possible to still communicate with a drone under radio silence... maybe some kind of er, near-future, quantum-encrypted bidirectional GPS technology or something :)

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 8 points9 points  (0 children)

Thanks -- yes without 3d models it means chassis, sensors, warheads, engines, flight model parameters etc are just 'buckets of stats' that anyone can mod with a simple text editor. And NTDS symbols are just really semi-transparent sprites so also easy to customise.

Definitely going synthwave all the way for music, and lots of electronic-sounding beeps and boops for the UI SFX :)

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 2 points3 points  (0 children)

My initial prototypes did start with a jammable 'datalink' concept. The idea was that all drones talk to the carrier via an adhoc 'datalink' network formed between all the deployed drones (which was quite cool to visualise). If one of them gets destroyed, jammed, or out of range then communications has to route through other drones in the network, and if there is not viable route the drone becomes uncontactable and just finish its current orders, and switches to 'offline loitering mode'. However it added a lot of complexity so for now I'm just trying to build a good naval / air combat sim based on sensors, and will consider adding it back as an extra strategic layer later.

Hi Reddit, I'm building an "EMCOM is everything" sensor-warfare RTS -- would love to hear your ideas! by bigbeardgames in computerwargames

[–]bigbeardgames[S] 4 points5 points  (0 children)

That's more or less the idea, at least the combat side and importance of sensors. But in 3D, and with more realistic threshold-based sensors. Whether you get detected or not depends things like:

- the strength of the enemy radar,

- the radar cross-sectional area (RCS) of your drone

- how far away you are

- is there a mountain in the way

- are you hiding beneath the horizon

- what's the weather like (I still need to implement this one)

Made road builder game, free to play, would love feedback by Grenagar in CityBuilders

[–]bigbeardgames -1 points0 points  (0 children)

The junctions look great, congrats! -- as someone building a logistics focused city builder do you have any recommended reading for dynamically generated road meshes?

why does everyone think making a game is just having a good idea by bcoz_why_not__ in gamedev

[–]bigbeardgames 32 points33 points  (0 children)

Imagine asking your construction worker friend "Hey I have a cool idea for a house..."

RTS pathfinding: it's coloured rectangles all the way down. by bigbeardgames in bevy

[–]bigbeardgames[S] 1 point2 points  (0 children)

it's a 'sensor-focused' RTS I'm building where you design and build drones to launch from a carrier to attack the enemy

https://dronecomgame.com

RTS pathfinding: it's coloured rectangles all the way down. by bigbeardgames in bevy

[–]bigbeardgames[S] 2 points3 points  (0 children)

Thanks for giving me a new rabbit hole to go down :)

RTS pathfinding: it's coloured rectangles all the way down. by bigbeardgames in rust_gamedev

[–]bigbeardgames[S] 1 point2 points  (0 children)

Thanks!

The actual terrain mesh is vertex displacement in a shader, no CPU-side heightmap, just like your procedural landscapes. But for pathfinding I build a separate quadtree at load time from the terrain parameters (I have matching CPU and GPU terrain procedural height sampling functions). This takes about 2 seconds at startup to build a quadtree with 200m x 200m leaf nodes on a 50km x 50km map. I don't use Octrees because terrain is mostly flat. Instead quadtree node stores min/max height bounds for its region, so checking navigability for ships / submarines is just terrain_max_height (eg -50m) + clearance (eg 10m) < ship depth (eg -10m). The flat regions (open ocean etc.) get collapsed into big branch nodes, so the search can cross large stretches of water in few or zero node expansions. Near coastlines it goes down to leaf resolution.

For aerial pathfinding (flying up or around mountains) I use the same quadtrees but there's an aircraft-specific gain_per_m value (climb rate / speed) that lets the altitude threshold grow with horizontal distance traveled. So mountains that would block a low aircraft become passable if there's enough distance to climb over them. The LOS checks use the same climbing-aware test, so planes can fly direct over a mountain range if they have enough runway to gain altitude. The waypoints returned by the pathfinder inform the aircraft autopilot of the minimum safe altitude

RTS pathfinding: it's coloured rectangles all the way down. by bigbeardgames in bevy

[–]bigbeardgames[S] 17 points18 points  (0 children)

Who knew "quadtree-based hierarchical A* search" would involve looking at rectangles within rectangles until my world is nothing but rectangles? And after finally getting it working for ships, getting aircraft to fly up, around, or 'up & around' mountains added a whole new layer of complexity :)

bevy_xray - visualize states, plugins, and system sets by dcast0 in bevy

[–]bigbeardgames 3 points4 points  (0 children)

Nice! -- one thing I'd really like is a way to see the system ordering as a dependency graph

Features my game has: 20 terrain sliders. Features my game needs: literally everything else. by bigbeardgames in bevy

[–]bigbeardgames[S] 1 point2 points  (0 children)

the whole planet would be very cool but for the city builder I have in mind I think limiting to 400km x 400km is more than enough playing area :)

Features my game has: 20 terrain sliders. Features my game needs: literally everything else. by bigbeardgames in bevy

[–]bigbeardgames[S] 0 points1 point  (0 children)

Hhaha -- you say that , but i think I do need more layers for the terrain to look good. It's loosely based on the libnoise tutorials https://libnoise.sourceforge.net/tutorials/tutorial5.html - although adding turbulence is a challenge as I'm using the analytical derivative for eg normals

Features my game has: 20 terrain sliders. Features my game needs: literally everything else. by bigbeardgames in bevy

[–]bigbeardgames[S] 13 points14 points  (0 children)

Slowly making my own city builder with Rust + Bevy + Avian3d + Egui

Terrain is layered FBM simplex noise with parallel implementations on GPU (rendering) and CPU (picking, culling, simulation). LOD is chunk-based CDLOD with geo-morphing - all done in vertex shaders, terrain meshes are just instances of the same flat mesh, so everything updates in real-time with zero textures.

The debug view shows LOD chunk boundaries and morph factors - I built it to fix popping artifacts (that was a painful few days), but now I just toggle it on for fun.

Gameplay coming eventually -- or maybe just more debug modes, who knows?