But honestly, as much as I’d like to say we had some super special process, the results are just a result of old fashioned iterate, iterate, iterate. What we eventually ended up on was mapping the phone’s screen space to your character’s space in-game. Using a joystick to push a mouse cursor around the screen is probably the most tedious, frustrating, and imprecise task in a video game I can think of, so we had to make sure that whatever we did for the movement marker was responsive and easy to grasp.įrom drag-and-drop on a main touch screen in our initial prototype, to mapping phone screen space to game screen space, we implemented a lot of ideas. When you think of console games and mouse cursors, you probably cringe. In particular, our "movement marker" went through probably eight iterations before we finally got somewhere we felt worked. How do you keep people from bouncing back and forth from the big screen to their small one too often? When do you split the player’s attention, and when do you get them to focus on one screen or the other? A lot of UI paradigms that game devs take for granted today had to be completely rethought due to the separate screens – like what information you display on the main screen, versus what do you keep on the controller apps. Zelda: Four Swords, the Jackbox bundles, and a Scrabble mobile game were basically our inspirations, and yet our game is still very different. Not many games out there use the model that we do.
The hardest part of the entire thing was actually user interaction. That’s part of where we ended up having to fight Unity a little, since their default networking model wasn’t conducive to the game we were building. Getting the controllers and the main game talking wasn’t simple, either. Having a rendering engine, scripting engine, networking, and so on already ready and waiting to go allowed us to build something that from scratch would’ve probably taken us three times as long with at least three times as many engineers. Having an engine like Unity behind the game certainly helped in terms of rapid development, even if we had to fight it occasionally. I won’t say that programming the game was easy per se – we’ve had many interesting and difficult engineering challenges – but between Leah Vilhan (our former lead programmer) and myself (the current lead programmer) we brought a lot of engineering/programming experience to the table. What was the toughest technical challenge of implementing this? Getting the controllers and the main game talking wasn’t simple.
From there it’s been a lot of iteration, and the game has evolved from our initial vision as we learned more about what works and what doesn’t. Luke or Scott – I have no idea who – had a lightbulb moment that hey, lots of people have smartphones these days, that would be perfect for keeping info to yourself. They couldn’t simplify it enough to ship as a board game, but video games could handle complex rulesets. We all have pretty fond memories of our role-playing nights in our friends’ basements.įast forward a few years later, Luke and Scott had taken Crythania and evolved it quite a bit, and they tried to make a board game out of it, including PnP RPG elements like secrets, backstories, and the like. Originally Eon Altar was a pen-and-paper RPG called Crythania that I had built way back in high school, which I inflicted upon my high school friends, which included lead designer Scott Penner, studio manager Luke Reynolds, and former creative director Ed Douglas. Where did the idea for the mobile companion mechanic, having your character sheet/dialogue on a smart device, come from? We spoke to lead programmer Joey Wiggs to find out how all this was accomplished.
0 kommentar(er)
