The End Is Nigh

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.

Advanced Functionality:

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…



So I only left myself with a couple of goals this week, as I wasn’t sure how much work was going to be required by the following two systems, and with a huge increase in work load down at the factory, I was finding it very difficult to set aside a good chunk of time for my project. Rather than being able to sit down for an hour or two here and there, it was a case of 15 minutes here, 20 minutes waaaay over there, the not so glamorous results are about to follow.

Create a day night cycle.

The day / night cycle was far easier to create than I had initially thought it would be. With real time shading available in Unity 5, and a new system which creates a sun off in the distance that rotates with the directional light in the scene, all I needed to do was to create and attach a script which rotates it over time and wallah!, Day / Night system created, with real time shadows throughout the scene. I’ve sped up the cycle so it is far more noticeable than it will be in the final product, should it ever reach that point.

Create or implement animations.

With the first system out of the way in less than half an hour, I was pretty amped to get into the character animations side of things. Low and behold, this was where my project was going to fall over…

Over previous weeks, I had learnt quite a bit about Unity’s animation system from getting doors to open and calling functions from the animations time line. I knew that working on a character animation was going to require a lot more work because of the larger quantity of moving parts on the character.

I was struggling to figure this out so I had a look around for any tips on creating animations, and only managed to come across one that was reoccuring… “Don’t try to create animations in unity!” after already attempting to do so for a couple of hours, I totally agreed!

Things were disappearing on me, objects rotated completely different to how I wanted or expected, and it was just a really frustrating experience.

I watched a few tutorials about animating in Blender and thought “yay, that looks pretty easy…” the problem though, is that I couldn’t import the pre made characters into Blender.

It was time to put aside the idea of creating an animation for now, (although I am determined to figure it out at some point) and focus on implementing the models accompanying animations across the network.

At this point, several hours spent, it’s Friday night (I’m lucky enough to have to work over the weekend…) and no real progress has been made in terms of character animations. I have organised the animation controller for the character with most of it’s animations set and ready to be connected via script but I feel time is now too short to implement the animation system across the network as it requires some planning, multiple RPC’s, and something which I can really only test out effectively with access to two computers. This is one requirement that may go unfulfilled for now.

I will continue with finalising the remainder of the project, as there is a little bit to do to get it ready for assessment, and hope to revisit the character animations over the next few days.

Import an asset from a third source. (Current plan is to create a rotating quest marker). Completed last week: Imported health pick up for use in health system. I did also complete the rotating marker, but this was imported from blender.

Not the most successful week in the project but still some progress made. Let’s see how it all finalises next week 🙂


Unity Project: Week Three in Review

Continue improving house. Try to have it finalized this week.

This week I spent a bit of time just tidying up the house. It’s now pretty much how I want the basic structure to be.

I’ve added some ceiling lights and lighting throughout the building which is a big improvement, and adjusted the animations of the doors to work a little better, as well as adding some door audio. Unfortunately I have come across a couple of issues, specifically with the door animation triggers. Because I have used a sensor to know when the player is in a position where he can open the door, and some of the doors are so close together, two doors will open at once in some locations.

Two options here would be to change the design of the house, or look at a different way of programming the triggers. Because I don’t really want to change the design, I am looking at adjusting the scripts to only allow a door to open, if the center of the camera view is over the door. Something else I want to look at is adding highlighting when you are close to a door which lets you know the door can be interacted with.

Create and import health pickups.

This was an interesting part of the project for me. Using the building tools within Second Life is a lot of fun, and after finding out Open Sim had export ability, I immediately knew that taking something build within one of these worlds and putting it into Unity was something I wanted to try out.

To start with I entered an Open Sim sandbox, and created a simple medical box pick up using a few basic prims. It took about five minutes and I was pretty happy with it’s simplistic design.


Before importing it though, I quickly opened the file within the Blender modelling environment, to see more detailed information on the mesh. As I had suspected, it wasn’t as efficient as it could be. Each face of the model had been unlinked and had become it’s own entity. I selected all of the object and joined it together. The initial stats for the joined object were:

  • Vertices 210,
  • Edges 348,
  • Faces 168,
  • Triangles 168.

Considerably more than you might expect for such a small object. Luckily Blender has a simple function called limited “Limited Dissolve” which calculates the geometry and removes anything it considers unnecessary, and a function to remove any doubles.

The new stats after performing these functions were:

  • Vertices 40,
  • Edges 60,
  • Faces 30,
  • Triangles 60.

So as you can see, it makes a huge amount of difference, and now requires far less memory to render what is essentially the exact same object, but built differently.

While it was in blender, I also marked out its texture seams and applied two basic materials to the object.


Implement a health bar system which updates across the network.

I’d had a bit of a practice run with the health system when I was making the gun script in an earlier post, and I’ve actually ended up just fleshing that out a bit more and it seems pretty robust now. It works across the network and has a slow regeneration (which of course may be altered with future pick ups/systems).

The health total is sent across the network via RPC and the health bar simply updates itself based on this information. Currently you can kill another player using your (currently) unlimited gun, but I haven’t created a re spawn system yet so the application gets a little confused when you do.

For the visual health bar, I ended up going onto youtube to look around for some tutorials on creating a health bar in the new Unity UI, and came across this one:

I ended up only really taking the design and recreating it in Gimp, as I ended up using a few different techniques, and the system he was making didn’t fit snuggly in with the systems I already had in place. This step wasn’t too difficult, and I didn’t really have any major problems implementing it.


Introduce a basic health pick up system, ensuring the pickup itself has some form of highlighting, and audio.

Turning the object I created into Open Sim into a functional pickup item was reasonably straight forward. I created a basic animation in Unity (I say ‘basic’ but it still took forever) and applied a trigger to the object collider. Now when the player collides with the trigger, The object plays out the animation by spinning, shrinking, and floating upwards until it disappears. It then adds 20 health points to the players health across the network, and updates the players health bar.

As I also wanted to play audio when this is triggered, I searched around for an easy way to do so, and found that functions could be triggered within the animation timeline itself. So implementing it was pretty simple. Rather than adding audio sources and adding a co-routine to time it etc, I was able to play it as part of the animation, at the objects position.

Something else I had to do with the pickup was to give it some kind of highlighting. I tried a couple things with this, such as rotating it, pulsating it (which I ended up using for the quest marker), putting a particle system on it, but they were all to obvious, and I wanted an element of subtlety to the highlighting of pickups, so players actually felt like they found the item rather than being told where it was.

To highlight the health pick up then, rather than add something, I actually took something away. I turned off the objects ability to cast and receive shadows by applying an unlit shader. I like that it stands out now, without jumping in your face.

So with week three behind me, and only two weeks to go, I’m pretty happy with the progress so far. Most things are surprisingly on track, a few things that need a bit of tidying, but isn’t that always the case? *Looks at the growing pile of dishes on the kitchen bench* 😐


Unity Project: Week Two In Review

So week two wasn’t any easier than week one… but I almost got it all done. XD

Continue improving house.

In terms of the house model itself, I have only made a few adjustments this week as I had a bit of scripting to do. I have adjusted the interior textures and fixed up a few textures which I had allocated to the wrong materials when I created the house in Blender.

Create the initial spawning system across the network.


The above is the very simple spawning script I created to instantiate the players across the network, and works really quite simply.

The player object is referenced by adding it to the player variable within the Unity editor, and I have set up multiple spawn points (only three at this stage) across the scene. These can be moved to anywhere, but are currently right next to the house I am building to stop me from having to hike half way across the scene while testing any changes.

OnConnectedToServer is a built in Unity function which runs when any client connects to the server.

The first event within this function is to reference the spawn points within the scene which have their tags set to “Spawn“. I then create a temporary GameObject variable spawnPoint, and assign one of the three spawn points randomly.

I then instantiate the character across the network on both clients and server at the position and rotation of the selected spawnPoint.

But there’s a couple of problems which I haven’t (yet) been able to fix:

  • The built in function Instantiates a character on all clients connected to the server, as well as the server itself. The problem here is that the server does not need the characters to be created within it’s scene. This isn’t exactly a game breaking bug as the characters will just run around on the server and not affect anything but it does take processing power for something unnecessary.
  • The second issue, and it’s quite a big one that I’ve found has affected a lot of people working with unity networking, is that anything with a NetworkView (the functionality that lets objects talk to each other across a network) that is instantiated using Network.Instantiate, is allocated a NetworkID. The problem is, when a character is removed from the network, the NetworkID remains allocated across the network to an object that no longer exists.

There is one way I can think of to stop both of these problems, and that is to Instantiate characters through use of RPC calls rather than Network.Instantiate, which is going to take a lot more work. This way, the script can check that the call is only made on clients using a simple check, and the allocated ID can be removed when the players RPC’s and GameObjects are removed by the server. I will leave working on this step until I have learned a little more about RPC’s in the coming weeks.

Introduce a system where the user can change character model.

So this one took me a while to complete, partially because I had trouble with some of the new Unity features, partially because I had to create multiple RPC’s to implement changes across the network, but mostly because I went completely off of my original plan of creating a simple Input managed change, to create a more comprehensive customisation system.

Now when pressing Escape to bring up the disconnect window, a simple menu to change character is also shown on screen, including a secondary camera which shows the currently selected character (shown below).


Cycling through character models changes the texture applied to the character, removes any additional character meshes, such as hats, camera, hair, and adds an appropriate mesh where available. This happens across the network via two RPC’s.

Although it doesn’t yet look ‘pretty’, the functionality is there. The main issue I had with this step was something that had me rather frustrated, and unfortunately plays a pivotal role with the more comprehensive path I chose. The new Unity UI system (Which is causing more headaches than I had hoped for) has depreciated the old way of locking/unlocking the cursor, and they have a new way which looks very simple when reading up on it. The problem being… I couldn’t get it to work, along with a lot of others on the Unity community forums. Eventually I did stumble on a way to get it to work. I’m still not sure why it works, by placing the script in a certain location… but it does. So for now, I’m happy with that.

Create a simple weapons system to display a particle on impact, ensuring the impact has some form of audio.

The Gun script I have created for this part of the project can be found here. Some of the functionality I have set up for the weapon system so far is:

  • The weapon controls only work on the controlling characters inputs.
  • A fire rate, using a changeable variable, as will have different weapons available in future. This will only allow weapons to be repeat fired after a certain interval, and can change a weapon between automatic and single fire.
  • A range of audio clips which play from the characters position on firing the weapon.
  • A scanning system which searches for tagged objects in via a ray from the middle of the users camera view out for a changeable distance.
  • Depending on the tag of the object hit, the particle to be displayed will be either grey for debris from objects, or red from characters tagged enemies.

I have kept the particles as simple varied squares to keep within the theme of the overall project.

But even though this system was fun to make, it wasn’t without it’s fair share of headaches. The main one, which required a bit of an adjustment to the original plan, was the issue with the colliders not registering well at high speed, as the original plan was to instantiate a bullet object which fires out and detected collisions. Unfortunately, some colliders wouldn’t register at high speeds, and a few other weird things were happening, and turning down the speed of the bullet made it look a bit silly.

Because of the above, I changed the system to send a ray cast directly from the players location, more specifically at the users camera center, and did away with the bullet completely.

I have also added a very basic health system, which means that an enemy that is hit will lose 20 health points. But I will be developing this further next week.

There is still a huge amount of work to be done on the weapon system, but I feel this is a good starting point to build upon.

EDIT: Create doors and windows with more detailed textures for build requirements.

I have created the windows and doors within blender. They are not hugely detailed due to the environment design I am trying to achieve, but do show the application of textures better than plain colours found on the main areas of the house. I was able to have a look at a few different techniques for textures such as texture mapping, including marking seams of the object and then unwrapping the textures for drawing in Gimp (Another free programme for art manipulation that I love), and the easiest method for my current project, by allocating different materials to required faces. (Although I’m not sure how efficient in terms of memory this method is…).

One thing that may be a possibility looking forward, due to the style of environment I’m trying to build, is to create one texture with an array of colours, and apply those colours where required. This could save a lot of memory if only one main texture is required for a lot of the build, although it’s something that I will need to research further. The buildings from the assets I purchased form the Unity asset store use a single texture map for each building, model, or character. Again this is a technique that I would also like to look into further.

I have also added some animation based movement to the doors, in order to be able to walk through the house during play testing. This is only basic however as pressing the required input from anywhere in the scene will open the door, and this is not displayed across the network.

So here we are, another week done and dusted, and a bit more functionality added to the project. Time to see what next week has in store for me.


Unity Project: Week One in Review

One week down, and it was a busy one! Here’s a rough overview of how it went:

Blog for initial Plan and Design.


Build a house model for use in world. Try to keep with the design of the imported assets, however some differences will apply in terms of scale to allow for interior access.

While building the house in blender, there were a few things I had to keep in mind. First of all, was the purpose of the build. This was to fulfil the build specific criteria for the assignment, firstly, to build with appropriate scale of construction and textures.






In terms of scale, I managed to achieve a far better result than I thought I would. I’m really happy with the simple design, even if I did spend faaar too much time on it :S

The roof however had me a bit perplexed. I tried a few different ways to get it how I wanted which was similar to the original design, and at some stage I would like to go back and change it, but as I felt I was spending far too much time with it I simply extruded the outlining vertices and pulled them into the center. It may not be the prettiest roof but it should keep the rain out for now.

As I had assumed during planning, the house I built is a bit bigger in comparison to what a small house from the imported assets would be because of the additional interior which needed enough space to actually move around in, but it still has a similar design feel.

I had planned on creating assets later on very much the same as the ones I had imported from the Asset store, but now I quite like the extra shape shown in the house and may move in a slightly more detailed direction. As for the textures, I don’t feel they really show any scale as they are plain colours that have been assigned to their appropriate faces. I have done this to try to keep with the simplistic feel I’m going for with the main project. Because of this, I have adjusted the schedule for Week Two to include doors and windows with more detailed textures while still keeping within the minimalistic theme.

For the use of shaders criteria, I had initially expected to require multiple shaders as I had done before while using unity, however the latest version of Unity now has the ability to use standard shaders which allow for real time shadows, straight away I jusmped at the chance as up till now it had only been available to Pro Unity users. It took a while to get the settings right to display it appropriately, and to be honest, I’m not sure what I was doing but managed to end up with a pretty good result. I even ended up with that plastic-e look for the objects that I wanted… even if it was by accident.

Import required environment assets and create a basic city environment with which to base the project in and implement the server client system.

The environmental assets I’ve chosen to use (for place holders) are the Simple Town – Cartoon City assets available in the unity store, and created by Synty Studios. These guys make some really neat assets and they come out with new ones pretty regularly. This was to make sure I could quickly have a reasonable space for game testing, but also as one source from which to import assets. The house I built being the second source which I created in Blender, so I still need to find a third source, possibly for the additional items I will be creating in Week Two.

Create a user friendly interface to create or connect to a server, possibility of dynamic server information to be displayed.

So I had already created a simple button that would either initialize either a Client, or a Server. It was a bit boring, and overall a bit crappy. But now let me introduce you to Main Menu version 2.0… alpha.


The textures applied to buttons have been imported from Kenny’s Assets, and I really like the look of the menu now.

I’ve added quite a lot of functionality to the menus as well. The new Unity UI makes the creation of UI’s really quite simple. It’s a case of drag and drop, and then add your functionality. It took me an hour or so to get on top of a few things, such as the new UI positioning system, but then I was away.


I’ve added in text fields to enter certain information which are initially filled out with default settings (above), and if they are changed, they can be loaded up using Unity’s PlayerPrefs system… anyone who knows Unity might let out a groan at that, as it saves and retrieves information from the computers registry, but it’s only temporary.

I’ve also added a quitting menu on the Server window and the Clients. The server window also displays the current amount of players that are connected to the server and the average ping as dynamic information. I managed to find a tutorial on how to do this and had to make a few adjustments as they used the old UI system. I do still have to create the correct RPC to show that information in the clients disconnect window as well.

Import Characters, apply the character controller script, and adjust for networking.

This step was pretty easy to finish off this week. I managed to find some awesome character assets from the same people that created the Simple Town assets I am using for the project, Synty Studios. I then had to simply attach the Unity provided script and made adjustments to enable it, or disable it depending on whether the client belonged to the characters user or if it was on someone else’s client.

So with a busy week behind me, and most of what I had planned to complete done, I can move on to next weeks projects. Will see you in a week!



The Beginning of The End

As we take our first few steps into our third assignment for the Multi User Virtual Environments course, I’m pretty excited to be able to work within Unity for my final project. This will be the first time I’ve actually had some sort of pre-planning before I’ve jumped into somewhat sporadic game development.

The project option I’ve decided to take is Content Creation, with a focus on creating a very basic non-authoritative server, and implementing network behaviours, as well as complex interactivity. So this option is based on one of the available assignment options, which requirements have been altered towards basic networking, and to allow for creation in Unity, as opposed to Second Life. It is important to note however, that my aim is not to release a finished product at the end of the five week time frame, but to create a good portion of what will effectively be the platform for an on-going project.

The project brief will be here once it has been finalised.

Initially my plan was to create a Game Design Document encompassing the game in its entirety, and then implement the requirements of the above brief into the world, but as I sat down with my Game Design template open, it became quickly apparent that I just am not yet able to fill it out in as much detail as I would like.

My initial run through of the project will be to create a basic environment and get the assignment requirements functionality working. After I have achieved this, I will let out a huge sigh of relief, and see what improvements can be made, I have referred to ideas for further improvements I would like to make as “reach goals” below.

Referring to the project requirements, I was able to evaluate some of the resources I would need, what areas I would be able to complete with my own current ability, and what areas were going to require more research. I have detailed below some of my findings.

Required Resources:   

  • Unity Development Software and Account
  • Blender Software
  • Gimp Software
  • 3D environment assets
  • Character assets
  • Character movement script

Assessment of Requirements:

The appropriate scale for purpose both in construction and texture use.

The use of different assets, textures, and colours throughout the build, with consideration given to using appropriate textures and shaders.

For the build criteria of this project, I will be personally creating a 3D building model in Blender and transferring into Unity. The below is the plan for a house that I will use as somewhat of a reference, however I am aiming for a rather cartoonish feel for the world I would like to create.



I also have some other assets available that I will use as place holders for future content. These assets create a very similar environment style to what I intend to use for the platform, however they do have a few draw backs which will mean many of them are unable to be used in the final project. The biggest issue is that the buildings are exterior only, which means the inside of the walls (reverse side of the planes) are not rendered, and the scale of the buildings do not easily allow interior environments that would be fit for purpose. They are also quite difficult to modify for a ‘non-designer’ such as myself. They will be very helpful however to show just exactly what it is I am aiming for.

Visual highlighting on at least three points of interest.

I would like pick up items to be clear from a distance, so would like to highlight them with some form of shimmering. I would also like areas which can be affected by user input, such as a door, to have some form of glow to highlight their interactivity. There will also be in game quests so a rotating quest marker may also be an option.

At least three sources for imported objects.

As I hope to work mostly on the coding side of game development, it’s going to be important to know how to find assets even if only for prototyping. I will be importing a couple of packages from the unity asset store which I have already picked, and will also be creating a few items in blender which I will be importing. Something else I would like to try is using the importing an object from OpenSim, as the building tool withing SL/OS is a very interesting one to use.

A scanning system that will detect the presence of a user, then interact with the user in some manner.

For this first piece of functionality, I am looking at implementing a basic pickup system. Initially I will look at creating a health pick up for the users. Some reach goals for this element would be to allow multiple different pickups with different attributes, and then on to other items i.e. weapons.

The basic functionality should be pretty straight forward, however it will be interesting working out the RPC’s required, i.e. removing the object from all game instances, updating health across the network.

An appropriate particle system.

My plan for the particle system, is to use it as part of the weapons system. The user will instantiate a bullet which fires and sends out a raycast directly in front of the bullet, activating a particle system on collision. The reach goal for this will be to have a different coloured particle instantiate depending on what the bullet hits.

I have managed to make most of these things work before, but not all together as one system, and not across a network. Again I will need further research into creating appropriate RPC’s

The Presentation of a Menu with a minimum of three options displayed.

This will be implemented for the initial game menu. The user will be able to select; Create a Local Server, Open a Client, Display Credits, Exit Game, or as the reach goal, Create a Public server.

The functionality for this should be quite easy to accomplish, although I have not really used the new Unity UI, which is far more wysiwyg than its predecessor but may still require a bit of research. Hopefully the only difficulty here will be to make it look good… the reach goal would be to include functions within an options menu.

A scripted change in texture / model.

I will be keeping this rather basic initially, users will be able to change their displayed character using a combination of Inputs at any time, as the game will be first person (subject to change) only other players will be able to see your character. In the future I am looking to add a third person controller element as an option. Using two clients, you will still be able to see the change) As this is rather dependant on the character assets I am able to get, my back up for this option is to create panels which can be placed over windows / doors as part of an Idle Play aspect of the overall project. The user will be able to upgrade barriers around safe houses.

User Character Movement.

For the character movement, I will be using a movement system which comes with an example project in Unity, and applying the required changes for inputs, and ensuring movement across the network. The reach goal for this will be to allow the use of a hand controller.

The main difficulty for this will be ensuring movement is relayed across the network properly via RPC’s, as the bulk of the scripting work has been completed.

User Character Animations.

This one is a little difficult to decide on an approach until I have some character assets, as they may come with animations. My plan is to either create a variety of animations within Unity, or if animations are already provided, set up an animation state machine which applies the appropriate animations.

Animations will probably require a tutorial for the first few, otherwise the animation state machine should be pretty straight forward. Again, the difficulty will be ensuring they are played across the network.

Create a Server Client Relationship.

I have the bare necessities for this in place from a previous project I was prototyping in. Unity makes it very easy to set up a network so the difficulty here will be programming everything to work across the network. I am aiming to create a different ‘viewer’ for the server, as for the clients, and plan to create a non-authoritative server, although this may change.

Use of at least five RPC’s across the network.

This is where most of my researching from here on in will need to be.  From what I understand so far, and from a limited amount of play testing, RPC’s seem reasonably straight forward, however having many RPC’s working in the overall project is going to be something new for me to manage. If I am able to complete the rest of the requirements, then this requirement should have been well and truly fulfilled.

Display at least two pieces of dynamic information.

Two pieces that I would like to implement early on are the health and energy bar, although there are a lot of options for this. A reach goal for this would be a chat window, which can display both user and system messages.

This should be relatively straight forward and should only require some time, and the chat system may be beyond this project.

An avatar spawning system.

This whole project would be a bit silly without any characters in it, so spawning system it is! The plan is to allow a user multiple spawn points from which to enter the game. The reach goal will be to expand it into a re-spawn system.

Implementation of a Day/Night system.

I have created a simple rotating directional light day / night system before. Hopefully this wont be too much of a problem to remake. May need to investigate the real time shading that has been introduced into Unity to see if there are any issues.

At least three uses of appropriate audio played in world.

I haven’t had much to do with audio up to date, although the system seems pretty straight forward for it. Some sounds I would like include, character audio, object audio, and ambient audio. These are things I will probably implement as I go. I don’t perceive it to be too hard but may need to search the Unity forums for a guide on best ways to do it.

Build for presentation of final project.

Creating a standalone executable build is extremely simple within unity. The reach goal here would be to implement the game either as a web player or on another available platform. I may look into these if I am satisfied with my progress later on.

Sooooo, writing all that out has made me realise just how much I have to do within the next five weeks (Gulp) but I’m confident I can get it done. As stated earlier, my aim is simply to get everything working, and then improve upon the bits that I can, assuming there’s time to do so.

So here’ a bit of a time line for the next five weeks.


Week One:

Blog for initial Plan and Design.

Build a house model for use in world. Try to keep with the design of the imported assets, however some differences will apply in terms of scale to allow for interior access.

Import required environment assets and create a basic city environment with which to base the project in and implement the server client system.

Create a user friendly interface to create or connect to a server, possibility of dynamic server information to be displayed.

Import Characters, apply the character controller script, and adjust for networking.

Blog on week one process and problem solving.


Week Two:

Continue improving house.

Create the initial spawning system across the network.

Introduce a system where the user can change character model.

Create a simple weapons system to display a particle on impact, ensuring the impact has some form of audio.

EDIT: Create doors and windows with more detailed textures for build requirements.

Blog on week two process and problem solving.

Week Three:

Continue improving house. Try to have it finalized this week.

Create and import health pickups.

Implement a health bar system which updates across the network.

Introduce a basic health pick up system, ensuring the pickup itself has some form of highlighting, and audio.

Blog on week three process and problem solving.


Week Four:

Create a day night cycle, ensuring appropriate ambient noise is used at appropriate times.

Create or implement animations.

Blog on week four process and problem solving.

Import an asset from a third source. (Current plan is to create a rotating quest marker).


Week Five:

Finish off any bits that need tidying up. (There will be some…)

Work on any reach goals that have a good chance for success within a very short time frame.

Blog on Reflection.

So that’s it for my initial plan, although I do believe there are going to be a few changes on the way.

Can’t stand around and talk all day, I’ve got a world to create! Mwah-ha-ha.








Protecting Intellectual Property

Before talking about Protecting Intellectual Property, specifically in Second Life, we have to take a brief look at what intellectual property is, and what the objectives of the law surrounding it are.

Your Intellectual Property from my understanding refers to something that may not have existed, if you didn’t create it. If you hadn’t used your experiences and emotion to make that beautiful water colour, or you didn’t use that knowledge to create that masterpiece of an invention. If you didn’t tirelessly spend hours on that 16 by 16 pixel sprite to get it just so, or spend weeks creating that orchestral kazoo theatrical music number.

Below I will be going into detail about Copyright, but there are other rights included under the Intellectual Property Law such as Patents and trademarks which most people will probably be familiar with at some level, even if not understanding them completely.

One objective that I have touched on briefly before is increasing incentive through financial reward from intellectual property.

Another objective of Intellectual property law is economic growth, but in terms of innovation, it could be seen as a negative, from keeping knowledge/creations to yourself when many others could benefit from it, or perhaps improve upon it.

There is also an element of morality involved being able to be rewarded for hard work, which some people may view as an ‘extension of themselves’.

Although there are many aspects of Intellectual Property, the second Life permission system seems to have a direct relationship with Copyright.


As is the case in ‘real life’, creators of original works in, or of original works introduced to Second Life, gain or are allowed to retain their position as copyright holder under section two in the Second Life Terms of Service agreement. This is something that is automatic by law, and not removed under the terms of service upon importing/creating within Second Life. (Some games or software may require you to give away your rights to certain things within their Terms of Service agreement).

You will always retain copyright over your items, unless you set the object licence to Creative Commons, or explicitly position it in the public domain. One way to do this is to enter a notecard into the objects inventory which states the above objective/s. So even when passing on an item with certain permissions, and even if you no longer own a copy of the item, you are still the copyright holder.

What being the copyright holder of an object means, is that you can set how others may use your product/object and what limitations or restraints there are for using it. (There are some usage rights that are automatically set as per the Terms of Service Agreement such as allowing Linden Labs the certain access required to store your property on their asset servers, and also those set within Second Life policy such as the Snapshot and Machinima Policy.)

The Second Life Permissions system allows the Copyright holder to more easily control the usage and distribution of their original creations. A more detailed explanation of this system and settings that can be used can be found in my earlier post on Permissions, but these aren’t the only ‘regulations’ you can stipulate for your own creations, you may for instance, allow or deny the items to be used on different platforms, this however is a lot harder to control.

By using this system appropriately, you can limit peoples ability to copy, manipulate, or trade your creations within Second Life in a way you didn’t intend for it to be used. Unfortunately, nothing in the technological world is completely hack proof…


CopyBot was a debugging tool originally created with the intention to  backup user creations, by allowing creators to replicate prims and objects and export them as an XML file, initially requiring appropriate permissions.

After the source code for CopyBot was made available on the web however, it was edited and re-released, and incorporated into other viewers and software with no permission requirement, meaning any 3D models in Second Life could be backed up using the likes of Copy Bot, and people were able to import the back ups with themselves as the object creator. This fooled the permission system into believing the new owner was the creator, and afforded them the permissions accordingly.

Using CopyBot to make copies of other peoples content which would allow you greater permissions than you should have in Second Life, is an infringement on copyright, and violates the Second Life Terms of Service, which has it’s own procedure and consequences. But there are ways in which you could use the tool responsibly, such as making backups of your inventory, or taking your items out of Second Life to work on them in other modelling programs. It is the infringement on Copyright or Terms of Service that Linden Labs do not allow, not the actual use of Copybot. Viewers however are not allowed to have Copybot functionality incorporated to be authorised.

There is however something similar for use when using the Singularity Viewer on Open Sim, which incorporates an additional Export permission. This can be used to export 3D environments or create a copy of your inventory, within OAR or IAR files specific to Open Sim.

As well as permission systems for IP protection, I can think of a couple other ways that may be able to help as a deterrent to those that like to break the rules, although they would require a bit of forethought when creating a build and could end up being more of a pain than they are worth.

One option could be to create objects which require scripts to work, as scripts themselves can’t be copied. You could also unlink your larger creations, as from my understanding, the CopyBot only copies one object at a time. Imagine having to copy, upload, and then put back together 100 objects. Probably wouldn’t seem worth it. If you were running a retail area to sell your creations, you could set up displays with modified objects, or posters on the wall as many do, using the permissions script to sell the displays inventory items.

There are probably many things that could help, and if it really was an issue for you, a good place to start would be learning how the CopyBot worked. Knowing how something works is the best line of defence.

In the end though,

“If it can be rendered, it can be copied.” – Imnotgoing Sideways.

So here’s a few things I’ve found based around Second Life and protecting Intellectual property:

If you believe someone has infringed on your intellectual property, Linden Labs does have an official IP complaint process found here. As there are millions of objects in Second Life, it may not be that easy to do, but following this process could end up with any copyrighted material you’ve noticed being taken down.

The next step could be to take legal action, but I could see this being incredibly time and money consuming, so you would really have to weigh up the investment you might have to put in, and the results you could end up with.

Learn the permission system. As well as being able to easily communicate your intentions, people can’t accidently do something that you may not have intended to be an available option.

Check, double check, and triple check that you have the right permissions set on your objects, including objects in their inventories. It may not completely protect your property, with the likes of CopyBot in the mix, and realistically, someone could come along and reverse engineer your creations if they really wanted to, but if you don’t want to make it too easy for people, heck, check them a fourth time.

If you’re selling items, give residents a good reason to buy them from you. Go for reasonable pricing, reasonable permissions, and try to make the overall purchase pleasant.

Not everyone is out there to steal your creations, and if one of your items ends up being the hair piece on 90 percent of Second Life Residents, it may be more beneficial to use it for marketing, or start a hair salon… when life gives you lemons, grab the tequila!