We want to build a game that accepts the limitations of mobile development while stepping into the unexplored VR space. Simple camera controls is a mechanic that is taken for granted in modern games; this is a core component of VR that deserves proper respect. Observing should be enjoyable!
Limiting the player's inputs in this way lowers the barrier to entry they won't need a controller or other devices. It also keep the player's focus on exploring the environment and the interactions they can do.
The turn based aspect for this game should give players time to both consider gameplay choices and visually explore their environment.
What's the goal
The player is trying to escape from a dungeon
What does the player do
The player can perform one action per turn. They can attack a nearby monster, move into an empty tile, use a potion or use a magic spell. These actions will be explicitly displayed using a diegetic interface.
Players can also interact with non-gameplay objects during their turn without using their one action. Some examples of this are extinguishing candles, pickup up gold coins and smashing barrels
Gyro to Look
Trigger/Tap to Interact with buttons and non-gameplay objects
Diegetic Buttons for Move, Attack, Potion and Magic Spell
Magic Spells and Treasure
The Fireball Spell damages an enemy within a line of sight The Speed Spell allows the player to take 2 turns immediately The Cursed Sword gives the player mana when they hit an enemy with it The Giant Sword stuns an enemy for its next turn
Both the Slime and the Skeleton share a behaviour. On it’s turn, it moves towards the player. If it is within range of the player, it will attack for 1 damage.
Skeletons have 2 hit points. Slimes only have 1
This idea seems really different from the last one
Yes. Based on the complexity required to design, implement, test and balance a ‘medieval countryside simulator’, this seems like a much more reasonable scope for a game jam. That project is still on my todo list somewhere
Finished! + Bug Fixes +New Lightmaps
There was more last minute scrambling than I would have liked. Enemy behaviour and pathfinding took a long time to figure out. In the end, we didn't need Astar - enemies will just try to move toward the player.
Optimization was surprising. We had occlusion culling set up to keep everything smooth. In the end, the dungeon is just combined in Maya and rendered all in one go. The occlusion was a significant overhead and we didn't have a large enough level to get the benefit from it.
I have a lot I could say about the game design and level design, but I'll limit myself. The ceiling flipping mechanic was more disorienting that I thought it would be, and there is lots of gameplay (combat, puzzles,etc) missing from the ceiling section. It's something to expand and fix - I think exploring the same environment in different orientations is really neat, but we didn't give ourselves enough time to see where it could go.
The other major design change was removing the player's 'wait' ability. It would be very useful, but I like that the player is forced to do something on their turn. There is a tactic to using a potion to 'wait' on your turn. There is inevitability of that the first slime monster absolutely will hit the player.
Core gameplay including enemies should have been completed much earlier. We didn't do enough early prototyping to figure out strengths and weaknesses of the game design and interfaces