Let's start from the beginning
Prototyping a game for me is very much like watering a seed. With this game, I started by thinking about an interaction that worked with both “standard” VR controllers and hand tracking, that also was fun and engaging. After playing around with my hand in the air for a while, I realized the act of grabbing something that is attached to your pinched fingers with a virtual spring felt like a really fun fiddling toy.
v0.0.1: After making the first prototype with a simple sphere as a hand, connected to a small drone with a physics spring in Unity, I tried to connect that drone to a cube with another spring. That felt really natural and fun and created a feeling of weight depending on the mass of the cube. This cube was now a package, thus delivering with drones as a concept was born.
Now I just needed a game. How hard can that be? Well. Very hard. This project went back and forth. Starting out with a simple puzzle game where you should deliver the package with your drone from Point A to Point B without colliding with anything. This gave me the idea of training an AI drone system to find the best path around the world. That gave birth to the recording system (By this point, the name of the game was Drone Delivery, more on that later).
Silence, recording in progress!
To create something that works against you in the game, I added the worst enemy; yourself. By recording the position of the drone during a set time, and then saving it to a timeline, I could then replay one drone path after the other, until I had a cluster of drones in the air flying all over the place. So you had to be careful so you didn't collide with a past recording. If that happened, or you collided with another structure (and that happened all the time), your drone would die, disconnect from your hand and start falling down (Later on I changed this so it only disconnected from your hand, as it was more annoying than fun).
The key to keeping all these drones synchronized is both to have a central timeline that you store the recordings' start positions in, and to make sure a single recording is shorter than the length of the timeline. To visualize this I gave the drone a battery. So when the length of the maximum recording was soon done, the drone would indicate that it was out of battery and you better find a landing/charging spot fast!
This recording system made me think of factories and other automated systems. So to spice it up a bit, I started to build a small automated factory game. You know, nothing big. Only like Factorio or Satisfactory, but in XR.
Loop One: Done is born
It took about 3 more years before I had a testable version of this automated factory game. In 2024, I renamed the game "Loop One: Done". It felt more in brand with what the entire game had transformed into. By now I had moved from VR to MR (Mixed Reality), built mines and other facilities that could extract iron ore, water, and plastic. Smelters that could convert them to iron blooms and stems. Factories that could take raw materials and produce refined products like steel plates and drones. I had built a save-system, UI menus, a procedural resource placement system (that spawns different resources around your room), a tutorial and quest system, a bunch of debug tools and updated all graphics.
I also bought a domain and built a first version of the site, LoopOneDone.com, creating a mailing list, and started marketing the game on social media like Threads, YouTube and TikTok.
Testing, testing, testing
v0.5.1: Now I was ready to make some first real play tests. Before I had only tried on family and friends. So on 20-21 Sept 2024, I showcased the game for the first time to the public at a small newly started gaming event in Gothenburg, Sweden called GGX. The first day was a hot mess. I stood in front of a window pointing down in a paddle hall, so the tracking went all bonkers. But it was easily solved by cover it with papers. But the few visitors that forced their way into the sweaty cave of our indie-room seemed to like the game a lot. The next day I moved out to a bar, where the air was much better and there were no annoying windows to interfere with the tracking. There I got many more testers, and some even thought it was the best game they'd played that day. Almost everyone that played was wowed by the game and the tech. That kind of feedback really warmed my heart and gave me a confidence boost that I might be onto something. But the game was full of bugs, and I had to explain basically everything to the players. So I got a huge backlog of things to fix for the next test.
v0.6.4: A couple of weeks later, it was time for Retrospelsmässan. It's a recurring gaming event where nerds come and buy and play old games and merch, but they also had an indie room. This time, I had a nice big poster, had fixed tons of bugs, and was ready to test. Of course, the first day didn't go as planned. Most of the morning was spent trying to figure out why I couldn't retrieve any room data from Meta's room API. After a couple of hours of trial and error, I uninstalled and installed the game, and then everything worked. Wonderful. And then during most test sessions, all buildings were drifting towards the player and were reset as soon as they placed a new building. So I had to ask the players to place a random charging pad on the floor before placing any real building. Most players ended up with a big pile of charging pads on the floor. Such a waste.
But the reception was great nevertheless. I even had a couple of players who played for almost an hour, completing the entire demo I had prepared, and created a queue of curious players who also wanted to try. I had another headset, a Quest 3S that I had got the week before, but couldn't get it to work as it didn't allow me to play the same game on two devices, but it worked as a good showpiece for people considering buying a new (or first) headset.
I'll end this first devlog with a 10 min long raw gameplay video, played by one of my visitors at Retrospelsmässan in Gothenburg 27 October 2024. Enjoy!