The Road to Playtesting

The game has come an extraordinarily long way since work started in February.

When I started the point of the project, was to get a deliverable product, something with a scope I felt I could accomplish, so that I could get a finished title under my belt after years of playing around as a hobbiest. The core list of things I put to paper then, has shifted around the edges; but, generally keeping the aforementioned goal in mind has lead to a rather tightly maintained scope. That has paid off, since it's meant I haven't really had to do a lot of repeat work. Models I made in March are still the final drafts I have right now. Systems I propped up on day 1, are still being utilized the equivalent of 57 work days into the process (I track my time, and every 8 hours I consider 1 day of work, given I work on this part time). I feel more confident day by day, that this will pan out into a game, something I've never been able to say about my prior projects.

That said, on to the update:

Vision

The vision system is fully implemented. Right now, the game creates distinct entities that act as data storage blocks in the world. Each block retaining a record of what eyes have been on it in terms of Active Radar, Passive Radar, and/or Vision. Manned vehicles or pilots spread vision, which reveals any and all entities in those now spotted blocks to that team.

The current work, is to improve the spawning script for our data holder blocks, such that they don't spawn where terrain is placed, and so that shadowcasting can properly project the vision cone of units and active radar's area of influence in a way that considers terrain. Passive radar will conversely allow you to see outside of LOS, but will come with some limits: It can be fooled and it will not give you a distinct radar signature to lock on to and fire. Instead you will simply have to attack ground near those targets and hope for the best.

This work has also pushed me to start considering VFX and a greater emphasis on visuals. It's intended that you can view where your radar ranges are in a radar view. This radar view will also provide you a simplified but total view of the battlefield, where you can order units around. Likewise, while it's obviously where you have vision in terms of there physically being things in the game world, it'd be nice to see on a radar view a delineated area of where you have vision, where you have active radar coverage, and where you have passive radar coverage.

Hubs

Adjacency allows buildings to transport goods between them. Specific tasks, materials, power, etc. are distributed freely over the network, with a hub entity connecting them. This hub entity serves as the distributor, making sure goods are transferred on orders that wont overlap or repeat. This means that when a building asks for power from the network, it can be pulled equally from each powerplant and given back to the individual buildings one at a time. The next step of this, is the creation of longer form workorders. These orders would be distributed to the hub, who will then decide what buildings should get what piece of the longer order.

This has basically worked, for a few months now. The thing is, that in testing I have found that there have been issues with items being distributed to power plants or other buildings, causing more material to be pulled than is available from a building. So the intermediate manager entity will need to be used to fix that.

Likewise, there is not at this moment, any recipe manager that holds the recipes for vehicles or equipment. Since work is diffused out amongst many buildings when an order is created, the aforementioned intermediate block manager will be what distributes work out when an order is created. All of this working, should allow the next step of development, which will be base building and combat balancing to be started.

Pilots

As mentioned in the section on Vision, pilots are going to be an important part of the game. In most RTS games you have Infantry, Vehicles, ships, etc. that draw from a population supply that you have. Wildcat will handle this differently. On the frontier of human civilization, people are hard to come by. There are cities and settlements, but unlike Earth and some colonies with populations in the billions, Sectare 121 can count maybe 500,000 people across it's entirety. So every person you can get to work for you is important, and each of them will be physicalized in the game world.

Above: Pilot model, in the test map.

They will hold equipment, drive the vehicles, man the buildings, and are effectively your eyes. Changing vehicles will give them a different set of abilities, based on the equipment in that vehicle. Though, they can also equip any number of weapons themselves; and, act independent of vehicles as infantry. This is to allow the player a greater degree of control in the world, as certain actions can only be performed by an unmounted pilot, like securing or interacting with unoccupied structures or unpowered vehicles. Pilot entities are also extremely hard to spot, allowing them to act as great scouts and agents out on the map.

Right now, pilots are at least partially implemented. They are are rendered in engine as seen above. They also have the ability to mount and dismount from vehicles in a way that the vehicle will recognize. The next goals, are to get their equipment handled so that models change based on what they get their hands on, get pilot stats implemented so that different pilots effect the vehicles they are inside of, and to implement the screens and systems to allow for the recruitment of pilots during a match.

Models

Something that's been important to me, was defining a style for the game. The ships in Wildcat are based on ships I used to sketch when I was a child, in the margins of notebooks. There'd be swarms of fighters, spacecraft, and bases on asteroids where factions would fight in large pitch battles. I'd even make entire dictionaries of what each ship, base type, and fighter was called.

Going from those sketches though, to in game model has taken a few iterations on the workflow. All of the models are built and concepted in MagicaVoxel, but Magicavoxel is kind of terrible at a few things, like non-right angles, round edges, and most importantly UV Mapping.

Above: An image of me finding out the quality of MagicaVoxel UV mapping. What you see is a diffuse layer being stretched in parallel, nanometer thin strings, that melts the image down to an indistinct smear.

So, once models were completed in magicavoxel, such that I liked their design, I take them into Blender. There, I add some angled faces, round some edges, edit some features, simplify the tri-count, and remap all of the UVs. The few humanoid models have also been rigged in Blender to allow for animations. With a .PNG of the UV map generated from blender I can start on texturing.

Above: A revised model of the Light Combat Vehicle, after blender edits adding angular faces and simplifying the tri-count.

Texturing will likely get brought into an Atlas eventually, but for now individual textures are being made for each model. This is done utilizing AESprite, in order to capture a pixel art texture to match the blocky voxel models. Ultimately, I've been pleased so far with the results after everything is brought into Unity. There is still work to be done, since with time the individual textures will be swapped over to a Texture Atlas so that normal mapping can be done more easily at a unified resolution; but, that is more of an optimization step. For now I just want to get models in game to make sure I'm generally happy with their style.

Above: The final Light Combat vehicle, after import and texturing in Unity.

This workflow is a bit heavy and I had considered BlockBench as an alternative since it has the UV map right there. It might become an alternative longer term, but right now, the current workflow best fits my brain.

Next:

The next steps are a march towards playtesting. Once the block manager mentioned above is completed, work orders will need to be scripted so that vehicles can be constructed. Vehicles being something you can build in game, should then mean it will be time to make damage systems to empower combat between these constructed vehicles. At this point, the game will be playable.

There are a lot of features I think adding will come down to how much time it takes and how complicated it will be to do. For example, in the final product I'm hoping that drones will build and harvest from bases placed around the map. These drones being a unit that accepts orders from it's nest entity, that they then go out and perform. Making that work would add a lot of visual flare to the Mobile refinery and the Mining facility building. That said, for the sake of making a working game, I can easily just add timers to the buildings and playtest while I develop the AI for the drones.

Likewise, I have direct and indirect munitions planned for the game. Direct fire works, that's how the targeting was set up from go. Indirect will be very important, but doing so is no small feat. I think this is much more likely to be added as a feature than a more holistic system for drone AI.

Any way I cut it though, the most critical step I need to get to is playtesting. A lot of the work done, has been based on assumptions that I need to run by other people. Once we're there, I'll have much needed context on where to go next.

Thank you for reading, and if there isn't another update before the year's end: Have a Happy Holidays!