Over the past two months we’ve been hard at work creating an experience that brings true horror to Facebook in the form of a real time, multiplayer game. Banshee is about survival and discovery, with the indirect result of territorial conflict, involving two teams – the emergency services and the spirits. The two teams will try to take control of areas of the city with the use of light and darkness, while discovering the lore of the world!

The game will be a first of its kind in eventually delivering the full length horror film, made by Mr Dog Films, via the game. We’re using Unity for development as we felt it was the best fit to achieve the level of immersion required for such an experience.

We’re really excited about this project and we’ll be releasing more information as we develop the game. Expect to see live streams and developer video blogs from us as the months progress!

For more information please see the Banshee Facebook page and website!

Over the past two months I’ve been slowly continuing with the Monitor system that I’ve decided to name ‘Farseer’. My last blog post ended with some open questions regarding the various design choices I faced, such as how to lay out the monitor’s view in the scene space. To quickly sum up I had two choices.

After some thought I decided to go with the second option. I felt this would ultimately be the best approach as it kept things spatially together. I discussed my choice with a few of our community members and they seemed share my opinion.

Now that the above issue was decided on… what was next? I felt that I had taken the current approach as far as I could and it was time for the next step. With this, Farseer finally was elevated to its own project! (I tend to prototype in a common project as it saves some time setting things up again).

My intention for Farseer has always been for it to be used in a procedurally generated game. The system will need to work well being accessed by various game systems, however, I didn’t want to limit how the system could be accessed. I wanted Farseer to be useable in the Unity editor too and so, with those thoughts in mind, I set off again!

As soon as I had made my mind up to make Farseer as flexible as possible, I hit another design choice. Should I use prefabs for the monitor objects, or not? Think of Prefabs as a ‘here’s one design made earlier!’ approach within Unity – a design of an in-game object previously set up by the developer. Unity development tends to encourage heavy use of prefabs and with good reason. They make development a lot less complex and messy. If I decided to use prefabs I would create ‘monitors’ of various sizes for use. A developer could then create one of these monitors that best fit their needs. My only concern was that I had previously encountered some issues involving the interaction of prefabs and RenderTextures (the flat 2D ‘live’ image view of what the monitor is looking at). In the end I had two choices – use prefabs or use a non-prefab, more code based approach.

I initially decided to pursue the prefab approach but I hit various issues that made me backtrack. The issue I encountered was that the Unity Material (something that helps define how an object is displayed in game) assigned to the monitor prefabs and Mesh (effectively the 3D model) seemed to be shared between all prefab instances (an instance being a ‘constructed’ version of a prefab).

In hindsight it was probably user error on my behalf. I was sharing a lot of Meshes for the monitors and this was probably causing the problems I saw. Ultimately, this meant that if I tried to changed a Shader effect on a monitor instance, it would change it for all instances of that monitor prefab. I realised that to make Farseer as flexible as possible I shouldn’t create monitors of various sizes as this approach is inherently limited.

So… with my new found knowledge (or so I thought) I took the more code based approach. I would generate the monitors as and when required using the required dimensions. This involved a bit more work but it was more flexible in the end, and by using Unity Editor plugin coding I was able to use Farseer in the Unity Editor too!

I plan to have preset monitor types that can be quickly created without a lot of effort but I also wanted to provide finer control over the system. I thought a two stage system of ‘Create Monitor’ then ‘Create View’ satisfied that need.

Looking at the pictures above, ‘Create Monitor’ concentrates more on the creation of the Plane / Mesh (effectively the 3D representation of the monitor) and it also generates the most suitable RenderTexture to fit the custom monitor size / dimensions. Once created you can see the beginnings of a monitor!

Again with the above pictures, the ‘Create View’ concentrates on creating the actual ‘View’ and linking it to the 3D monitor.

Taking a deep breath… that’s where I’m up to right now. It has less ‘pretty’ functionality than where I was at in the last post but my next step is to reintroduce the interactive sections I already have working. I don’t have any real blockers right now other than finding the time in between our contract projects to dedicate to Farseer. I’ll post another update once I’ve made more progress!

Until then – thanks for reading!

Round 12 is another 2-month round and has already begun, so duct tape that cardboardium armour and reload those foam missiles and get ready to fight!

I wanted to create something simple and effective similar to what Doom 3 achieved.

So, with the decision to do some tech prototyping I went about wanting the monitors to be as flexible as possible. It’s still early days but I intend to have lots of different monitor types supported. In my eyes the system should support quick access, full focus in-environment and total immersion monitors. So, here are the initial set of types I am dwelling over:

So… with those types in mind I went to create a prototype. You can see my efforts below in the Youtube video.

As you can see, it’s very early days but this proves the concept pretty well. Now… how is this implemented? As we’re using Unity Pro this is where a Pro specific feature steps in – RenderTexture. It allows a camera to render, or draw, its view to a texture. This texture then can be used on, for example, a Plane. By setting up a scene where the cubes can be viewed; the Plane can show this. By doing some raycasting on the Plane, then continuing the raycast from the intended camera – you can detect hits on the objects and then trigger the interaction.

In general this approach works well but I still have a few design choices to chew on. Firstly, while the camera and RenderTexture approach works really well for ‘real’ views such as Avatar or Security camera mode, since it’s looking at something in the ‘world’, it gets a little cloudy for the monitors and consoles. Where should the ‘view’ exist in the game scene for a monitor with just buttons / user interface options / typical computer interfaces and feedback? The two main trains of thought on this type of thing are:

I’ll have to give this issue a good bit of thought. I’m going to see if there are other options available to me that I’ve not thought up yet. I’m more inclined to go with the first option but we’ll see. One very interesting side effect I encountered has been getting an effect similar to Portal’s portals. By leaving a mouse controller active on the security camera monitor when it should be turned off gives a very similar effect to what it’s like to look through a portal.

We’ll see how the tech progresses – thanks for reading!

The reason behind the change is due to a trademark dispute with another games studio.  After taking legal advice on the matter, and a failed attempt to negotiate for continued use of the name, we are forced to rebrand.

We feel Rogue Vector fits our (James and Richard’s) feelings about our company and our determination for the future.  Running your own business is never easy.  You break away from a common path in life and you often encounter unknowns but it’s a direction we will keep travelling.  Our company is becoming stable and we intend to keep pushing to the future!

As a result of moving to Rogue Vector we’ve been able to pull together all the great systems we’ve developed such as the feedback and the cross-platform account system.  All these systems are now accessible from the main Rogue Vector site!  All our games will remain with us and there will be no service disruption to Mechadroids.  Any accounts you previously had still exist and can be used to log into our website (or you can visit http://account.roguevector.com for your full profile).

In the end, leaving Deadworld Studios behind was very hard for both of us but we’re excited about the coming years, projects and games that’ll be made under Rogue Vector.  The core values and culture that made our community grow and bond will survive in Rogue Vector.

With our eyes set on the future, we have some very exciting games in the works so expect to hear from us again soon!

If anyone has any concerns please contact us at info@roguevector.com.  Thank you for reading and we hope you like the new site.

As always, you can check out the winners for this round, and past rounds, by visiting the Hall of Champions.

Round 10 is commencing immediately, so get in there and start making more scrap metal!

You can check out all the previous rounds champions, and defeated piles of metal, by visiting the Hall of Champions.

Round 9 starts now, good luck everyone! You know the drill… time for action!

You can check out all the previous rounds champions, and defeated piles of metal, by visiting the Hall of Champions.

Round 8 starts now, good luck everyone! May the best Mechadroid win.

You can check out all the previous rounds champions, and defeated piles of metal, by visiting the Hall of Champions.

Round 7 starts now, good luck everyone!