Friday Devblog 04
This week I haven’t been working on the buddies a lot unfortunately because of other projects. However, some tweaking has been done and a few bugs have been fixed, mostly in regards to performance.
The buddies will not spawn above the water anymore when the player is on the surface ( despite the entertaining images ), they will be more robust in swimming towards their preferred position ( i.e. in front of the player ). They are also smarter in determining a location to swim to. Before, they would only check if there is a path towards their preferred position, now they also take in account whether they can swim freely around that position.
The yellow spheres on the following images display positions where the buddy could possibly swim to. The green sphere displays the current chosen position. Here you can see a large wireframe sphere which indicates the area in which the buddy would like to swim freely.
This week I've been designing a system to manage all the different states the game can be in. For example,
a player character can be swimming around, using a tool, standing still during customization and so on. The user
can perform different actions depending on which state the player character is in.
It is possible to write code which sets variables, like for example when a tool is equipped, and then handle the input in different ways depending on which variables are set. This provides a large chunk of code with no Encapsulation of the states. The problem with this is that when changing the functionality of a state, it would be easy to accidentally create bugs in different states. It also means it is very hard to extend the functionality of a state, add a state or find the state you were in when a bug occurs during that state. The better code structure would be for each state to have its own class.
The game currently makes use of the State pattern. This is fine for quickly making new states, but becomes hard to manage when the states become more complex. The states handle their own input and act on that input themselves, while most other code in World of Diving uses the Model-view-controller pattern to split these responsibilities. This provides even more encapsulation, and thus improving the testability and maintainability of the code.
The ideal solution would be a combination of the state pattern and the model-view-controller pattern. This solution can be implemented in a number of different ways;
- Each state can have a model, view and controller class;
- A model can have classes for each state;
- The model, view and controller can each have classes for each state
We went with the last option. This provides a clean structure for creating states, and has the additional advantage of being able to create a system with only state classes for the model. This is preferable with some simpler systems, which have mainly the same controls and view in each state.
With this structure, the model class (and potentially the controller and view class) delegates its functionality to the class of the state it is in. This means other systems only need to have a dependency on the model class, instead of the state classes. This is an example of Loose coupling, which causes the system to be more robust and more easily extendable.
SteamVR and stuff
Another week full of bug squashing, one of them being the bug where quality settings are sometimes reset to 'very low', making the game 'not so pretty'.
SteamVR also needed an update, the game should launch on the correct display (the VR display). In order to get this working, I had to communicate with some tech guys from Valve. Among other things, the effects for SteamVR also needed a fix because surfacing and submerging effects were not working on SteamVR yet. This required a change in the way image post-processing effects were handled for the normal and VR cameras.
Last week I've been making some adjustments to the Bismarck model.
I adjusted the holes where the main batteries of the Bismarck were, so you can actually go in there instead of them just being black holes. I also added the damage to the sides of the hull and the torpedo impact on the rudder and added the third screw to the hull.
Sea horses and anemones
This week I finished the seahorse, tweaking some of the animations.
On Thursday I started with the Cusk Eel and friday morning I was almost done with the model. Friday at the end of the morning i was asked to make a sea anemone in-between making the Cusk eel, I was relatively fast with the model and around 3 a clock I started the unwrapping process.
Gameplay and stuff
This week I've been doing some more work on the Bismarck level. Although we allow players to dive normally in the Bismarck level without instantly killing them, we are still aiming to make the environment as realistic as possible, but not at the cost of gameplay. Therefore, it simply didn't feel right to add the oysters in the Bismarck level, so I created a mockup version of a new pearl container in the form of a little box that is scattered throughout the level. I've also tweaked the material of the doubloon pickups to make them more gold than yellow. They might be a bit too shiny for objects that have been underwater for so long, but we do want you all to notice them as you swim passsed! The HMS Tranquility (or as many refer to it: The Brony) now has seahorses swimming and hanging around and I added a challenge in which you have to photograph them all! We'll be adding more variants of the seahorses in the future, but as a first test, I think they are working out ok and they are just perfect for The Brony! Every now and then I try to reserve some time on a prioritized summary of the main design issues and ideas. It should reflect what has been discussed on the forums and I hope we can make it to good use soon.