No meeting last Thursday due to weather and technology clashing. Our next Design meeting will be on the 4th. To start this meeting off, we went over some upcoming milestones we’d like to hit. The first is an open playtest this Friday for KSBs 1 and 2. There will be one in February for KSB 3 and another in March for KSB 4.
We then briefly went over our QA database and how we want the team to use it. There will be an instructional video to go along with the database so it’s easy to learn. We’re anticipating team members using it to report bugs when we do the playtests, but also have hopes that it will be simple enough to learn where the Teachers in the field tests will be able to contribute to it as well.
There was a brief discussion on the Physical (real world) Modeling Curriculum Design. Since one of the goals of our project is to parallel every exercise in game with one in real life, and see which method is most effective, we needed to talk about how similar the content of the two exercises needed to be. Another thing that came up was if we needed a third activity that blended the two (physical and virtual). And how will we support the Physical portion of the game? Through the use of a Moodle? Something that needs to be considered in the future when we dig deeper into this issue.
Moving along, Jim proposed the idea to the team of implementing the Multiplayer in Second Life. It offers some distinct advantages and disadvantages.
- Shorter Dev Cycle
- Leverage COTS Technology (VoIP, SLOODLE, SLscripts)
- Lower Support Costs (IT and Community)
- Easier Community Management
- Less Access to Data – it isn’t on our server, use scripts to capture
- Teen Grid Access – staff will need to be authorized
- Lower Production Value
No decision needed to be made today, but something to chew on for future meetings.
The Design team resumed discussion on KSB 4, the water tower building activity. They’ve been working on making it more fun and challenging for the player. After that, it was time for Multiplayer talks again, this time about general game sequence and player activities.
Our next scheduled meeting is for the Development Team on Tuesday the 26th, weather permitting.
Due to unknown circumstances, we were unable to webcast today so it was a phone meeting only. That means no meeting recording either, which is a pity since we discussed a major change to our character animation workflow and rig.
Despite the technical issues, we had a full meeting with plenty of new stuff to go over and continuing tasks to finish. Next week we’ll be ramping up playtesting on KSB3 (the Snowshoe Race), first with small internal testing and tutorial video making, and ending the week with an open playtest on Friday. We’ll post more about the playtest next week, and also tweet our updates.
Kyle Bean is our master QA, Dialogue, and Game Design guy. For KSB3 he’ll be working on the tutorial videos that will be seen before the player starts the game. He’ll also be developing the entrance and exit questions, and the Project Testing Database System Presentation. Ty Hegner is our amazing Environment Artist and Musician. He’s working on the gray level for KSB 2, various game props, and in-game instructional videos. And Cecilia Mason is our awesome Art Director and Character Animator. She’s working on various environment props, establishing web content, and also re-rigging and re-animating the male snowboarder character (player avatar).
To elaborate on the decision to re-rig the snowboarder, the old rig was… old. It would need some significant modifications in order to add all of the functionality that was required, and most of the mocap data that needed that particular rig was dense and could have used some serious cleanup in order to lower file size. Since we had so many unique actions that were destined for hand animation anyway, we decided to push forward with the change in direction. Cecilia will create a new rig in Maya, then bring it into Motion Builder so we can share the rig between all team members with a variety of software. We’ll post a workflow video to our youtube channel once we make the shift.
Our next meeting is this Thursday for Design. See you then!
Our first meeting of the new year kicked off with us getting right back into the design of the Multiplayer component.
The design team began with an overview of plot motivation behind the Shelter Design activity and basic activities that should go on during this part of the game. We know that the team of 4 players will need to design and build a survival shelter based on what they’ve learned so far, and survive for 3 nights while the shelter is put through some strain. The gameplay has been broken up into 9 team activities to be completed within several class sessions.
We focused on questions that came up during the design process. Here is a list of the general questions asked:
Game Play Setup:
Teams of 4
- What if there are an uneven amount of students?
- What if students are absent for illness, out of classroom activities, etc.?
- Can the system play as a missing student?
- Can the system recalculate for 3 (or 5, etc.) team member efforts?
- Without roles how will work be divided?
- Can the system divide work tasks evenly between team members? Ex. Once a team decision has been made (e.g. Insulating materials) can the system divide up the number of tasks needed to insulate the shelter and distribute them evenly within the team – popping up each member’s task on their screen?
- Is there a way to make teams include students from various skill levels to ensure the teams have an equal chance?
- What will the students do while waiting for teams to be formed? Snowboard?
- What do teams do if they finish before the other teams?
- Is the game continually saving team progress?
- If any of the teams need to retry in the activities below, how far back do they need to go?
- We need to determine the average in-game time amounts per class period.
For the rest of the meeting, we discussed many of the questions in-depth. Good progress was made today, but we still have much work ahead in order to finalize the game design. This will be continued in next week’s meeting.
Each week on Monday we usually have a 2 hour team meeting to discuss the design of Survival Master Knowledge and Skill Builders (KSBs). At this week’s team meeting, we were joined by an engineering expert, Jack Goldberg, to discuss our learning goals for KSB 4. We consult with experts periodically during development in order to confirm that we provide the necessary lessons for the subject matter being taught. In the case of KSB 4, we wanted to ensure that we addressed all essential aspects of constructing a water tower.
The meeting started out with introductions and a brief game overview for the sake of our guest. After that, Jack and the design team bounced ideas off eachother on how to present the idea of “bracing” in the context of the game. They discussed various bracing types and ways of attaching the braces to the main posts, and what role the base of the tower plays in relation to bracing. After that, the discussion turned to what forces act on the tower supports and how the supports would fail given certain situations.
Some important points brought up:
- If you have proper bracing, the thickness of the columns can be reduced.
- Bracing essentially breaks up one lengthy vertical column into a series of shorter vertical columns that are less prone to buckling.
- Internal forces of the bracing without any horizontal force applied to the structure are essentially zero.
- Once a horizontal force is introduced (such as wind), the internal forces of the bracing increase.
- Showing a student the worst case scenario, then improving the structure from there would be an effective way of conveying the importance of each aspect of tower design.
The rest of the discussion was filled with specifics on measurements, weight, wind load, base design, connections, stability, and gameplay. At the end of the meeting, we were still struggling with giving the player enough choices to make this KSB interesting and fun. It is easy to come up with one or two optimal solutions, but for a player we feel it would be more fun if they had a wider variety of options for completing the exercise successfully.
In our next meeting, we will return to this issue and hopefully find a workable solution.