This is your Captain speaking.
We've been going through some rough weather since take-off. If you had seatbelts I would urge you to fasten them, but due to budget issues we had to cut some corners. My sensors are picking up:
- Install/update problems on Android (error codes -504 and -505)
- Restore Previous Purchases not working
- Difficulty connecting to the Waiting Room
- Crashes at the end of the game (when you crash in Spaceteam you crash in real life...?!)
With version 2.0.2 I think I've fixed the first two issues. I'll investigate the crash next, and the connection issues will continue to improve as CaptainsMess (my networking library) gets better.
I'm also getting messages begging me to bring back Bluetooth. I hear you! I'll bring it back as soon as I can. I've been getting some promising results so far from the Android Bluetooth Multiplayer Unity plugin. iOS might be a bit trickier but I'm sure I'll figure something out.
Other things I've been working on:
- Updating the Lexicogulator for the new languages
- Updating CaptainsMess with the latest changes from Spaceteam
- Getting my new websites up and running: spaceteam.ca and spaceteamadmirals.club
- and... Blabyrinth!
Blabyrinth Project Setup
Last week I spent several full days working on Blabyrinth and it felt great. Now that I'm more familiar with Unity I have a much better idea of how to structure everything.
Some of the Unity lessons I've learned from Spaceteam (these may not apply to other games):
- Force all assets to be stored as text. Otherwise it's very hard to track changes in scenes and prefabs.
- Use a lot more prefabs, even if the object is only used once. Try to keep the main scene as empty possible. But be very careful with "nested" prefabs.
- Keep server & client classes totally separate. Never have ambiguity about which data lives where or who has access to what.
- Put static game data in ScriptableObject classes, not in the scene hierarchy
- Don't use Unity's built-in Animation Controller for simple 2D and UI animations, use a tweening library instead (like DOTween).
- I ended up not making good use of PlayMaker, and it was the cause of some of the suspicious Android permissions. For Blabyrinth I'm going to keep my state machines in code.
- Have an in-game log viewer and debug panel available from the beginning
- Use more custom editors and property drawers
- Use more coroutines and enumerators. But be careful about how and when they get cleaned up.
I'm designing Blabyrinth to be pretty extensible and modular, both for my own sake to manage the scope of the project and also to give it some longevity with later expansions.
I'm breaking systems up into components that I can work on separately, and the scope and complexity of each can change independently:
- Level Layout Generator — connectivity between rooms, secret passages, major landmark locations, etc.
- Level Editor — by default the level and puzzles for each game session are procedurally generated. But I also want to support handmade or "curated" levels, allowing for levels made by guest contributors and eventually fan-made levels.
- Puzzle Generator — locked doors and obstacles, clues, and solutions
- Mysterious Diagram Generator — certain clues will involve diagrams that contain hidden information and look something like this: https://twitter.com/ebooks_goetia
- "Riddle" Generator — a system for language-based clues, more on this later...
- Item Appearances — general purpose items like keys and books will have many variations in style, shape, material, and colour
- Level Appearances — cosmetic variations in the walls, floors, and scenery
- Character Appearances
- Custom Set Pieces — most rooms will be generated from a combination of reusable scenery elements, but there will also be unique special-purpose rooms used in certain situations
- Character Abilities — each player will have one special ability that allows them to solve certain puzzles that no one else can, ensuring that everyone gets a chance to participate
- (Secret systems that I don't want to spoil yet...)
I'll start small and add things to each component as needed. This way I can quickly make a fully playable prototype and then the game will progressively get more varied and interesting from there. But the first step is to make a bare-bones version of each system and get them all working together so I can start testing the game as early as possible. That will be my next major milestone.
Happy Canadian Thanksgiving!