Hello there once again! A lot has happened since my last post and I’m quite eager to share it with you all. First off, we’ve had about 3 or 4 different meetings regarding what direction we were going after finishing off the Satan Tower prototype in our first work session. I’ve actually got news for each one of the three prototypes that we’ve been working on, so I’ll save the best for last.
First of all, as you’ve all read up to this point, the Satan Tower prototype for Capstone has been finished for the past week as of today. While we couldn’t move on from 3 prototypes to just 1, we still decided to show off the newly (at the time) completed prototype to the class and get some feedback on it. Overall, the prototype itself was fairly well received, and in fact, there was only one problem that the professor had with the game. In order for this prototype to be complete enough to pass a challenge, we still needed to add one thing, a level end. All we really had to do was have the screen fade to black after the player kills all of the enemies and we’d be all set with that prototype. Needless to say, we were pretty excited with how well it was received after how hard we’d all worked on it. This meant that we had just a short list of tasks left to complete for this prototype:
- Complete 2 QA sessions (a minimum of 4 people each) for the prototype.
- Complete any required documentation for the prototype as listed on the challenge requirements.
- Add the level end component.
Following this, we actually decided on something rather important at our next meeting. You see, in order to move forward in the class, each team needs to “challenge” the first phase with no less than three complete prototypes as well as a bunch of documentation and 2 recorded QA sessions for each one. While our pace currently isn’t too bad, most teams in our section of the class as well as in other sections of the class will be challenging this coming week. At our current pace, we were not on track to do that as we had planned to challenge on October 10th, which is admittedly rather late to do so. In light of these circumstances, we decided at our meeting following last Monday’s class that we would only work on the VR game prototype for one week instead of the originally planned two. This still presented a problem, though, as even with AI and feedback loops to code, only one of our two programmers would get any decent, loggable hours. So, we decided that while myself, Stefan (the Lead Programmer) and George (the Lead Artist) work on the VR game, we would have Nick (our other programmer) work solely on the Caravan game prototype in order to decrease the amount of time before we challenge to move to the next phase.
In all honesty, the Caravan Game is probably where we have made the least amount of conceptual progress. In terms of the original concept design, not much has changed since the last blog post I made. However, we have decided on what will basically be the core game loop for the prototype in order to challenge with it. First off, we want the game to start with a side view of the actual caravan (an RV) with the different group members (the leader/player, the mechanic and the hunter) inside. After a few seconds of a moving background, we’ll have the caravan slow to a stop due to some kind of engine problems. It’s here that we’ve chosen to create three different “mini-games” of sorts. First, we’ll have the hunting mini-game, in which the player must hunt and scavenge for food to keep the caravan members fed and well. This will be extremely reminiscent of the hunting mini-game from the Oregon Trail games. We’ve also decided to incorporate a very simple mechanic mini-game, in which the player takes control of the mechanic in the group in order to fix whatever is wrong with the caravan. This mini-game consists mostly of sliding objects into different slots and connecting different matching objects to one another. Finally, in order to help completely show what we want the completed game to be like, we decide to include a battle scene in which the player must fight off a gang of bandits that come and attack the caravan and its members. Overall, the game will be quite short and has yet to be tested (obviously) but we seem to be on track to a prototype that will get its point across fairly well.
In terms of continuing on, this prototype is seeming to be the one that we’re least likely to move forward with. There are certainly upsides to moving forward with this specific game, such as the lighter art load, but this is certainly the prototype that we’re the least excited about.
Sword of the Sorcerer
Now, here’s the big one. The Knight on a Bridge VR game is where we have made the most progress of all the prototypes. One of the first things people may notice is that we actually managed to finally pick a name for the game as well: Sword of the Sorcerer. The reason behind us picking this particular name is actually due to some of the changes we’ve made to both the level and the gameplay for the game. In the beginning, we had the following level layout and gameplay plan:
- The player is defending a single bridge over a ravine from oncoming hordes of enemies (skeletons at the moment).
- The player must keep a certain amount of enemies from slipping past them in order to survive.
- The player can unlock different spells based on how many enemies they kill via the use of a skill tree.
That was really all we had. For a game that we were so excited about, there wasn’t all that much to it was there? However, thanks to the suggestions of one of the amazing professors here at Champlain College, we decided to completely revamp the map and parts of the gameplay. Instead of just the single bridge over a small ravine, we chose to take a 3-pronged approach, switching to using three separate sets of bridges connected to floating platforms that the player can teleport between. The map layout, from the side looks like this:
As you can see, the player starts in front of the large wizard’s tower at the far right of the picture, acting as its defender. This is where the title for the game actually came from, as the player is standing in defense of the sorcerer and his tower. The new map layout also changed gameplay in the following ways:
- The enemies spawn in the fog below and climb up the three large stone pillars at then opposite side of the map before starting their march up one of the three bridge chains.
- We added player teleportation back in, allowing the player to start near the tower and teleport between any of the yellow, glowing platforms.
- Instead of having the player cast spells, we have chosen to place the wizard atop his tower to cast spells for the player. This is done in the same killstreak kind of manner, with the player unlocking the use of the wizard based on how many enemies they’ve killed.
- Adding the three bridge chains has also added an enemy management element to the game, meaning the players have to keep track of how many enemies are on each bridge chain and teleport accordingly and efficiently in order to keep the tower safe.
- The new map layout has also added a large degree of verticality to the map, meaning that the players should get a sense of just how high up they are by looking over the edge into the fog.
- The new layout also means that less art assets have to be created in terms of environment (for this level anyways) and that it’ll put less stress on the VIVE when we run the game for playing and testing purposes.
With all of these changes, we’re actually looking to be in a pretty good spot and so far, we’re looking to be on track to challenge the first phase on the 3rd of October. That said, now comes one of the more difficult weeks, filled with shoring up of the prototypes, a ton of documentation, more QA testing and one of the most important decisions of the semester: which of these three prototypes would we like to go forward with?
Stay tuned for the answer to that most important of questions and even more weekly capstone development updates here on my blog! Thanks for reading!