We’ve reached of the second half of the Ultimate Coder Challenge and it is a good time to review the progress we’ve made so far and get a top-down perspective of what we will be focusing on for the rest of this challenge.
Since the start we’ve had a clear idea of what we want to achieve: to teach computer science concepts to a broader audience, with the goal of either supporting their education curriculum or sparking an interest for technology and programming, which is what we do at Zenva.
Our first prototype was an experience where user could create add “commands” to objects in their surroundings. These commands were added a “program”, which the user could execute:
Whilst this was certainly an interesting concept (which could be used for other things, like actual content creation tools to build content in VR) it was a bit too complex in terms of UI and overall goal for our vision of Zenva Sky.
The second prototype we built was a spin-off of the first one, where the user has to enter commands for a robotic vehicle they are in, instead of environmental elements. This idea felt right from the get-go. Some iteration was needed in order to determine the best scale of the levels/challenges, and motion sickness considerations for the moving vehicle.
Determining the right “game mechanic” for this application allowed us to speed up progress, as we could shift the focus towards specific features, as opposed to broad conceptual explorations. To learn more about that process make sure to check out the previous instalments of this series.
We are now in the process of adding more features to the app, and polishing small details and improving the codebase.
The app has currently three commands for the vehicle:
Move and Rotate are very self-explanatory. Activate allows the user to toggle Boolean switches, which can be connected to different Boolean gates (AND, OR and XOR).
1. Activating any adjacent Boolean switch
Last week we introduced the Activate command, which is used to shoot a “laser beam” to Boolean switches. This action changes their value, which can trigger the opening of Boolean gates. In the version we showed in last week’s video, the user’s vehicle had to be facing the switch for the activation beam to toggle the switch.
After building a couple of sample levels we realized that this mechanic required way too many Rotate commands, as the user had to be constantly rotating to face the interactive elements. This prompt us to modify this command so that the vehicle no longer needs to be facing the switch, but can instead activate a switch located in any adjacent cell.
2. Six challenges ready for playtesting
That small change in the way Activation worked allowed for a much more fluid experience. We were able to modify the levels we had worked on before and also to create a level that includes two Boolean gates connected to each other.
We connected the 6 levels which provide around 10 minutes of gameplay. Connecting all the levels to each other has given us a good idea of what the app will feel like, and how it can be improved.
The very next step will be to add conditionals – something that can simulate an “if statement”. We also want to explore adding repetition (loops). It will all need to be done in a way that’s simple and that keeps the Program view clear of clutter.
We also need to make more progress in the art style definition, which has been challenging since the app mechanics were not as clear as they are now.
Our goal is to publish an Early Access version before the competition ends or shortly after.
Product and Performance Information
Performance varies by use, configuration and other factors. Learn more at www.Intel.com/PerformanceIndex.