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:
Panels – Quick access monitors like ‘Open’ panels near to doors, lifts or single use machines. How Doom 3 did it. Environment Monitors – The player’s view is zoomed in and locked onto it. It will still show part of the environment around it. Fullscreen Monitors – Monitors that go into full screen mode. Security Cams – Full screen, limited movement angles and possibly screen effects Avatar Monitors – Full screen, full movement control (for turrets or robots/probes)
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:
Same coordinates as the monitor but on another layer for culling
This keeps the ‘view’ positionally relevant to the monitor and is easy to remember where the view is. The problem is that it feels messy to me. You can enable / disable layers in Unity so it doesn’t need to be messy but it just feels a little wrong to me, however, the ‘view’ in-game will be culled so you won’t ever see the actual ‘view’ – just the result on the monitor.
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 email@example.com. Thank you for reading and we hope you like the new site.
Round 9 is finally over, and it’s been quite a long one this time (plus an extra couple of unplanned hours). Congratulations are in order for Fluffball for coming first with quite a lead, with rambo taking second place and superdroid close behind!
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!
So, we finally got around to wrapping up the hard work we did over the community game fortnight. It was a great two weeks but we were a little optimistic with our time frame, especially since we had to make all the art ourselves! Most of the game systems are created so we’ll return to it soon to finish it off (the story is pretty good and we’re eager to share it with you).
The game is called ‘Freedom’ and it was create using votes to make a post-apocalyptic cyberpunk puzzle RPG about self-sacrifice. It’s pretty short but we hope you enjoy it.
Special thanks goes to Christopher Baklid (Inveracity) from our community who wrote the amazing soundtrack!
Round 4 is officially over and congratulations goes to NeverLupus as he continues his dominance over the Mechadroids’ leaderboard for a second win in a row! Nicely done! Well done to Titan and Timothy for coming in close behind.
Also, a big thanks goes to out to everyone who participated in Round 4. We’re slowly building up a larger active player base, which is great news. Mechadroids is designed around player versus player combat so the more players we have, the more fun Mechadroids will be. This, in turn, will attract more players!
That being said, we’ve been extremely busy behind the scenes here at Deadworld Studios and have had little time to work on Mechadroids apart from minor bug fixes. So, unfortunately, we’ll be kicking off Round 5 with no additional features. That doesn’t mean we don’t have anything new planned for future releases… and we definitely have some big plans!
We are also in the process of working on a Facebook (and potentially Google+) version of Mechadroids so you can play on your computer when you’re at home (or work) and then continue the fight when you’re out and about with the Android version. We’ll keep you posted on its progress.
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.