I’ve been working with a loose deadline of around late october release, so with that in mind I’ve also had to make some tough choices about the viability of some of my design choices.

I’ve been working to refine the visual style for the actual gameplay to the UI. I’ve also explored different avenues for progression, and by extension,  menu functionality. In my last post I showed some concept work on the new menu visual style as well as the node based upgrade system.

Here’s the image of the full PSD as I worked to map out how sprawling the node system would be and help figure out just how many icons I would need to create. I also created all iterations of the elements I would need to build the node network.

As you can see, it’s actually  a fairly substantial  network of nodes. I really love upgrade tree’s and interconnected node systems but after looking at this I started to have genuine concerns about the amount of time it would take to create quality icons that accurately represented not just an individual element that was to be upgraded but the progression variants as well all  while being readable on a small scale. I’m only one person and this would eat a large chunk of time out of my schedule, not to mention having to build out the interconnected node system functionality  in Unity.

I was also concerned about the usability of this on the iPhone. Perhaps with the ability to zoom in and out and see the entire tree, people would understand what they were looking at and how everything connected. I built some tests in Unity to see how they played on the phone. You can see it in action in the video below.

I added a slight angle and 3D depth to each node to create parallax movement as you scroll around. This helped to give the illusion that the icons were more 3D than they really were. The 3D angle was something I had wanted to experiment with as some of my early sketches were based off the idea of a 3D space where the upgrade icons would be connected to their corresponding part on the ship.

The info box was also put in to play around with having context boxes show up when a node is clicked to give you all the pertinent information about purchasing that upgrade as well as the actual purchase button.

Designing a usable interface for phones and touch screens poses some interesting and somewhat unique problems over say a computer with cursor  input. There are no “hover” states that can be used to have contextual information shown. Some examples of contextual information being a simple highlight of a button as you roll your cursor over it. Something as small as that can indicate that an element is a clickable object over just a background decoration. On a phone, you only have the moment of touch /click. Anything clickable needs to visually communicate that it is an interactable element that can be clicked on, just from its presentation on the screen.

The lack of a hover option meant that having a node grid alone was not enough information for a user to know what they should be “purchasing”  or even if they wanted to “purchase” a particular upgrade. They needed information on the cost as well as what the upgrade actually did. This meant that the menu couldn’t be just a simple grid of icons where users would simply tap an icon to upgrade. There had to be an intermediary step between clicking an icon and purchasing the upgrade, which is where the modal box came in. The user would tap an icon, then have an information box show up giving them all the information they needed as well as a way to purchase the upgrade and finally a way to close the modal whether they purchased the upgrade or not. Figuring out each of these individual steps was important in understanding the functionality and user flow of the upgrade node system.

Seeing as there would be so many steps between the user finding the desired upgrade and being able to purchase said upgrade, the node grid itself needed to convey as much information as possible without relying on the modal. The grid itself needed to convey which upgrades the user already had, which upgrades were available to them, and what upgrades were unavailable. The grid also needed to convey the relationship between each upgrade and how they could unlock the upgrades they may want.

I created a visual language for both the nodes and connections to help convey all this information.

After all of this exploration, through visual design and functional tests, I re-evaluated the node system. I played a bit with my older system on my phone a bit, that just had 5 simple upgrade buttons that would increment the level of the upgrade. It was simple, fast, and easy to use. The problem that the current scroll system had that the node system was fixing, was the granularity of upgrades. In the simple system upgrading, say, the missiles with one button would affect multiple aspects of the missile without the user knowing it, such as firing more missiles at once as well as making the explosions bigger. The simple system also did not appear to have a cap and could thus be upgraded indefinitely.

Looking at the two different solutions I decided to merge the two solutions. The linear vertical scrolling system worked well for communicating similar information as well as being easy to use and understand. I decided to break the upgrading down into more top level upgrades. Instead of a single upgrade for each level of stat, there would be a top level upgrade that could be upgraded multiple times but have a visible cap as well.

This system uses a similar visual style while making all the information easier to find and simpler to use. The only issue is that with the expanded upgrades came an increased scroll length. My solution to this was found along with a way to unify the menu system as a whole. A way to navigate to the map / level selection screen as well as access any options.

There is less scrolling and when in the upgrades you can swipe left or right to get to the other upgrades as well as tap the nav tabs.

It’s not complete and I still need to make non-FPO icons but in terms of usability as well as viability, I believe I am on the right path.

Hello!

I’m currently writing a very in-depth post about my work on the new game UI and the UX of it. But in the mean time I wanted to post a few pics to show some style explorations and actual in-engine tests. Look for a much deeper breakdown of the systems and thinking behind them in a post to come probably later today or tomorrow! In the mean-time, PICTURES AND VIDEOS!

This is a shot of my working PSD with all the different node shapes and some color samples up top as well as a test of the full range of upgrades spaced out and arranged (even if unmarked, was more to test how things connected and would need to be situated for all the interconnectivity).

This is an earlier working PSD where I was playing around with different colors, layouts, messing around with text, and potential shapes. Although not very cool looking, it’s the playing around that led me to the style I really enjoyed.

This is a 3D render done in Cinema4D and adjusted in PS to get the DoF as well as color adjustments. I wanted to find a style and see what it would take to get something similar in Unity.

Now some videos of these comps as they were tested in Unity (note the videos were just tests).

And finally, a still of how the actual gameplay currently looks (at least for level 1). Quite a bit different from my last post. The screen is red at the edges from taking damage. There’s still more work that needs to be done but things are moving along!

I posted the time-lapse of my work on Team Radmars’ Grim Gateway. At the very end is some footage of me playing the game terribly. Also, please excuse the royalty free music at the beginning, I just wanted something there so it wasn’t totally silent. At least for a little while. Take a look!

Quick post about Ludum Dare 30! Once again, I teamed up with Radmars to create a 2D Action Platformer : Grim Gateway in 72 hours! I started out creating a lot of concept art then shifted into pixel artwork for environments, UI and splash / story screens. You can play the game on the Ludum Dare page HERE!

Or you can click the image to play directly!

I’ve posted some of the artwork I did created for the game below.

Koala-Bee and Manfish!and their Necro versions

ParrotCrab!

and his Necro version as well

and finally the CATerpillar. Which I didn’t even notice the pun until after drawing it…

Drew some weird tree.

Painted some ideas for the soul pickup item as well as projectile. Early idea of the Soul Gauge and the concept for the Grim Gate.

The following are 3 concept paintings for the ending.

Been working on the UI style as well as just overhauling how it will work. I am switching over the upgrading system from a simple leveling system to a node based research tree system. Here’s some examples of the newer icon styles!

Been plugging away on my Unity3D iOS game! I’ve been working with NGUI to create a much more responsive interface as well as testing out some styling for the menu system. I am playing around with some UI styles but my current favorite is this, which is cropped as it was posted to Dribbble:

And this is it in-engine with a few photoshop adjustments for the side lighting (still need to figure that part out, but I believe it’s possible). The current in-engine version is also not indicative one the final functional layout. I tweaked it a bit just to get it working so I could test buttons, sliding, and whether upgrades were working correctly.

I have a working scrolling version in the game now which you can see in a video I posted to youtube (I have the video set to show the menu right away):

Every thing in the game is still FPO but the codebase is coming along. Functionality is moving faster and faster. I have a simple Wave system in that’s easily changed in Unity’s UI which makes it easier to test. I also have multiple ships in that each have their own stats and upgrade independently of one another! This will come in handy when I implement unique ships with different capabilities.

Next up will be implementing a simple Boss enemy and update the Wave manager to handle Bosses. After that will be a research system which will tie into ship upgrades and make it a much deeper system. You will have much more granular control in how your ship progresses.

For now I will leave you with an image of a massive laser beam after mucking around with new laser upgrades.

I have always wanted to have an inventory system in one of my games. I love them. I love picking up random shit and being able to swap armors and weapons and potions! I have no idea why, but I love stopping in games and organizing my inventory that has become full of random stuffs. So, I made one!

NGUI comes with a bunch of tutorials and example scenes to show how you may utilize and setup a system using NGUI. One of them is an elaborate and surprisingly deep inventory system. The only thing is, the dude who made NGUI never intended it to be something he supported, it was just meant as an example.

I spent a few days going through the scene and the code to get a handle on how he went about writing the system and generally how to use NGUI for something so complicated. It was enlightening to say the least. Once I had a good understanding of his original code base I opened a new scene and got it working without the demo. Then I set about extending it to do some of the more advanced features that would be imperative for it to be actually usable in a game.

I created scripts to allow for picking up objects from a 3D environment and placing them into the inventory. The reverse, of dropping an item from the inventory down into the 3D world was actually far more difficult, but I achieved it! Finally, I needed to be able to have placable objects in the world that I could control, as well as allow enemies to drop items and have them be randomly generated. I created a youtube video showing it working. The UI is just the basic demo stuff that comes with NGUI as this wasn’t for any particular game but a test to get the inventory up and running.

I made a youtube video showing it work!

I created a short video on youtube of a time-lapse of me modeling and texturing a low-poly missile for use in my iOS shooter game. It’s not an especially clever or cool missile, I just wanted to make something very quick for use in the game as well as test out my time-lapse software.

I was also making it as a test for Youtube. One of my most viewed Youtube videos was one I made on a whim of messing around in Cinema4D modeling a rough character. I was curious to see if this would garner as many views.
Was it that character modeling was the draw or just modeling in general? WE SHALL SEE. WITH SCIENCE!

Also, I wanted to screw around with making an animated GIF using photoshop and videos. Was surprisingly simple!

Used Cinema4D + photoshop + ScreenNinja 2.0.

See the full youtube video by clicking the GIF below.

Good day, internets!

As can be seen from the dearth of posts between this and the previous one, I’ve not blogged much in a while. A long while. I’m going to do a rundown on some of the reasons for my lack of content, if only for posterity and my sanity. So, shall I begin? I shall.

Shortly after the previous post was written, I took a full time position at a startup in Rochester, NY. This put an end to my free wheeling freelance days. Starting a new job tends to suck up your time and mental resource. The job alone wasn’t enough to stop my game creation, but life as a whole is nothing if not a time Vampire.

Once settled into my new full time position my wife and I decided to purchase a house in Rochester. Apartment hopping wasn’t a long term plan and with both of our families in the area we yearned for roots and were hell bent on digging in. As nothing is ever easy, purchasing a house revealed itself to be a quagmire. The house needed repairs and the owners agreed but were about as difficult as could be imagined. Once all was said and done, we had purchased a home; but this was only the beginning of our adventures.

The house desperately needed refurbishing, which we jumped into immediately. Ripped up carpeting, sanded floors, painted, installed a fence in the winter, and leveled a bathroom to the bare studs. Amidst the renovation, my wife got an incredible promotion! This came with a required cross country move to San Francisco, though. We’d been operating at 200% on boring our roots deep into Rochester but when fate grabs you, you go with it, because fate gives no second chances. Thus began the process of rending our embedded roots in preparation for transplant.

Things needed to happen fast. Every room in the house needed to be painted, plumbing needed to be… plumbed..? (spoiler alert: I know nothing about plumbing). Outlets needed to be replaced and the bathroom needed new walls, paint, a toilet, lights, and a vanity / sink. Oh, and we needed to sell a car we had purchased less than a year prior. To say things got crazy would be an understatement, as cliche as that is.

To cut an already long story short, we got shit done. And we’re now in San Francisco. Life!

A lot has happened in a little under a year. Got a full time job, bought a car, bought a house, renovated said house, sold house, sold car, left full time job, and moved across the country. And that’s why I haven’t posted much on the blog, we decided to fit an entire lifetime of experiences in less than a year.

In other news, if anyone is looking for a full time Designer in San Francisco, I’ll be here if you need me.

Finally, I’ve decided to write a post dedicated to my continued exploration into game development, specifically with Unity. Starting in January 2013 I joined the website OneGameAMonth.com. My goal was to make something new every month (which seems somewhat obvious from the name of the site). To get better at game design and development, I needed to make more games. Although I have created or been involved with game creation in the past, it was limited. I need to create more. To fail more. To be able to just play.

One month is not a tremendous amount of time when one has a day job and responsibilities; in any given month I generally only have a day or two of good work time. So the games I make are not terribly complete. They tend to be more akin to demos and proof of concepts. Though, before pushing something out, I try to make sure it at least have some form of beginning, middle, and end. This usually amounts to an intro screen, the gameplay / mechanic test, then some form of end screen.

So here is my current list of games, a mix of my One Game a Month games and Ludum Dare (48 or 72 hour game jam) games. Further in depth explanation will probably come later (if at all, with my current blog post track record it could be a while before my next entry).

For each game, you can click the image that will link you to a page where you can play each game (using the Unity3D web player plugin).

2.5D Megaman Type Game (Made for LD23 in 48 hours)

Controls : wasd / arrow keys for movement with mouse click for firing your gun (intro menu requires you to use your mouse to click a planet)

Gem Drop – 2D gem collection game (One Game a Month – January – Made in 6 hours)

Controls : Left and Right arrows or A + D keys to move / collect gems

Proxy-Drone 3D shmup (One Game a Month – February)

Controls : AWSD to move – SPACE to fire, Upgrade Menu requires Mouse

Mungeon 2.5D Minimalist Rogue-like (Ludum Dare 26 (72 hours) & One Game a Month – April)

Controls : AWSD to move – SPACE to attack

Each game tends to have a more than its fair share of bugs. As much as I would like to continuously spend time improving and iterating, my goal with these wasn’t to have perfect full games, but rather to have small quick experiences. I wanted to experiment with different genres and have the experience of working through the problems presented with each new game type and actually think through and confront the issues.

The goal was to learn through creation.