top of page
cameron_schneider

Dev Blog 12: Senior Production Begins

It is now our final semester at Champlain, and since Breaker made it through the Greenlight selection process last semester, it's time to prepare for and execute a full production cycle!


At the time of writing, it is the middle of week 2. In accordance with the course milestones, we must have all of our production plans ready by at least week 5. This will include a roadmap, feature list, asset list (art, audio, and UI), as well as an executable testing plan. All of these items will have their own in-depth implementation plans as well, however that is not entirely a course requirement, and is a choice we made early on.


Professor Dan Buckstein, who happens to be my advisor, always likes to push the mantra "PLAN PLAN PLAN" and will always require a UML diagram for programmers. We want to take that approach to all areas of production this semester, since we have 8 new teammates unfamiliar with both the project, its goals, and even the engine & development tools. So far, we've simply been getting acquainted with our new team members, and introducing them to our workflows and our goals for the semester. Personally, I really just want everyone on the team to have one particular part of the project that they can point at during and interview and say "I did that, that's my work", so I'm trying to have each person choose a tool or feature from our (prioritized) list of wants & needs that they are interested in. After people choose, we're going to all research ways of implementing these features. Why? I personally find it a lot easier to learn new subjects when I'm invested in them, and I know that's a general trend for a majority of people. This way, everyone should be able to learn about the development tools in regards to their personal interests as a starting point before they have to expand into other projects and tasks.


So far, we have quite a few development tools that we're considering and researching. One such tool is going to be used for developing our multiplayer experience. By that I mean tweaking level designs, charge point placement, player traffic management, and weapon balancing. To do this, we essentially need to collect and analyze match gameplay. Thankfully, Unreal has their Replay system, which essentially records gameplay for later viewing; however, it doesn't really have support for querying things like player positions and actions. Additionally, we'll have to figure out how to track usage of certain items, such as our recharge points and weapon pickups. What we can do is have our dedicated servers automatically record and save each game, and then create a data analysis plugin for the UE4 Editor that utilizes those replays (along with metadata). From there, we should be able to run various data analysis algorithms over saved replays from testing sessions, and aggregate all the data we need. It will likely require us to make fairly heavy engine modifications in order to query player position as well as object usage, however, we may be able to write server-side game code that writes specific metadata into the replay, and then use that metadata in our analysis.

Outside of that tool, we've got another planned which is basically an admin-spectator tool. It would be useful for testing purposes to give developers elevated, server-level permissions during matches. Additionally, it would be useful for developer admins to see and be able to join & control any existing match. This will likely be the first tool that is worked on and implemented extensively, as we still don't have a fully networked game to analyze gameplay. To do so, I think we'll have to whitelist a subset of developer IP addresses so that our dedicated servers know who has access to restricted commands. Then, we'll need to collaborate with our UI programmer to develop an admin command console, as well as custom commands to control various aspects of the game while functioning as a proxy server. The admin should be able to:


  1. Fly around as a free-floating spectator

  2. "Possess" various player cameras and view their perspectives

  3. Control the match state (e.g score, progression, time)

  4. Pause and un-pause the match

  5. Restart the match


Whenever a whitelisted IP joins the server, they should enter the game as a spectator, and be presented with the admin console. Players will only be notified through an in-game messaging system (like a chat box). Of course, this feature needs to be removed prior to publishing, as it is a security risk to leave it in, but I think that's fine since this is mostly targeted towards development builds.

0 views0 comments

Recent Posts

See All

Dev Blog 16: Wrapping Up

We're almost done! It has been a wild ride over these last few weeks, and we've gotten a ton of stuff done--but I want to talk about our...

Comments


bottom of page