The game is now playable for players using any combination of left / right keyboard or standard controller, although not all game mechanics are implemented (See most recent progress on Github). I did not accomplish all of my goals this week for game progress because I was working on the Design Presentation. That being said, we are still on track with the original planned schedule; however, my estimate last week of when the game will be playtestable by (originally by the start of Week 7) will be pushed back a week as a result.
Continue reading “Angela’s Status Report 2/15”
John’s Status Report for 2/8
This week I researched ways to connect the modules to the panels and communicate between the modules and the Arduino.
Connecting modules to panel/controller
Players must be able to quickly connect and disconnect the modules without pausing gameplay and shifting their focus. This immediately rules out any connector that requires precise positioning, such as pin headers and sockets, USB connectors, audio jack style connectors, etc.
One viable option is a combination of pogo pins and magnets. Magnets will help guide the modules to the right position and the pogo pins can make a good connection without needing perfect alignment. They are also typically rated for tens of thousands of cycles (or more), which is important since the core of our game is switching modules around. These connectors are expensive, but worth it for us due to their importance.
Sending signals from the modules to the Arduino
I looked at a few different options for how modules can communicate with the pins of a microcontroller (e.g. Arduino). The simplest option would be a module that is just a button with passive electronic components.
I also looked at different debouncing techniques. For our MVP, a simple RC circuit might work but I also considered the possibility of incorporating a Schmitt trigger. We’ll make the decision later after more testing.
Progress and next week’s deliverables
My progress is on schedule. By next week I hope to have some working hardware that is ready to communicate with a microcontroller. It should provide reliable, noise-free signals based on user input. I will probably start with a simple module like the push-button, but will also work on more dynamic modules that involve more electronic components.
Angela’s Status Report 2/8
This week, in addition to contributing to the proposal slides, I have started work on the game project in Unity (Github link here). There has been some progress on programming game mechanics as well as some team discussion of the art direction of the game and the interface between the controllers and the game. Progress on the game is on schedule. Continue reading “Angela’s Status Report 2/8”
Team Status Report 2/8
We’ve set up a Github for the Unity project and begun work on basic game mechanics. We have also done some preliminary research into electronics selection for modules and put in some parts orders.
Significant Risks
The most significant risk we see to our progress at this time is the complexity of the connections between the modules and the game panel. For our game to be enjoyable, it’s critical that switching the modules is fast, seamless, and reliable. This risk is being managed by handling this aspect of the project early on. As a team, we are discussing various ways to make solid electrical connections between the modules and the game panel. We are also looking at different ways to communicate between the modules and the panel. We are leaning toward mostly passive designs to keep the modules simple and minimize latency. A contingency plan we have is to focus on the simpler modules first and make sure that the MVP of our game works with them before moving on to more complex modules.
Significant Changes
We have not made any noteworthy changes to our overall system design but have made some changes to our module electronics. For example, we’ve decided to use an encoder instead of a potentiometer for one of our modules because it allows the users to freely spin the dial/wheel. This was necessary because it more closely aligns with our game design and how we’d like to control the submarine. It also allows the users to switch the module without it maintaining its state, since encoders do not output absolute position but rather direction and velocity. This will be slightly more expensive but still well within our budget so cost is not a significant concern. This is not a significant enough change to update our schedule.
Alan’s Status Report 2/8
This week I made some thought toward the module design. We have agreed on having 6-7 pins per module. One pin will be gnd, one pin will be Vdd, 3 pins will be designated as the identifier of the module via binary, and the last pin(s) will be for transmitting data from the module to the arduino.
I also made the order for 2 arduino leonardos. I have started some preliminary research on the peripherals needed for the modules. I found this potentiometer that has infinite rotation but it requires two data pins. We also might look into encoders but those are not passive devices..