Oversight is a stand-alone mod made for World of Warcraft. It is a unit frames Addon specially designed for arena and battleground play to present data in a way that is easier to assimilate by the average or beginner player. It may also find use by advanced players when making videos to better illustrate their strategies and swaps as targeting is made very visible to the user.

This mod is in Preview status. This means that there are bugs and incomplete features. Usage during regular gameplay is strictly at the user’s own risk. While bug reports are more than welcome, the main intent of releasing a preview build is to gather feedback on ease of use, feature recommendations and particularly annoying quirks. All serious feedback may be posted on the Oversight forums located here.

Features

• Movable unit frames arranged in a pleasing circular formation.
• Original Blizzard unit frame artwork, because circles are cool.
• Enemy frames are party targets during normal use, but are arena opponents when inside an arena.
• Spotlight targeting system to visibly show who’s targeting whom.
• Cast bar for each tracked unit.
• Aura configuration so that specific buffs/debuffs may be displayed for ally or enemy players. Aura’s may be shown in a ranked list of five, or may replace the character’s portrait.
• Unit Frame highlighting for poison, curse, magic and disease debuffs on friendly players, as well as dispellable buffs on enemy players.
• Race portraits for all units except pets.
• Raid target icons display.
• Spec detection and display.
• Locking of party member frames so that the same party members are displayed in the same order when entering battlegrounds or arenas.
• Sound alert for when the focus target is casting a spell, or when the target is casting a spell if there is no focus target.
• Extremely low resource usage.

To Be Done

• Preservation of raid target icons whenever the group is reformed, provided that the player is the party leader.
• Class/spec specific critical cooldown display and configuration, including PvP trinket usage.
• Spec memory – remembering the specs of past opponents and displaying them before actual spec is detected.
• Configuration checkboxes to toggle displaying each of the unit frame highlight types (poison,curse,disease,magic,dispellable)
• Better customization of the sound alert.
• Combo point display (Power Auras may be used as a temporary substitute)
• Death knight rune display (Magic Runes may be used as a temporary substitute)
• Shaman totem display (Totem Timers may be used as a temporary substitute)
• Scrub box, containing the health bars of all raid members that are not in your elite party. Meant for healers when they have nobody to heal. (Grid may be used as a substitute for now)
• Better pet support, so they can be spotlighted.
• Profile system for individual characters, and ability to copy configurations between profiles.
• Default aura list setup.
• Additional skins.

Known Issues

• Party locking sometimes results in the wrong raid member being tracked, especially if they are in the same party.
• Channeled spells only display cast bar momentarily. Targeting somebody channeling a spell does not display the cast bar.
• Some spotlights are still displayed when the unit has died.

Unity 3D

So one of the projects I’m currently working on that (being so covered in the traditional game-development shroud of secrecy that I cannot reveal anything about lest they deem it necessary to terminate my immediate existence)  uses the Unity engine for iPhone development. I believe there are also hopes that this may expand to encompass the newly announced iPad.

So how easy is it to create games using this new toy? Pretty easy it seems, to begin with anyway. Grab 3D models from your artists and drag/drop them into your assets folder, and they automagically appear in your editor. Match it with the appropriate texture, add a few scripts to implement behavior, and voila, instant game! At least that’s how the theory goes anyway.

How does it measure up in real life? Not so good, though admittedly, it could be due to the limitations of the iPhone edition, as well as my own relative inexperience with the engine. As I suppose could be expected, there’s the performance limitation for the iPhone. We’re limiting ourselves to 400ish polys for the main characters and 100 or less for environmental objects. The terrain engine is unsupported on the iPhone, so our terrain is merely a simple mesh. Also unsupported are shaders (though there’s said to be some emulation thing we haven’t figured out), and things like stencil shadows. Some developers have apparently been devolving to ancient techniques that from the 80’s to produce better-than-blob shadows.

Then there are other unsupported features like networking. Unity comes with full multiplayer support thanks to Raknet (which incidentally is my favorite network library). However, this is not supported on the iPhone platform. There are theoretically .Net sockets, but my junior programmers have opted to write their own plugins in Objective C, so they can incorporate multiplayer bluetooth support as well.

The GUI system is important because this is a major yardstick for the polish of the game. Unity chose the interesting approach of having their GUI system mostly script based. This makes it very possible to create spiffy animated UIs with all sorts of effects only limited by the programmer’s imagination. There doesn’t seem to be a visual editor for it, so the artists are at the mercy of the programmers to implement their visions. To be honest, I like it this way, as artists seldom have the mathematical background to implement the beautiful movements that programmers can pull off rather efficiently. The could do it with a Flash-like editor, but I guess that is something that Unity could eventually evolve towards.

Scripting happens in a choice of Javascript-like or C#-like languages that run on top of Mono. The team has mostly opted for the Javascript approach because it looks more familiar to most. As far as scripting behavior goes, it is pretty good, and I haven’t found anything glaring to complain about. It gets the job done. I’ve yet to see if we can do more esoteric operations, like programmatically attaching meshes to bones, controlling animation cycles and digging into the guts of the engine. How deep can you go in a drag/drop game editor? That’s yet to be tested!

Overall, I am happy but not. It certainly does the job. I don’t feel like I’ll have as much control over the process as I would with a traditional engine, which is to be expected. The limitations for the iPhone version put a severe cramp on our style, but the PC version looks pretty promising from this side of the proverbial fence.

So after a bit of scouring the interwebs, I’ve found a plugin that should forward all my blog posts to my Facebook page. So in a way, this is a kind of test to see if it works.

To be honest, I’m not a big fan of Facebook. When I first signed up a couple of years ago because it was the new “big thing”, I got inundated with silly stuff like invites to play games involving zombies, vampires, pirates robots – you name it. These are little more than time sinks. But as time sinks, they are really big! So a couple of weeks after I signed up, I deactivated my account and forgot about it.

Recently, for the Ninja Assassin game for iPhone, one of my tasks was to set up Facebook Connect to update highscores in the game to the users’ Facebook pages. So, in the name of testing, I reactivated my Facebook account, and wo behold, everybody’s still there.

Publicity is publicity, so I’ve looked at new ways to capitalize on Facebook as a way to reach out to people, and this is one of them. So if anybody’s looking for a freelance game developer, drop me a line eh?

Title Screen

This is an iPhone game based on the soon-to-be-released movie of the same name. It’s basically a horizontal scrolling action fighting game that uses swipes and gestures to control combat moves.

Menu Screen

Interestingly, for this project, I worked on everything but the main game itself. The accelerometer physics-based main menu to the Facebook highscore upload functionality. I even coded a bonus feature that is multiplayer over bluetooth and wifi (the main game, interestingly, is single player only) that involves throwing virtual things making use of the in game accelerometer.

The movie is due to be released at the end of November, and the game is already out at the iTunes Store.

This is a mobile J2ME project. From a central Midlet, users can download various games in the form of scripts and resources from a central server. This midlet then interprets the scripts on the fly to execute the game content.

The project makes use of the JSR 75 File Connection API as well as tools such as LWUIT and FScriptME. I basically took all these components, and welded them together into a functional scripting system through which you can create simple animated games. This was then handed off to the UI artist/programmer who I suppose will make it pretty and add polish.

They are probably still doing that now, so no names, no pictures, all in the name of the mighty NDA.

This program simulates dock-side cranes, and is used as a training aid for aspiring crane operators. The hardware resembles the interior of the crane cabin, with 3D graphics and physics simulating the actual dockside environment. There is also a trainer station, from which trainers can both modify environmental effects as well as observe the progress of the trainee. Multiple trainees can work within the same simulation.

There was a small team of developers working on this, and my job scope was to engineer the input system, interfacing it with the hardware, as well as providing a “virtual console” which can be used to test the product on a PC. I also provided consultation for the programmer who was in charge of implementing the physics using the PhysX engine.

The graphics implementation was farmed out to yet another company, which was pretty screwball. In the end, it was a huge project that employed a few individual disparate teams. It would probably have been much simpler to have all the development done under one roof.

I’m not sure if the company has gone live with this, so no pictures or names for now.

This is a shopping store simulation where customers can browse store products and purchase them through a realistic 3D application. The virtual environment is an exact replica of the brick-and-mortar store itself. The purchasable products are also exact look-a-likes of the real goods. Customers can manipulate these products, rotating and zooming in on them in full 3D.

This was all done using… wait for it… the Unreal Engine 3! Say overkill? It’s amazing what can be done when you have budget. We were sent to Shanghai for a 3 day training course and consultation. After that, we rolled up our sleeves and got to work. Our artist was going balls-to-the wall with all the fancy shader effects. I’m pretty sure he was in a constant state of artgasm.

Meanwhile, I got to touch on the finer points of Unrealscript and the underlying engine. What we came up with in the end was pretty darn good looking. But from what I know, it isn’t really launched (yet?). So no pictures. *shakes fist at NDA*

Project Alpha is the working title of a turn-based strategy game built for the iPhone for Personae Studios. It was created using the iPhone SDK and Lua back when the iPhone SDK was still in beta.

My main responsibility was as the Project Lead, managing and mentoring 3 interns to deliver the prototype within 1 month. In addition, I also coded the more complex features of the game, including a simple demonstration of a custom touch gesture.

While we did manage to deliver some interesting, if ugly (we had no artists) gameplay, the main thing seemed to be the framework which Personae used (I’m assuming) to develop a bunch of simpler titles to catch the launch of the app store.

Gather Your Gurbles is a casual physics-based game. The objective is to slingshot your character, Gale, to knock the enemy Gurbles off the play area. It features a wildly casual art style, semi-realistic physics, and a utility through which you can design your own Gurbles for in-game play.

The main menu

The project was done for a startup casual game company called Brick Age. I was the sole programmer for this prototype, but did not have to handle project management or design. It took a total of 3 months to complete.

The game itself features three game modes. The first is the adventure mode. This is where the player plays through all the levels in succession, and is peppered by humorous comments by the enemy characters along the way. Completing each of these levels unlocks it in the second mode… the Challenge mode.

Gameplay

In the Challenge Mode, players need to beat certain objectives in each of the levels. Doing so awards the player with a plain Gurble, which he can decorate with his own textures and stitching patterns. These can then be used for the third mode of play – Multiplayer. For the prototype, however, multiplayer play was not incorporated.

The whole thing was done with Playfirst’s Playground engine which I have grown to hate. The engine is multi-layered, usually leaving an easy way to do things and hard way to do things. Always a sucker for the easy way, I often ended up doing both. So yes, you use their sprite class to attempt to do positioning and deformations, find out that it can’t quite cut it, then go back to calculating your own good old-fashioned matrices. And then you take that and try to integrate that with their lua-based framework which encompasses the main game loop. Painful!

The intro screen

This was a quick flash-based pseudo-3D goal kicking game meant as an advertising gimmick for Gillette. Basically, it is penalty kicks with  a bunch of obstacles for the ball to bounce off.

It was integrated as a mini-suite of games that included soccer, golf, tennis and cricket. It was fairly entertaining implementing 3D pseudo-physics in a 2D environment, aided by some research in art that I happened to be doing at the time. In the book “Drawing on the Right Side of the Brain” by Betty Edwards, she stresses that you draw what the eye can see, rather than the brains pre-conceived notions of what should be there.

Gameplay

Taking that in mind, my “physics” comprised of making the ball smaller or bigger, altering the direction and speed based purely on what you would see if the ball were bouncing in 3D. This is opposed to the “math” approach where you take proper 3D physics and transform it to a 2D environment. It turned out to be more efficient too. Yay for innovation!

You can play this game at Gillete’s website.