Round 14 has just come to an end ended with Quarionaid on top of the scrap head, congratulations! There he is in all his glory on the right. Runners up this round ElSnoopere and guima, coming in at second and third place, respectively. Congrats to those guys as well!
As always, you can visit the Hall of Champions to view all previous rounds’ winners in their fully customised awesomeness!
Round 15 has just started, good luck everyone!
Round 13 has just ended. Congratulations to DarkN for his place on top of the scrap pile podium, with SuperAndroid09 and KRONOS just slightly behind!
Please visit the Hall of Champions to view all previous rounds’ winners in all their customised glory!
Round 14 is commencing immediately, another 2 month round, so let the fighting begin!
Round 12, another 2-month long round, has just concluded! Congratulations to chicoteRAW for clawing his way to the top of the scrap heap and obtaining first place! He can be seen in all his glory to the right 🙂
Additional congratulations are also in order for KAOTTICO and lmn for 2nd and 3rd place, respectively.
As always, you can check out all previous round’s winners by visiting the Hall of Champions!
Round 13 is commencing immediately, so get in there and make some more scrap metal!
Some of you may know that we’ve been working closely with Mr Dog Films over the last few months on a transmedia project called Banshee. We’ve made excellent progress so far, but now the time has come to get Banshee the funding it needs to become the game we want it to be.
As of today, Banshee is now being crowd-funded via Kickstarter with lots of excellent pledge rewards. It would mean the world to us if you supported us by pledging.
Everything you need to know about Banshee can be found on the Kickstarter campaign site and the Banshee Facebook page.
Thank you!
Rogue Vector will be at the Wales Games Development Show 2013 again on June 26th this year! We attended last year as Deadworld Studios so we’re looking forward to christening Rogue Vector with another great show!
We’ll be showing off some gameplay footage of our current project, Banshee, as well as the other games we’ve developed over the past few years.
At time of writing, there are only 22 free tickets left so you better be quick!
You can grab a free ticket at http://walesgamesdevelopmentshow2013.eventbrite.co.uk
Hope to see you there!
We are very proud to officially announce that we have teamed up with Mr Dog Films to develop the game for a new transmedia project called ‘Banshee’.
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!
This is part two of an article series for Unity Development on an interactive computer / monitor system. See part one here.
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!
The first 2-month Round 11 is now over. Congratulations to lmn for taking first place! And kudos are also in order for Arobot and ale6 for taking 2nd and 3rd place. Remember you can check out all previous round’s winners by visiting the Hall of Champions.
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!
In the spare time between our contract work I’ve been developing technology for our future game. One piece of tech that we feel will feature heavily in the game is interactive monitors and consoles. While going through my thoughts I immediately remembered the strong impression that was made on me when I first played Doom 3 and came across their interactive monitors. I loved how they integrated more functionality into an area of games that was traditionally just an ‘on/off’ switch-style game entity.
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:
Very far away from the active game world
This keeps the ‘views’ away from any active area but our game will make use of a very large in-scene area. While our game will use a very large in-scene area, ultimately, there will always be space for it somewhere far out. We’ll be loading world data in and out as the player(s) move. I’m not too comfortable with this approach though as the ‘views’ will be a little dislocated from the monitor – it feels wrong to me too.
The game scene is the building area of the game. The active area is what we would load game objects into. This leaves some ‘no mans land’ which we could add the monitor ‘views’ to.
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!
As of today, Deadworld Studios will now be trading under the name Rogue Vector.
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.
This is part of a series of posts revolving around user interface design and development, the introduction and links to the other posts can be found here. Last I wrote about user interfaces I discussed the new Unity UI system and I wrote about our process of porting from Daikon Forge to it. That was a year and a half ago and a lot has changed since then. To keep things interesting we decided to move from Unity UI (yet another move?!) to Coherent UI and I’ll explain why we did it. Why Move… Again?!... (read more)
@SolitudeGame: Status update: Fuel reserves low. Asteroid mining facility detected on sensors. No response to our communications. On approach station appears to be abandoned and running on emergency power only. Away mission approved. Mission objective: Search and salvage - fuel is a priority.
@RogueVec: And so it begins! #RebootDevelop
@RogueVec: We'll be at @RebootDevelop this year. We can't wait! If you want to hang out just give us a shout! #RebootDevelop2018 #GameDev
@SolitudeGame: Fullscreen terminals allow you to hook into your ship's guns for fine control! Moddable gun modules, terminals and UI! https://t.co/B5N01jrA70 #GameDev
@CWolf: Woo! And, now we have a cross-compiled (nix --> win64) @SolitudeGame server in our build and deploy pipeline #RV #GameDev