Weekly State of the Repo

This first week was spent importing systems that I built over the summer, plus writing a build system.

The following key systems were written over the summer:

• ServiceLocator – Provides business code with access to the following services, or a null version of the same that will not throw errors in calling code if systems need to be disabled:
  • AudioManager – More will be written about this later, but it is a multi-layered system designed from things I learned from Eos and from my internships.
  • InputManager – Instead of a system based on the Event/Observer pattern, this one is based on the Command pattern. This is partially a result of doing so much functional Javascript programming at my summer internship.
  • EventManager – An implementation of the Event/Observer pattern for game events. A similar system was indispensable for Eos. The implementation was overhauled to use C# events and delegates to make all events typesafe rather than relying on an enum and an “object[]” parameter.
  • GameConsole – This was a bit of a pet-project over the summer, partially for fun (but fully functional). Activated with the backquote (`/~) key, this is an in-game console that prints any Unity logs. Game code can also register commands (such as “noclip” or “godmode”) and function handlers for when these commands are entered at runtime.
  • GameStateManager – At the moment, this is a skeleton class that will later handle game state and things like scene transitions. This requires gameplay code first.

My other focus was writing some pipeline scripts.

• One script runs on startup and checks to see if the user has our latest git hooks installed in their local git folder. If not, it asks permission and then copies them. Currently, we only have a pre-commit hook that checks to make sure all files being committed meet our naming convention, makes sure that new assets have meta files, and makes sure that paths are set up correctly.
• We also have an Asset Post-Import script that will create a material for all imported models, and attempt to fill the shader channels by looking for textures based on our naming convention. This will save a lot of tedious time, dragging-and-dropping textures in the Unity inspector.
• Finally, one tool adds a new menu option to create a build and upload it to our QA SVN server in one click. The tool reads the current git branch, gets the latest version number for that branch (for example, our master branch is currently v0.00.01a), asks the user how they’d like to increment it (by letter or by number), then builds the game into a folder based on the branch name, adds all the new files to SVN, and commits it with a simple message such as “NEW BUILD: master/build-090317-v0.00.01a”.

Brainstorming Review

The first week of Capstone is spent mainly focusing on brainstorming and coming up with 50 game ideas. Because of the individual interests of each of our team members, our brainstorming sessions tended to focus on two key concepts: weaponry, and stealth. While brainstorming, five ideas out of the 50 particularly stood out to me, although they might not be the ones we choose to move forward with.

1. A stealth detective game, with mechanics informed by games like Thief and LA Noire. You are a detective trying to stop a cult from selling weapons in the city. The gameplay programming for this would be simple to prototype, but there would be a lot of work required to get the “feel” just right, especially for the detective aspects. In general, this concept is more design- and art-heavy. For a proper noir detective feel, we would likely need custom Unity shaders, which I have some level of experience with but not to a point I would describe as comfortable. There would also likely be a heavy focus on audio systems, something I learned a lot about from Eos.

2. A tower defense game where you play as a massive AI supercomputer defending yourself from scientists trying to shut you down. You use your nanobots to construct defenses, which you can then jump into and control for greater accuracy. This is another concept that would be easy to prototype with only one or two tower types, but would involve a lot of “feel” programming later on. I could swear I remember seeing a very similar concept (of a tower defense game where you can control the towers) many times before, but I cannot think of or find any specific examples. It also has the potential scope creep of two games built into one.

3. A stealth theft-them-up game with mechanics informed by games like Thief and Dishonored/Bioshock. An emphasis would be placed on the magic powers which have limited uses, requiring players to use them wisely to escape with the most loot without being seen. This concept is probably the “scopiest” of them all, but is an idea I absolutely love. From a programming viewpoint, it would require intelligent AI systems that can coordinate and perceive their environment properly. It would also require some sort of inventory system—or, at the very least, a score system—for tracking what the player has stolen. Finally, the magic powers would be an entire system to themselves; the complexity of which would be informed by the design, though we discussed powers such as teleportation and possession.

4. A gun-making game where you assemble the parts of a weapon in an almost cooking-game style environment. One setting idea for this is that you are making guns for “the mob” and you are behind on deliveries, so you must assemble them at a break-neck pace. I played a lot of Cook, Serve, Delicious! at the beginning of this past summer, and this idea was partially inspired by that. Yet again, this is a concept that would be easy to prototype, and a lot of the difficulty and depth would arise from things like more complex “recipes” and time pressures, and would be more up to design and QA.

5. A Western-style couch arena game. The goal is to shoot and kill all other players before you die. Players would have health, and a primary mechanic would be spinning your revolver. The longer it spins for, the more damage it does, but spinning it for longer increases your chance of temporarily dropping your weapon, or even shooting your own foot.

This is possibly our top concept at the moment, and also has more programming scope. In addition to a solid third person camera, we’ll need to handle the fun of Unity’s input management with multiple controllers (which is an absolute nightmare, and would require a total refactor of the existing input manager), plus many other gameplay systems.

Overall, all the ideas we are throwing around right now sound roughly in-scope (at least with some tweaks), and we’re planning to make some quick digital prototypes of a couple before the end of the week. It’s exciting to get started!