Site Sections

Wednesday, June 15, 2011

E3 2011 Awards

Now that E3 is over, there are always awards given to developers for various categories from various sites. UTV Ignition Games, the company that I work for while developing Faxion Online, received an award from Massively. The full article can be read here. Otherwise our award and comments are shamelessly listed below.



Beau Hindman: UTV True Games. They not only showed off Faxion and were ready to discuss how much they were concerned about fixes and future updates, but they seemed to be having fun. I like an accessible developer. I believe in Faxion because it comes from the same place I would if I were a developer. Sure, it needs its fixes, but it's brand new...and what game doesn't need a few patches when it launches? Also, the rest of the games they offered made me smile. Planet Crashers? I must have it, now.
Shawn Schuster: UTV Ignition/UTV True Games. Their first showing at E3 was preceded by months of tongue-in-cheek humor in trailers and advertising campaigns, which simply reminds us that we're playing games to have fun. Their booth was impressive for a first-timer, and they seemed to get some healthy foot traffic. Will Faxion Online prove to be a hit? That I don't know, but the team behind it is still catching our attention.




I'm very excited, this is the first award that any team I have worked on has won since I have moved to the game development community. We have all worked very hard on Faxion and the rest of UTV has been working hard to bring games like Swarm, Planet Crashers, El Shaddai, and Sky Legends to the public. So I want to congratulate both the Faxion Team (myself included I suppose) and the rest of UTV for a great first half of the year and continued success.

Saturday, June 4, 2011

Faxion Online Post Release

Well its launched. Faxion Online, the game I have been working on with UTV for the last year has launched. Its fun to play and momentum is building in the community. I am very happy to see this work put forth in front of so many people. It has been really fun working with the Faxion Team and I have learned a lot since starting here a year ago (as of June 2).

I think there is a lot that Faxion still has to do to see it where it should be, and we have a lot of content planned for future patches. That excites me because I am not ready to be done supporting that product and making improvements for the product that I am creating and offering to the public.

On that note though, I am happy to say my second game is released for sale. Possibly looking at doing another side IPhone game in the future. With who is still left to be decided, I guess it just depends where momentum picks up on a new game idea.

I wish that I could highlight here some of the more complex stuff I worked on with the Faxion project but unfortunately you can't really discuss code like art without risking encroaching on copy write laws. For the most part it was tools development for particle systems and full screen effects. I created optimized terrain editing tools and I also wrote and maintain the Login system for the client. Overall I maintain the client in general and work on optimization.

Engines are funny things, there are so many working parts in them that one silly mistake in a single subsystem can impact performance. Also knowing what the tools do and how to best utilize them is really important for a team to understand. Getting a good balance between assets on screen at once and good play performance is a tricky number to maintain in a dynamic environment.

Anyways, I am wandering away from the subject of this post. I want everyone to go try Faxion if they are in to open world pvp and real time character leveling. Its a great game with more stuff coming every patch.

www.faxiononline.com

Tuesday, May 3, 2011

Art - Bathroom Starcraft Flyer

Something I whipped together today for our bathroom at work. We have noticed a large number of people who don't wash their hands... eww...

So a little Starcraft humor for the bathroom. Original artwork is owned by Blizzard.

Tuesday, November 16, 2010

Device Reset in Direct X 9

So, an issue that I have been battling for about a week involved resetting devices in Direct X. I wanted to cover how to do this and the possible downfalls you might run into while performing something that should be fairly straight forward to accomplish.

Q. When would you need to reset the device?
A. Anytime the device becomes "lost", this could occur when you resize the viewport, minimize the window, switch between fullscreen and windowed modes, and when in fullscreen, giving focus to another window other than the application which is running direct x.

Q. Why is this so difficult?
A. That is a great question, I am not sure. It seems like the Direct X interface should be smart enough to recover itself in the event that the device is lost. This is not the case. Not only is it not able to recover itself, it requires quite a bit of tender loving care when resetting occurs.

Q. What is required to reset a device.
A. After you have set up the code to create a device, your application loop must regularly check to see if the device is still active. This can be performed by calling the Device.TestCooperativeLevel() function. This function tests the device to determine if it is in a state ready to render. The possible outcomes of this function call are D3D_OK, in which case you may proceed to render your scene, D3DERR_DRIVERINTERNALERROR, in which case the device is in a bad state or the drivers are unable to process commands for some reason. The other two states are the important ones, these are D3DERR_DEVICELOST and D3DERR_DEVICENOTRESET. These indicate that the device is lost and needs to be reset.

Once either of the Device Lost or Device Not Reset errors are identified, code must be written to reset the device. The important thing to understand is that the device is very stupid about how it handles passing out resources. As such, you must ensure that the device reset occurs on the same thread as it was created. Additionally, Microsoft documentation indicates that the device releases all explicit render targets, depth stencil surfaces, additional swap chains, state blocks and default resources associated with the device. This means that any resource that is returned from the Device "Get" functions that return pointers to resources, must have their resource.release() function called on them to notify the device that the resource is no longer required. The down side to this is that any of these resources that will be required again once the device is reacquired, must be recreated before they can be used again.

The most frustrating thing here is that the Microsoft documentation states that these resources SHOULD be released, however, it is my experience that failure to release these resources causes the reset to fail, returning an D3DERR_INVALIDCALL. As a result, it really isn't just recommended, but a must, to ensure that all modules that request resources from the device have both a OnLostDevice and OnResetDevice functions that handle freeing and recreating these resources.

Another note, it is also a good idea to call the Device.EvictManagedResources function. This function removes any additional resources that were allocated using the managed resource pool. See this article for more information on the managed resource pool. Using the managed resource pool can also help prevent the need for the OnLostDevice and OnResetDevice functions for your modules, however there is a cost/benefit trade off here that must be understood and should be researched before choosing either method of resource management.

Once all resources have been released, we can reset the device. To do so, we must first build a set of Present Parameters similar to what we created when first creating the Direct X Device. This is the tricky part as there are many options here to set and any bad combination of these will cause the device to fail to reset. The important thing to note here is that you need some way for your application to know if it is in windowed mode or fullscreen mode when it resets (assuming that you want your application to have both a fullscreen and windowed modes). The reason for this is that depending on the mode, different settings require different values. For example, in fullscreen mode, you need to specify BackBufferWidth and BackBufferHeight values that equal a value that is equivalent to a supported display resolution. These can be retrieved using the EnumAdapterModes function. If the application is a windowed application, these values need to be set to the dimensions of the HWND object that is stored in the hDeviceWindow of the Present Parameters. Also, importantly, FullScreen_RefreshRateInHz should be set to the window resolution selected from the EnumAdaptersModes function in fullscreen mode, but should always be set to 0 in windowed mode, otherwise the reset will fail.

The rest of the parameters can be referenced here. Rules for setting each of them are listed. Be sure to verify that each of them are set accordingly depending on what mode your device is in.

Finally, reset the device by calling the device.reset(presentParameters) function. This will attempt to reset the device. If it was successful, it will return a D3D_OK and you should proceed with recreating all of your required resources by calling the OnResetDevice functions of your applications modules. If it does not, this is where the difficulty comes in. In most failure events the function will return D3DERR_INVALIDCALL, if this occurs then check your parameters to make sure they are correct. Otherwise, it is most likely due to a non-released resource.  Running your application using the debug version of the Direct X dll will improve the quality of the error message received from the Direct X driver. This may not be an option for you if your application is already pushing the limits of available frame rates.

I hope that this tutorial has been helpful. I know that when I went looking for information on how this stuff works, the tutorials were brief, mostly directed at solving specific problems and less about the actual theory behind the information. I cannot claim to be a Direct X expert and if any of the information in this article is false, as always feel free to correct me and I will update the tutorial.

Sunday, November 14, 2010

Game Review - Enslaved Odyssey to the West : Ninja Theory : PS3

I purchased Enslaved without knowing much about the title. Mostly that it was made by Ninja Theory and that it would have the same motion capture and voice acting work as Heavenly Sword. I was impressed by the level of cinematography in Heavenly Sword and with my love for action/adventure platformers such as the God of War series, Dante's Inferno, Darksiders, and Prince of Persia, I thought that I would really enjoy this game. The screen shots and cover art seemed interesting enough and the premise was something different as far as I could tell from the run of the mill "You are the hero, and you will go defeat the bad guy".

In Enslaved you play as Monkey, a man who lost his parents when he was young and has lived in the post apocalyptic USA about 200 years after nature has reclaimed the city. You meet Monkey while he is trapped on a slave ship, something the game never reveals how this comes about. You witness the other main character in the game, Trip, escape from her pod and start the slave ship on a collision course into New York city.

After escaping the ship you find yourself enslaved by Trip, forced to act to her every command, otherwise she will kill you. If she dies, you die. This leads to an interesting dynamic, but one that is actually quite glossed over in the game. Monkey and Trip become fast friends, only infrequently having dialog in the vein of Monkey's dislike for becoming enslaved. Maybe he just finds Trip so attractive (which she is) that he is willing to be her slave, hoping for some sexual torture as a reward.

Regardless of this, the dialog between Monkey and Trip reminded me heavily of the Ubisoft reboot of Prince of Persia. Interlaced humor and witty banter is quite prevalent. As both a pro and a con, you do not however have to perform an action button press to hear this witty banter, it is just interlaced throughout the level game play.

This leads into the second important aspect of the game, the game play. This I also found to be very similar to the Prince of Persia reboot, except that the parkour aspects of the environment were too easy to traverse. There was no chance of falling in most cases and it seemed to that pressing a direction and rapidly pressing the x button was effective enough in avoiding any potentially hazardous ledges that may fall. Combat was somewhat unique in that you use a staff much like Beyond Good and Evil, but that there was also combined areas of over the shoulder firing from your staff's plasma cannon. Overall, playing on normal difficulty, combat was very easy for the most part. There were very few times that I found myself in a situation that I was worried that I was going to die. Even less of those times did I actually die. I believe my death count throughout the course of the game was about 10. Most of these were due to miss understanding of the levels layout or a lack of cover when being fired on by ranged bots. This could have probably been avoided had I used Trip's distract action more often.

Graphically, I can not praise this game enough on the level design and artwork that really brings this post apocalyptic environment to life. I am however, a bit disappointed in the amount of texture popping that occurs during the cut scenes. The game was developed on the Unreal III engine and the age of the tech shows. However, I have played quite a few games on the Unreal III tech that didn't have this problem quite as bad. Perhaps it was an issue over texture quality and loading time. I would have rather opted for a longer load time and waiting for cleaner cut scenes than to see textures pop during the middle of a cut scene camera transition.

Overall, I was very pleased with the game. The witty dialog made for an enjoyable play through. It was far too easy as I had stated, probably good for someone who is new to the action/adventure platforming titles. The title is a bit short, however, there is a bit of re-playability as you can return to previous chapters to collect tech orbs and masks as well as re-attempt to beat some of the speed based missions for achievements or trophies. I would have to give the game a 7.5/10 though for the issues stated above.

Wednesday, November 3, 2010

Tower Assault! Curse of Zombie Island

Working with Rogue Pirate Ninja Interactive LLC, we have completed our IPhone title, "Tower Assault! Curse of Zombie Island". We are very proud and excited to bring this game to the app store for purchase. You can purchase it here or from your IPhone or IPod Touch device.


Tower Assault! Curse of Zombie Island is a reverse TD style game where you control a horde of zombie pirates against the forces of an Evil Witch Doctor who has stolen your pirate loot and cursed your crew. You control them by firing brains out of a cannon.


The goal of the game was to provide small bite sized levels that varied in the goals and difficulty as the game progressed. We didn't want to make a simple puzzle style game though and have weaved a story of revenge into the over all game play.

I hope that you try Tower Assault! Curse of Zombie Island and enjoy it. I should have more time to start posting again now that the work on this title is complete, so look forward to that as well.

Monday, August 2, 2010

Where I have been...

So it has been a while since I have posted, this was due to my job hunting and subsequent relocation to my new place in Austin Texas. It was quite a journey to get to where I am now, but I am much happier than I was before at GE Aviation.

The biggest reason, I got a job in the game industry.

My new employer is UTV True Games and I am working on the Faxion Online MMO (www.faxiononline.com). This has been very exciting for me and an amazing learning experience. I can't talk about much now, but I hope to be able to write more once the game gets closer to release.

In other news, work that I have been doing with an independent game group, Rogue Pirate Ninja Interactive (www.roguepirateninja.com) is going well. We are working on an IPhone game that has been announced called "Tower Assault! Curse of Zombie Island" and will hopefully be released in the coming months.

Finally, the other big announcement is that I will be getting married the 21st of August. So it has been a hectic couple of months and I do hope to get back into the swing of things with some reviews, some programming stuff, and some art.