Senior Project - PPJ #9
Physical production on the build slowed down a bit this week as I put on my developers hat and jumped into a ton of design discussions. This week, I participated in design discussions for UI, core Game Loop, and theme/identity.
Game Loop: In an attempt to meet and discuss rubber-banding and balancing, we actually made some slight changes to the core objective instead and decided to test these changes and see how they affect some of our previous problems. The changes are pretty small, but still important. Our main topic was keeping players engaged, even in a losing situation. My main personal goal as a designer is to keep players engaged and give them a fun, enjoyable experience, even when they are losing. I thought the best approach was getting some rubber-banding in (which we will still need) to give losing players the possibility of a win, but in this situation that works more like a Band-Aid fix and not a permanent solution. We realized that who wins and loses is largely dependent on which set of teammates knows each other the best and/or are more outgoing and willing to communicate. Communication is the key to winning, which is great and entirely what we were going for, but in the process of designing the objective to fit that goal, we may have locked off the ability for an individual to do well a bit too much. To win, a team has to work together, that’s a given, but I still want to give players the ability to do well individually and experience a sense of pride and accomplishment (lmao) from their own success.
The way that we are attempting to give a tiny bit of control back to the individual player is as follows: both players must be on the hill/point, uncontested, to capture it for their team and activate the flags for capture. However, now both players can leave the hill and go collect flags. This is in contrast to our previous design in which one player would always have to be in contact with the hill/point to keep the flags activated. Now, once the hill is active for your team, it will stay active until the other team captures it. The method of gaining points stays the same; both players must be on the hill to for the points that they are each carrying to be “cashed in” and gained. Points cannot be gained if the hill is lost or contested. This change keeps the core necessity for teamwork and communication, but allows a player who is truly good at the game to make a bit more of an impact individually instead of being locked into a position (defending/retrieving).
One of our biggest criticisms has been that the penalty for falling is too steep. Previously, players would lose whatever points they were carrying and that number of points from their score if they fell. This is, admittedly, a huge punishment for falling and needs to be scaled back. The initial plan was to either decrease the amount lost or have it so you only drop your “flags” instead of dropping your “flags” and having points taken from your score, but instead we are going to try a different method first. Now, as players gain points, once they pass increments of 25 (5 flags), point locks will be put in place that prevent that teams score from decreasing below that point. For example, once red team gains more than 25 points, if they fall while carrying points they will only lose points until they are back at 25. Their score will never fall below 25 for the rest of that match. Once the team gets to 50 points, that barrier is placed at 50, and again at 75. In terms of flags, this looks like this: point locks at 5/20, 10/20, and 15/20. We believe that this will make the game progress a bit quicker and will eliminate many of the cases where teams either won 100 – 0 or where teams that were super close to winning lost all their points and lost. The reason we are trying this method first instead of just padding the punishment and making it less harsh is that we want to keep that “moment” (which I wrote about here) that occurs when a “high-value” target falls and loses points. It’s a big moment in our game that gets reactions, but now it’ll be less punishing as a whole. Players carrying >50 points will no longer lose the game for their team with a single fall.
Theme / Identity: We are still struggling to find our “theme”. Not our theme as in visual/audio/narrative theme, but rather that one word or phrase that describes our game as it base, most fundamental level. When designing the game very early on, we made a set of value that we as designer wanted to keep our game within. A set of design values that, no matter what, our game needed to fulfill. These “design pillars” are Motion, Environment, Social Space. This meant that, no matter what, our game at its core would have it’s core element be motion through a changing environment in the context of a local multiplayer game that your played in person with other people. We’ve struggled to separate our theme from our design pillars because, while very similar and in the same vein, they are different things. A good example that I can think of off the top of my head would be Mario. I would argue that the “theme” of Mario, at its core, is “Jump”, hence the appropriately named “Jumpman.” The problem we have is reconciling all of our core elements. We could say our theme is “build”, but that ignores the just as important “destroy”, and both ignore the local, in-person context of the game. This has been a very difficult dilemma, but I think knowing the identity of our game will not only make our game better (and make it easier to come up with a name for it), but it will make us all better designers in the future. We’ve made progress, but are still left at our design pillars.
UI: I have been working on UI functionality for the past 2 weeks but that has been put on hold for a while so we could finalize some designs and evaluate some technical barriers. The main design barrier was figuring out what the layout for the sign-in screen would be. In this screen, players will connect their controllers and have the ability to customize their team, gender, name, and control scheme. The discussion was over the usage of screen space and the necessity of menus. The original idea had a traditional selection menu with options/buttons below the character area. I argued that this was necessarily using screen space and that players who didn’t want to change anything wouldn’t even utilize those menus. Eventually, we ended up here:
In this iteration, we are trading in the 4 local selection menus for each player for a global set of button prompts. Most of our options can be cycled or toggled, so instead of a menu, changes can be visually represented on the character in real-time and cycled through with a button press. Any option that needs a dedicated UI element (name input / control options) will be an overlay on each players “column” that is brought up and disabled by a button press. This eliminates the use of a dedicated menu for each player and fully utilizes the vertical screen space to show off our character models in more detail.
What went well: I had so many meetings this week, but each of them yielded very strong results. A ton of good decisions were made and the over-all direction of the project technically/design-wise/artistically is very established and positive.
What could’ve gone better: With finals for other classes happening this week, I didn’t really do any work on the physical build, which honestly makes me feel like crap. I hate not making any physical progress, especially when I know there is work for me to do. The point we’re at is still very within the time-frame we planned (I’ve allotted all of winter break to do the UI stuff) and the design and decision making is incredibly important, but I always feel like I didn’t do any work when I have weeks off from the build. The UI input stuff is proving very difficult and is moving slowly. I’m convinced that we will never find a good name for our game.
UI meeting: ~3 hours
Design meeting: ~3 hours
Tech meeting: 1 hour
Other meetings: 6 hours
UI work: 2 hours and nothing to show for it
Total: 15 hours
Visit our senior project blog here.