So I've decided to post a sort of "summary" of the development process so far, since we did do a decent amount of development before starting this devlog.
Here goes!
Original PrototypeThis was my first time working with 3D at all, so I made up some quick models in MagicaVoxel (based on Denver's sprites), put them in Unity, and got to work. I got a grid layout working and some basic player movement. It turned out to be quite a bit easier than I thought, then again I am severely limiting the use of the Y axis so it's almost like working in 2D
Then I put in a bit of physics and let the player knock over other pieces. This was fun, but could be better.
Voxel DestructionSince the MagicaVoxel file format is available online (
.Vox Format) we were able to extract out the individual voxel positions and colors of the models from the vox files. This allowed us to relatively easily let the piece appear to be 'destroyed' and fall apart. When the model is supposed to be destroyed we remove the mesh and replace it with individual voxel prefabs that have rigidbodies attached.
There were some hurdles, such as figuring out why the hell the colors weren't matching up with what I expected:
But I eventually figured it out, you can see the class I use here:
MagicaVoxelHelper.cs. Feel free to use it in your own projects.
New Assets/Real Movement AddedThis is where the game really started taking shape. Denver gave me some beautiful new models for the ground, player, and enemies. I added actual movement logic for the player, including height and checking for collision. The camera was changed to be an overhead isometric type of view, which is more appropriate for the strategy/puzzle-y game we had in mind.
Voxel PoolingPerformance started becoming an issue as we started destroying larger objects. This isn't surprising considering each voxel is instantiated with it's own physics. So we had to optimize the best we could and started pooling our voxel prefabs so they wouldn't be destroyed and instantiated over and over again. Pooling and limiting the number of voxels helped drastically, although this meant we would need to be careful how often we used voxel destruction.
Basic Enemy Movement/Goblin SoldierThe next step was adding our first enemy: the Goblin Soldier. He is about as basic as you can get. He takes one turn to get 'ready' to move, while in the 'ready' state the goblin will pulse to show that he is about to move. The next turn he will try to move toward the player.
Another thing worth noting at this point is that, while the physics in game were pretty funny, they made pieces very, very unpredictable. Eventually physics were removed from everything except for voxels.
Player DeathFinally implemented a lose condition. If the player can be attacked at the end of their turn they will be destroyed.
Spawning/Despawning Rooms Now that we had actual win/lose conditions we needed something to actually happen when you won or lost. The rooms are introduced by the ground tiles coming up from below the camera and the moving pieces (player/enemies) drop in from above. When the player wins or loses the ground is removed the same way, flinging pieces up in the air in the process.
Better Player Spawn/Piece Rotation Introduced a different way of spawning in the player to further differentiate them from enemies and also to just add more eye-candy to the game. It was a simple matter of grabbing the information from the .vox file and just simple position tweening for each voxel. Piece rotation was also added at the same time. Player and enemy pieces rotate toward the direction they are moving, this can be turned on or off for each individual piece.
Archer Goblins Archers were the second enemy to be introduced to the game. They don't have to wait to move like the soldiers do, but they do take a turn to aim before shooting and a turn to reload after shooting. They have slightly different AI as well, as they won't go straight for the player but will try to get within shooting distance then try to get to whichever lateral axis is closest.
Crossbow GoblinsCrossbow Goblins were an easy and obvious addition. They function identically to archers, but can't move and have a further shooting distance.
Attack AnimationUntil this point we weren't sure exactly how we were going to handle attack animations. We almost settled on a static, bump into enemies to kill them type of approach. That was pretty boring though, so we instead decided to mix it up and give our static 'figurine' style characters animated attacks, which we think turned out pretty well and has given us a lot of ideas for future character attacks.
Hidden Areas/Camera Improvements We've always wanted to have rich worlds in our games. For us, hidden areas are pretty much a must. We're going to hide so much crap in our game.
The camera was also drastically improved in this section of updates. If the room is small enough the camera will zoom in until it fits on the screen. If the room is too big then it will zoom out as far as it can then follow the player while also obeying camera bounds. The player can also now rotate the camera in 90 degree intervals.
Wow, this post was much longer than I thought it would be, it's great to be able to see how much we've actually gotten done. I think I will enjoy this devlog.