Development Updated #7

The next semester is well on its way, and development has resumed. Over the winter break, Unity released a new version, so we upgraded our project to 5.5.1. This new version caused some slight repository issues with Visual Studio 2015 Tools for Unity, but we got them resolved.

Onboarding our new members took quite a bit of time. We needed to explain the process of how the entire project is setup along with how it functions. This was a good chance to update our readme with (more) up-to-date information about tool installation, script execution order, and repository configuration.

Much of the last few weeks has been spent fixing bugs and improving code. On fresh clones of the project, models were being imported incorrectly due to a script that was not completely tested before it was pushed at the end of last semester. This script ended up also impacting the water reflection/refraction, which ended up reflecting incorrectly.

We fixed many inconsistencies between the client and server projects. For example, our crafting station did not have a collider on the server. There were also a handful of old prefabs and assets that were no longer in use.

New Features

Day/Night Cycle

We have finally gotten around to implementing a day/night cycle. The sun rises and sets while the stars rotate during the night. Our ambient lighting can still use some tweaking, but

Drop System

A drop system has been implemented to randomize items that may drop from enemies that die. Stats on these weapons can be standard or “modded” prior to being dropped.

Other

Due to our previous outline shader not working at all, we have replaced it with a new one that looks much spiffier. We have also add the much coveted player names above each model (Horray! Now we know who is who). Nodes now also have a flag that allows them to spawn properly oriented to the normal of a surface.

We have begun implementing a new message display system for information from the server. This includes things like pickup notifications and such.

Movement has been updated so the player slides down and cannot jump up steep slopes.

After discussing the world event system, the base has currently been added. A new clock UI is currently being created which will replace the old fading icon. This system will allow for event firing to be synced to a time (tick).

Advertisement

Development Update #6

We are two days away from the official end of the semester. We feel much more confident about our game and direction than a month ago. Numerous bugs have come and gone, features have been written, torn down, and rewritten, and beautiful assets have been imported, broken, and re-imported.

A month ago, we had an impromptu playtest that showed us a very broken game. Now, we have a lot of complete features and graphical improvements that have really turned this project into a game.

Graphics

We have a bunch of new models, and virtually no programmer art left in the scene. We have models for the Krunchos, the primary enemy in the game, and animations for fighting them. We have assets for the core interactive parts of the game, the crafting station and the boat, as well as improved environmental assets for trees and the logs around the fire.

We had a fair amount of trouble properly importing assets from Blender into Unity, but we’ve streamlined the process and created a smooth workflow for adding new assets.

Gameplay

We put a lot of effort into polishing up and fleshing out the gameplay. Some core features, like resource gathering and crafting, have a lot of bugs. We still have a lot of work to do extending them, but the core functionality is there and we have been working to fix minor bugs as they show up.

The boat, as the central goal of the game, is completely functional, and with the new assets provides a good visual experience for the player.

We’ve added more resources and fixed up the gathering process, so it is both more intuitive and less prone to breaking.

Combat is now more functional. We have added environmental damage like acidic water and falling from great heights. The player will respawn at the campsite in the event of an untimely death.

A new feature has also been implemented, codenamed The Darkness. It took quite awhile to create a basic version, but we finally came to a consensus on how to implement this feature. While it still needs work, it is a functional part of the game that is important. We will reveal more details at a later point.

Design

After many, many, many debates on what we wanted this game to be, we’ve come to an agreement on the core experience and why people would play this game.

The initial and most influential design for the game was story and game feel. We wanted the player to feel like a colonist who was embarking on a new journey for humanity. This affected the game play as well as environment and enemy art assets. The visual feel of the alien planet as well as the unfamiliar resources the player must collect are examples of how this design continues to permeate into the play experience.

The world was designed to give the player the full game experience, so that they could have a sense of what the larger scale game would be after their play session. Everything from the starting position and location was tailored to direct the player towards the goal while also allowing for exploration and choice.

There is an overarching goal for the current build of the game and the player is encouraged to complete it. The environment pieces and terrain were made to influence the player’s experience and urge them towards reaching the end state.

The content of the game was designed thoughtfully around the potential play time. Additionally, we tweaked the numbers to make the game feel more fun and less of a grind. The rate at which players level up, the stats that are on each piece of gear, the enemy stats for combat, and the color scheme were all taken into account when we designed the world and how we wanted the player to experience our game.

Major decisions have been concerning the design of the player experience such as what happens when they interact with water, other players, and the darkness as well as when they die. Each of these factors have come together to create a hostile world in which each milestone accomplished by a player is incredibly rewarding.

Coming up…

We’re sad to say that two of our team members will be leaving. Trevor will be graduating this semester going to work for Liberty Mutual. Elizabeth will be going on co-op.

Our new members will be Ashwin (Gameplay Programmer), Rachel (3D Artist), and Julieanne (Concept Artist). Welcome aboard!

Over the Christmas break, we’ll be refactoring our current systems to make them more robust. This will allow our new team members to more easily build upon our existing framework.

Development Update #5

The past month has been busy for the entire team. With many discussions on the experience we wish to represent in the vertical slice, we have finally figured out what components we need for our upcoming playtest, and have been working towards those goals.

Our team has finally come to a conclusion on what our studio name will be: Mumble Bear Studios. Logo coming soon!

WASD

The biggest change with our entire design is the player control scheme. After discussing what we wanted players to be doing in the game, we concluded that click to move style gameplay was not the best option. Over the course of two weeks, we implemented WASD style movement controls.  This style of movement left huge gaps in our framework for updating player positional data, so we needed to refactor it. We needed a tick counter in order to tell when user input took place (and in what order). After adding a tick counter to the client and server, we needed a way to sync up the current tick.

Our logic for this is quite simple. First, we have the client send its current tick to the server. The server receives this information, and now knows how many ticks behind the client is. The server then replies with its current tick. When the client receives this data, it has all the information needed to sync up the current tick AND calculate its ping to the server.

After fixing the positional sync problem, we created a simple implementation of client side correction. If the player’s position on the client differs from the server by a certain threshold, we automatically snap their local position back to where it is on the server. We had initially discussed other implementations (that were much more complex, such as Valve’s Source networking), but due to the amount of time we have decided against using a more difficult solution for the time being.

Actors

Another big system we implemented was Actors. An Actor is an entity in the world that has movement logic, such as enemies and NPAs (non-player actors). Actors are correctly spawned in on the client when they are within a client’s region.

We created Actor spawners that allow for us to create a region where enemies are created (essentially a spawn zone). Players can fight and kill enemies.

Notification System

With the addition of each new system, we noticed there was no global notification system to inform the player of illegal responses and actions. We implemented an error message system that allowed us to inform players of the results of actions. These messages appear on-screen and disappear after a few seconds. We use this system to inform the player in situations such as when they are too far away from an object or when their inventory is full and they try to craft an item.

Stations

The next mini-system we added was stations. A station is a subtype of entity that represents only types of entities that can be interacted with to open a GUI. Each station holds a specific GUI ID that is sent to the client when they interact with it. The GUI with that ID is then displayed client side. The main action for a station is activation. Clients send activation packets containing the station ID they want to use/perform an action on. The server receives these packets, processes them, and returns the results to the client.

Crafting

Furthermore, within the last month we added the crafting system. Using the resource tool, we can create recipes that are loaded onto the server dynamically at runtime. These recipes are populated into stations that require them. For example, the anvil/forge station is populated with recipes that turn ore into bars. The system is highly dynamic and unquestionably easy to use due to the resource tool.

Workflow Tools

In order to smooth out our client to server (and vice versa) workflow, we began creating Unity editor scripts that create menu buttons that perform useful functionality with a single click. Below are listed some of the mini-tools that have been created.

• Start database servers
  • MySQL
  • Mongo
• Start backend servers
  • Authentication
  • Master
• Viewing logs
  • Unity logs
  • Network layer logs

Another workflow tool was created for asset package sharing between Unity projects. One of our biggest issues has been (and still is) keeping the assets between client and servers projects synced. We have to worry about every thing matching: layers, tags, GUIDs, and references. It is extremely easy to break the logic of the entire project by transferring over an asset and forgetting to transfer its dependencies at the same time.

To alleviate this, Justin created editor scripts to allow for automatic exporting and importing of the selected objects within the editor. This has been invaluable in speeding up our development workflow.

Art

Elizabeth has been hard at work on the newest iterations of the terrain. The starting location for the player has been completely revamped to more appropriately drive the player in the correct direction.

New flora models and textures have been created and placed throughout the scene to flesh out the natural feel. The campfire area has been populated with bench and fire models with particle effects.

Here’s some whiteboard art done by her for you to enjoy.

Development Update #4

This past week has been focused on resource management and starting iteration.

Due to the large volume of objects that need to be managed, it would be nigh impossible for us to manually change prefab values by hand. This led to the creation of: 1) dynamic data and 2) a resource editor tool.

Dynamic Data

In order to speed up our development process, we needed to be able to change data about resources without having to rebuild the entire game. We have refactored our code to automatically load resource data from files created by the editor tool.

Resource Editor Tool

While working with raw data files is an option, it is not viable in the long run when dealing with hundreds of resources. We would have to manage items, item data, resources, and resource data by hand.

Trevor has begun work on a resource editing tool that will allow us to modify resource data without having to work with raw data files. It has the ability to create and delete resources, along with modifying, adding, and removing properties for each individual resource. This will help speed up our development and iteration process.

Packet Library

After finding a bug with the total length implementation in our packet library, we dabbled with the idea of using reflection instead. The implementation was simple: all packet classes would uses properties, then the total length could be calculated at automatically. This left no room for errors. After discussing the issues with reflection speed, we decided to scrap the total length in our packets. Since each packet knows what data it needs to read and write to the buffer, and we do not batch packets for sending, there was not any need for this field in our header.

But after this, we still needed a standardized method of serializing and deserializing packets. Max refactored the packet library and created core functions for reading and writing many data types to/from buffers. When serializing packets, each packet need only call WriteHeader(), then WriteX() for each data type that it contains. Deserializing is the same process, but uses ReadX() functions.

Art

We have begun work on the first iteration of the vertical slice terrain. The majority of work has been creating environment assets and textures for them. Testing has begun on physics based environment animations and weather effects. Below is an in-engine render with updated models, textures, and animations.