So it’s been an interesting journey over the past few weeks. Below is a quick summary of the requirements and how they were fulfilled in the final standalone build for the project.
For the build criteria I created a small house with animated windows and doors, as well as a couple of items for use in the eventual game, including a small health pack and quest marker.
To keep with the purchased assets which I had originally planned to use for the overall project (and still may, as building an entire world is no easy task), the textures I used were simple colours. I ended up adding some detail to the doors for that little bit of extra depth.
An interesting part of this project, was looking into the use of Open Sim as a building tool for assets to use inside Unity. Although I didn’t create the most intricate model to export, it was easy to get the model from Open Sim to Unity, and it was this process I was most interested in finding out about. The process can be found in my earlier post here where I created and imported a small health pack.
I highlighted points of interest in a few different ways, which in all honesty, I’m not completely happy with. I do like the pulsating quest marker, but the health packs just don’t seem quite right. I used some rotating, a different shader, and a particle system on three different models, and at one stage I had one model with all three, but the highlighting was a bit over the top. I have left the different types in the build for now until I can work out how I want to approach it. I think after some furniture models and props are added, the highlighting wont seem so over the top.
I used multiple sources of course, including the Unity asset store, Blender, and Open Sim. Modelling in Open Sim and taking it to Unity was probably my favourite, and I can see a few future applications for this.
There are a couple scanning type systems in place such as the doors, but the main system I created to cover this requirement was the Gun System.
There is still a lot of work to do to flesh this out, but I am really happy with the progress. It uses a ray sent out from the center of the players camera, and detects anything it hits. If it hits a wall, prop or object, it will instantiate a grey particle system across the network at point of impact, and if it hits another player, it will instantiate a red particle system. I kept the particles pretty simple to keep within the theme of the environment.
The menu systems were a lot of fun to create with the new Unity UI system. It took a little time to get use to it as it was a complete overhaul on the previous system, but it has definitely paid off. Not only is it easy to design, it doesn’t require anywhere near as much programming as it use to, meaning far simpler scripts to manage, and with upwards of 20 scripts already, it’s a huge bonus.
For the scripted change in texture, I put in a character customisation system where via a menu, the player can change both his texture and character model across the network.
For the character movement, I used the example script which comes with unity, and made a few adjustments to allow use over the network, and then created an additional script to update the players position and rotation across the network.
The character animations is where my project fell over a little. I had some idea of doing this in a single player game, but making it work across a network was going to take some time. I decided instead to create animations for the character and well… that didn’t go as planned. See my previous post where I go over the problems in detail.
I had to do something based around the character animations, and with only a small amount of time available, I added some functionality in the character customisation window where you can play different animations by pressing on the relevant buttons. The system used for this is actually very similar to how it will be used on the player character, only with some additional RPC’s to update the players animation across the network.
This however would not have been easily achieved without either a much better computer, which could run three different applications of the game (one for the server and two for the clients) as mine was struggling to handle it, or two different computers. This is because of the testing phase.
Creating the server client relationship was relatively simple, and I lost count of RPC’s somewhere around seven. These are used to update player movement, health, server information, object instantiation, and anything that requires messages to be sent across the network. Each of the previously mentioned often requiring two or three RPC’s.
There are a few elements of dynamic information already, including health, server name, current character, and a lot more to come. One thing I’m having an issue with here is the character health, and I think it is stemming from an issue I found early on with objects that were being deleted but leaving their network ID’s allocated. At the moment, when a character takes damage, all players unfortunately take the same damage. This is clearly a big issue, so sorting this out will be the first action I take after this project.
The spawning system works well enough at the moment, but again there is still a lot of work to do. There is currently no re-spawn system so when a player dies, he is disconnected from the server and sent back to the menu. I have created it so the spawning happens at random, and can be very easily changed by simply adding duplicate spawn point game objects. For assessment purposes, I have only one spawn pawn near my build.
The day / night system I found a lot easier than I had previously seen. A lot of the effort needed to create one had been taken care of in Unity’s latest release.
I managed to find some free audio for use in the game, all creative commons, some with attribution licensing so I will have to create a detailed credits scene within the options menu before any release (should that day ever arrive…).
I didn’t really get to focus on any of my reach goals unfortunately, but am pretty happy with what I achieved over the five week period. I managed to stay within the time frame for most objectives I set for myself, and even got a things done early, but there are also a lot of things that I wish I had done differently, as is normally the case with hindsight, so here’s a quick list of some of those:
- First of all, I wish I had taken this course a little further down the track. I really think I could have benefitted from a little more knowledge around networking, and databases.
- As it stands, there is currently no level of persistence within the prototype, and without a functional database, there didn’t seem much point. The best I could have done would have been faux persistence which I used for the likes of the main menu input fields.
- I also wish I had enough networking knowledge to really flesh out detailed game design document, which even though is changeable, makes it a lot easier to make decisions, when you can see the overall result you’re going for.
But the most important part to analyse at the end of this project, is what have I gained:
- One of the biggest finds for me, may actually be the brand new building tool within Open Sim. Not only does it have an interesting and reasonably simple building tool to use, it’s a lot of fun too, and being able to create in Open Sim, and take it over to Unity is something I can see me doing a lot of.
- I feel I’m really getting the gist of working with RPC’s. At first glance I thought it the inner workings looked simple, but then trying to implement a few left my head on the verge of exploding. Now though, with a little fore thought and a plan of attack, I’m pretty sure I can achieve what I want to do.
- I really enjoyed actually having a plan of attack with weekly goals. Normally when I’m working in unity, there isn’t much of a plan. Just some sporadic development, and often far to much time spent working on one part of the project, which really needs to be progressing to maintain motivation. There are quite a few things that need reworking in the project, but there has been a lot of progress over the five weeks too. Failing to plan, really is planning to fail.
So we come to the end of the project, but not the end of development. Where to from here? I guess it’s time to go back through what I have, tidy it up a bit, and then make the next plan of attack.
To be continued…