Timeline:
• 2019
  • 7 (1)
    • Machines - play one of the first 3D RTS ever
• 2018
  • 11 (2)
    • Embroiderino towards open source embroidery
    • Lightweight agile plotter
  • 10 (1)
    • Principles behind vibratory summersible water pump and repair tips
  • 8 (1)
    • Automated coil winder

Machines was first shown behind closed doors at ECTS 1997 (European Computer Trade Show) - I'm not sure how true that is. Beginnings of the development touch year 1996, game engine mutated couple of times to support latest graphics cards capabilities when they came out. At first it was intended to run under S3 ViRGE/VX and similar accelerators which were quite limited in offered performance. As an compiler and IDE Watcom 10.6 was used (known mostly as Doom I compiler) - its ISO standard compliance was quite away at that time which effects are noticeable as workarounds in code. Moreover you needed to get an STL and STDLIB for yourself separately, those were not included. Reading someone's code without a documentation, trying to extend it, are a good exercises on how to write code which is readable for others and modifiable nicely.

Yay, with some effort it was possible to find people who worked on the game, it is a bit more complicated with artist folks thought. The sad part is that minority of them do not care about the game too much and they are not interested in deeper discussion - huh, after spending years of work on project? What might be the reasons behind it, out of time, bad memories, ignorance, self importance? One of the developers was kind enough to write a cool description, it is just one point of view with all the standard perils of memory fading after many years:

I mainly did tactical-level AI. Which covered (let's think) group dispersion patterns in battle, construction droids, the scavenger, smelter transports, turrets, APCs...probably a bunch of other stuff I'm forgetting. Oh, and command stacking and unit autonomy levels. Plus I tuned a lot of the weapons.

We had to ship that game before it was really ready. There were a bunch of missing features. In particular the administrator droids did almost nothing, whereas it had been intended that you could put other units under their command and they'd be semi-autonomous, setting up turret emplacements with minefields and guarding them with sentries, things like that. But the project was already overrunning its schedule a little bit. We'd pivoted on the design halfway through development. Originally it was a much more slow-moving game, more like The Settlers with droids. You needed to expand your territory methodically using communications beacons, and there was more of an emphasis on building and less on blowing things up. But there was a general design shift towards being an action game, which was cemented when new graphics cards allowed for dynamic lighting and we suddenly realized that the game could look amazing (for the time) as a sort of interactive animated sci-fi movie with plasma bolts and explosions everywhere. And one of the things that was criminally under-used in the final game was the day-night cycle.

There was also a slightly hidden feature that your units gained experience the more you put them in combat, so if you kept repairing them and sending them back into battle their accuracy would increase. But because we didn't have time to surface that to the user properly, a lot of people thought that when units first went into battle they missed their targets because of bugs in the game. (It was actually deliberate dice-rolling inaccuracy that would decrease on second and third shots, but experienced units would hit their target first time.)

Oh, and if you put standard units in a group with administrators their combat accuracy and detection range improves.

One change I pushed for was to make the ion cannon a disruptor weapon, i.e. one that stunned units for a period of time rather than damaging them. I thought it would have made for more tactically interesting gameplay, as you’d have to co-ordinate an ion attack with a follow-up strike, with a platoon of nearby units or an APC strike team or whatever. And it would have differentiated the ion cannon from the nukes. As things stood they ended up feeling like variants of the same weapon.

I think it was the last project I worked on that *didn't* use Visual Studio. And the compile times were so huge (around 8 hours for a full rebuild) that we had scripts to artificially change the timestamps of header files to stop automatic recompiles in cases where no object sizes had changed. Plus all file merges were done by hand, every time. Seems ancient now.

One thing we did have that was really cool was a development system that recorded all user input and all random number seeds into a linear log such that accurate playback of a session was 100% guaranteed. This meant if you were playtesting the game and hit a bug, you could restart in playback mode and the game would reproduce all your actions and run in a deterministic manner until the exact same bug was hit. Very useful when finalizing the game. Probably much harder these days with more fundamentally multi-threaded systems.

One other undocumented feature was the missile turret committing noble suicide. If it was being beaten up at close range by an enemy unit, was close to death and no collateral damage was likely, it would shoot at its own feet in the hope of taking out the nearby enemy.
There was also the unforeseen bug not picked up in testing of a first person unit becoming invulnerable when it was halfway in, halfway out of a building. I think this was because building interiors weren't part of the same 3D space so you effectively teleported inside them like they were the TARDIS or something. And this meant you could park a grunt unit halfway inside an opponent's pod and take it down from the inside without the opponent being able to do anything about it.

Pathfinding, some flavour of A*, and I think it used a set of portal points on the edges of grid squares that could be blocked dynamically by buildings. I have a feeling that it was reasonable at the macro but not terribly good at the micro, that it didn't do short journeys avoiding other units very well.
And to be honest there wasn't any proper generic strategic-level AI. Most of the single player mission AI was scripted. Outside of that I think the AI just formed pre-canned skirmish squads that it sent out, combined with some basic rules for finding and exploiting BMUs. It would have benefited from having the ability to form an assessment of the military power needed to overrun a particular zone on the map then building an appropriately-sized task force.

Get some unique and rare screens/renders of early builds bellow. Thanks to Hallfiry for digging them out.