next »

[FlightFight]

Introduction

Hey everyone,
I'm working on a game called Assembly RTS - Unleash Your Forces - An immersive, physics-based strategy game (with faction customization to come).

I'm building the project with Unity and its Entity Component System.

I've started building it more than half a year ago and I'm still working on some of the technical foundations.
High-performance determinism with lock-step networking, basic unit interaction, high-performance hovercraft physics, map editor with Steam Workshop integration, simple matchmaking with map voting and pretty UI are in a good state already (among other things). I've started working on A* pathfinding and will work on local avoidance soon afterward.

Up until this point, I've also created a dozen or so high-fidelity low-poly 3D models for hovercraft and tried my hand at a mech with animations to spice things up. However, I'm putting 3D art on hold for now.

Until recently, I've been regularly posting devlogs on YouTube in case you are interested: youtube.com/@seannowotny

I'll try to post higher quality devlogs on YouTube from now on, about once a month I imagine, but I'll keep up my weekly schedule for written devlogs.
So far I've posted my written devlogs on IndieDB only, but TigSource seems like a nice place as well, and a lot more active with game developers like myself!

The rest of this devlog is gonna be similar to the one I already posted on IndieDB today.  

________________________________________________________________________

One of the main challenges of building an RTS game are the technical hurdles.
Specifically, high performance regardless of the circumstances is super important. Gone are the days when an RTS game locked at 30 FPS was acceptable (looking at you, C&C series). This is why, even though the gameplay logic of Assembly RTS is updated roughly 30 times a second, just like the classics, everything needs to be running smoothly, preferably at 100+ FPS on inexpensive systems.

This is just one of the many aspects I've been working on for the past three weeks. Interpolation and extrapolation of positions and rotations now make everything look smooth regardless of other factors.

Stability Improvements

The past three weeks I thoroughly tested all of the current features of my game and squashed many a bug along the way. Steam Workshop integration edge cases are no longer an issue. I also fixed map editor data corruption and made the editor work out of the box, without requiring the player to take extra steps.

I also wrote some unit tests, play mode tests, and performance tests to see if they would benefit the robustness of my project. I had to conclude that they aren't worth the effort in most cases. Yet the play mode tests I wrote to check if scenes run at all, are actually useful. I had hoped that ChatGPT could help me with writing unit tests, but the AI made a lot of mistakes.

I'm reconsidering adding continuous integration to my development workflow once again. This would allow me to focus more on working on developing Assembly RTS without having to manually build and deploy it to Steam for testing purposes. I used to have a CI pipeline, but it was always fraught with problems...
Now that I'm forced to use Mono instead of IL2CPP for my builds (because of ECS 1.0 limitations) I'm planning to give GameCI a go at some point.

I encountered a Unity bug that completely corrupted the project when changing Assembly Definition files. This brought about a series of events that lead me to test various Unity versions and library configurations until I found a combination that actually worked properly.

During the long loading times, I learned a bit of Bevy on the side. It's a neat, ECS-based game engine that I'm keeping on my radar for the future...

Other New Features

I've also started implementing the automatic generation and serialization/deserialization of a terrain collider for the hover vehicles to collide with.

It's even possible to play by yourself now, without an internet connection.
(An AI opponent is something I'm delegating to my future self. Online multiplayer is of more immediate importance.)

And most importantly, as I've already mentioned, I started implementing A* pathfinding, so that units can avoid obstacles and find the shortest path to a target.

Thank you for reading

[FlightFight]

Assembly RTS Devlog - Blessing of CAD

Hey guys, last week I continued working on fast pathfinding.

In connection with this, I also started implementing a simple way to automatically rasterize obstacles such as buildings to the navigation grid - So map creators won't have to do extra work after placing structures in a level. I also took steps to ensure the determinism of the navigation system following rigorous testing.

Looking for a better Level Editor Solution

Unfortunately, after encountering new serious problems with the real-time map editor, for what I feel like the hundredth time, I‘m afraid the map editor is simply too unstable and unreliable to keep.

From the start, I‘ve kept encountering issues with this asset (despite the positive reviews).
Dealing with random data corruptions and finding new bugs is costing me too much time.

I see myself forced to look for a different solution.
(Coding my own map editor from scratch would be way too time intensive)

First I‘ll have a look at this open-source solution, early in development. (I may combine it with a terrain editing library)

I'll also consider this other feature-packed asset to build upon. It has the reputation of being very robust and extendable. The UI is a bit old-fashioned but that is something I could later improve.

New Design Ideas and Plasticity 3D

On a positive note, I had a new idea for hovercraft designs featuring more organic shapes with brushed chrome surfaces and rounded canopies. A bit like the Aeon in Supreme Commander I suppose.

Aeon Obsidian Tank from Supreme Commander:

I first tried my luck in Blender but became frustrated by topology complications.
This is one aspect of 3D modeling I've always strongly disliked- Having to deal with broken topology.
Destructive editing tends to be prevalent at every corner of the creation process. Experimentation is punished by the topology gods.

So I took another look at CAD software. Computer-Aided Design software utilizes Nurbs surfaces and volumes instead of polygons. This has some distinct advantages over polygonal software like Blender.

I tried all kinds of different programs. To my surprise, after some tinkering, Plasticity looks like the most promising program for the job. It's still in beta and lacks non-destructive boolean operations, but making edits to the Nurbs-based geometry is incredibly flexible in this program.

I'm really excited! I'll create my new design in Plasticity next Wednesday.

Maybe this new concept could form the basis
of the design philosophy of the Legions of Tesem (the bad guys).
The more rectangular, practical dogma could remain with the Order of Pisces (the good guys).

Thank you for reading

[FlightFight]

Hi, and welcome back to another devlog for Assembly RTS!

Hovercraft with new "Grav Plates" (Material ID Colors):

This week, I completely reworked the map editor by transitioning from my previous headache-inducing level editor system (RTE) to a far superior open-source-based solution (ALE).

By superior I don't mean more feature-rich. On the contrary - ALE has fewer features than RTE, but far more importantly it doesn't have any serious bugs!

In addition to a dozen of big advantages from a developer sanity perspective, this new solution even makes it possible to save a level to a much smaller file.

A level used to contain more than 100MB of data.
Now a level contains less than 10MB, thanks to less bloat and MessagePack compression.

Thanks to this, I can now store them on the Steam Cloud.
The Steam Cloud has up to 95MB of storage available for Assembly RTS (for every user).

So whenever you reinstall the game and forgot to make a backup,
or switch to a different computer altogether- Don't worry, your levels will be still there, waiting for you.

But keep in mind, that I've not yet completed the transition to the ALE editor, so the file sizes will probably get a bit bigger in the future.

Either way, I think having up to 7+ levels on the cloud should be sufficient for most creative people.
At some point, I should think of a solution to save and load levels from a custom location on disk, or from the Steam Workshop - Cloud storage overuse shouldn't be as much of a concern.

ALE is Open Source

I'm usually not a contributor to open-source software but I made an exception for ALE, because I think it has a lot of potential. It would have been a waste to not contribute my improvements to it.

In my opinion, the code for ALE is far more well-written than the paid assets I've come across.
However, it was a bit outdated, written for Unity 2020. The package uses some IL-weaving magic which I don't yet fully understand, but still, I managed to fix an IL-weaving problem, and now it's nearly fully compatible with Unity 2022. My "PR" was merged and the most recent version of ALE now includes this fix.

I wish ALE would become more popular. It's a really solid foundation with a lot of features already present. Regrettably, the author Herzole and I have been the only contributors to the project so far.
I would love to see more people get involved in the development of ALE!

3D Art is taking too much time!

This week, I didn't create the chrome hovercraft design I was talking about in my previous article, because when I started working in Plasticity, I noticed that live mirror functionality (mirror modifier) isn't a thing (planned for Plasticity 2.x by the developer).
So instead I opted to create some "Grav Plates" which were on my checklist.

I've been getting more and more doubtful of my current 3D art pipeline as you may have already guessed from my last devlog.
I have a nagging feeling that I'll have to rework a lot of my assets at a later time, potentially making my current time-intensive efforts in vain. I don't think that this concern is misdirected. Still, I ventured on, to create a Grav Plate, to be used by the hovercraft as per the usual pipeline.

Gravplate in 3D Coat:

In Substance Painter:

This plate will later be attached to four ends of each hovercraft and will be 'responsible' for their propulsion as shown in the image at the beginning of this devlog.
I plan to later animate these Grav Plates. They will rotate in different directions as the vehicle moves around. It will make all units look a lot more alive!

Continuing the search...

I've always played with the idea of giving Surforge, a streamlined texturing program integrated into Unity, a try. It could potentially skyrocket my productivity - Baking and texturing take up a large portion of my workflow's time schedule. This week I started giving this solution much more consideration.

3D model textured with Surforge (source):

I also think Surforge could be conducive to keeping a consistent style with less complexity getting in the way. Complementarily to this, UModeler makes it possible to create low-poly assets within Unity skipping the entire importing and exporting process.

Combined, these tools could potentially double or triple my productivity when creating 3D assets. Apparently, UModeler even features Sketchup-like push-pull modeling! However, the price of these assets is relatively high...

Push-Pull feature of UModeler:

There is a free version of UModeler that I'm going to try out next week. The same can't be said for Surforge, and Surforge has some caveats that have me scratching my head. I'll have to give it all a bit more thought.
Coincidentally,
the screenshot I made for the beginning of this devlog gave me a new 3D asset workflow idea

Stay tuned for the next devlog, when I will give this new approach a go.
You can also follow me on YouTube where I will be posting an animated Devlog soon™
Thanks for reading!