Tags

11.08.2013

I recently received my GameStick. Interesting little device... I backed it around the same time I backed the Ouya. The idea is having a game system available to you at all times. The console itself fits inside the controller making for easy transportation.

You also need to power the system, so you need to plug it into a USB port. Most TVs have this but the power draw of the GameStick is juust enough to cause problems. Ultimately it is best to plug it into the wall, which means you need to also carry a longer USB cable and wall port with you. Not exactly the most portable device.

Still, I was willing to let that slide as long as the controller felt good. And it does! The moment I felt the analog sticks I was in love. Great texture, nice amount of resistance and large range of motion. Unfortunately, it seems the sensitivity of these sticks is terrible.

The actual range of motion that registers movement is about half the full range of motion. So if I move a stick to the left halfway, I'm already at the max magnitude (1.0) for that stick. It feels bad. I'm not sure this is something that can be fixed in software... it may be a limitation of the hardware.

I took a screenshot to illustrate the problem:

What you're looking at is a quick program I wrote to record raw data from the left stick. I spun the stick in a circle a few times for both the GameStick controller and an Xbox 360 controller. The red circle represents the physical path the stick traveled.

Notice how even the 360 controller isn't free of artifacts -- it flattens out on the top, bottom, left, and right which isn't ideal but isn't terribly noticeable because the usable range of the stick is close to 100%.

The GameStick picture tells a very different story. Since the physical range of motion differs greatly from the data you get a square response. I tried to do some correction for this but wasn't happy with the results. You can make it work but... it really isn't ideal.

What all this means is the GameStick controller is going to perform poorly for games that require precision, such as an FPS or flight sim. You really only have two states: barely tilting the stick and fully tilting the stick. The range in-between is nonexistent.

I hope someone can prove me wrong... I had high hopes for this gamepad. It really does feel good in the hands.

6.17.2013

I am super excited about the Oculus Rift. It is a Head Mounted Display (HMD) which can accurately track rotation of your head. What does this mean? Virtual freakin' Reality!

My friend Danny rocking the Oculus Rift and Razer Hydra

My devkit arrived in April and I've had a few months to tinker with it. I really wasn't sure what to expect, but it wasn't this. Immediately I was blown away by how well the device transported me into the game world. It really is amazing tech, and everyone I've had test it out agrees.

Gaming is entering a strange era, and players are looking for something new to amaze them. I don't think the next-gen consoles will fill that want. Something like the Oculus Rift could really take the gaming scene by storm.

Expect more Rift observations and experiments. The Malchemist Lab is just getting warmed up!

5.14.2013

It has been back burning for a while but it is a hard thing to come to terms with. Time for a brief history lesson! Nebulous started as a blank slate. It is Malchemist's first project and we built the engine from the ground up, starting with math libraries and feeble OpenGL classes. Over time our engine matured and actually became fun to play with.

Now, the initial idea for Nebulous was a procedurally generated 3D tower climb. Early on after some pondering and technical consideration, we decided against procedural generation in favor of lovingly hand-crafted levels. Rather than make an in-game 3D level editor we opted to leverage an already existing moddable solution — Blender. This may have been our downfall.

Having a powerful 3D tool like Blender at our disposal colored the expectation of our work. We knew what Blender was capable of and tended to aim for level design above our modeling skill. We had to teach ourselves Blender and the amateur quality shows in all of the levels. I'm not hating on our design — the levels we actually finished are fun — but I simply state the obvious that we are not very good at 3D modeling.

This constant discrepancy between expectation and result wore on us until level design advanced at a crawl. The last six months or so of development went by at a painful pace. We could have contracted outside help, but the level creation process is complex and undocumented. It would have taken considerable effort to bring someone up to speed with the eccentricities of the engine. Eventually we decided to take a break from the project.

Ultimately I think having an in-game level editor may have forced our design to be simpler and not have slowed us as much. Taking inspiration from games such as Little Big Planet or Sound Shapes, I think building levels with an in-game tool can clarify design and add value for the player.

What Went Right

The engine. We learned an incredible amount about how a game engine should operate by starting from scratch. I'm not sure we will use it moving forward but it will allow us to examine other engines with a more critical eye.

Level design. Designing our own levels has had a lasting impact on how we view level design. It is impossible for me to play a game without analyzing the level design, particularly sections aimed and teaching the player. This is something that will stick with us.

Camaraderie. As a duo we lasted longer than we could have individually. We were able to keep the torch burning during dips in motivation.

Management tools. We used Mercurial for source control and Redmine for issue tracking. Despite a small learning curve, both tools served us extremely well and we were able to collaborate effectively as a team.

Style. Early on we decided to go with procedurally generated textures. This meant that rather than draw each material (which we suck at) we define each material as beautiful maths (which we are pretty good at). Combined with a pseudo-cell-shading outline technique we achieved a look that is unique and not too revolting. We decided against doing some more fancy techniques like bump mapping in order to further separate the style from modern render pipelines.

The IGF. While the IGF gave us zero usable feedback, it essentially was a $100 Hard Deadline for us. We went into overdrive the last few weeks before the submission date and polished Nebulous more than we would have otherwise.

Bullet physics. We tweaked the physics heavily to implement the grappling hook and spikes. Bullet ended up accommodating us well. This tech alone was responsible for much of the feel of the game. It's documentation isn't the best but the code is readable and understandable.

What Went Wrong

The engine. While crafting our own engine was educational, I'm not sure we will reuse it. Porting to Mac was extremely hard because we did not have hardware to test it on. Also, shader and other OpenGL related errors plagued us throughout the process stemming from weaker cards and hardware we don't own.

Level design. We are not 3D modelers and this slowed us considerably. An in-game editor likely would have helped as it would have simplified the building blocks we construct the world from. We could have focused more on gameplay elements rather than modeling proficiency.

Secrecy. We held ourselves to high standards and only showed work to the public on a few occasions. We got motivational boosts when people played the game and the response was generally positive, we just didn't do it often. Some social pressure could have helped.

Design creep. We call it "wouldn't it be cool if" syndrome. While I don't think there is a ton of cruft in Nebulous, we could have prioritized features better to get a fun, playable game faster. It was easy to slip into doing technically difficult things like high scores board, engine optimizations, etc. These are good to have but don't change the fundamental enjoyment of the game.

Lack of deadlines. The IGF rush made us realize how important it is to have some kind of deadline to work toward. Through most of the project we were of the "it'll take as long as it takes" mentality with getting stuff perfect. The problem with this is you get diminishing returns perfecting certain features. I have no doubt we wasted a lot of time on things the player will never notice.

Inadequate funding. Development time exceeded the initial estimate (of course) and eventually our financial situation was putting strain on those around us. This is not an easy mental state to be in and got worse the longer it lasted.

Sparse playtesting. We had a decent list of people interested in the game but didn't manage testing well. Getting feedback during development might help us realize which problems are most evident to players so we can better focus our time.

In the end we are happy with how the engine feels but don't have levels to back it up. I believe Nebulous will see the light of day in one form or another. The control of the player feels too good to pass up. I hate structuring this post as a post-mortem because I really don't think Nebulous is dead. Still, it is not being actively developed and we need to give closure to the project.

7.30.2012

4.22.2012

I've been working on a few administration tasks (warning: technical post :P)

We rent out a virtualized box from the kind people over at prgmr. We abused it for all of Malchemist's needs -- revision control, forums, high scores, blog, etc. It hit me that it would really, really suck for that box to go down and take out all those services, or even worse for the box to be compromised through one of those many attack vectors.

I moved our main website (malchemistgames.com) to Blogger, which was surprisingly painless. I even got it looking 98% the same as before! I know we lose a bit by giving control to Google, but we should be able to scale to traffic better and I'm not as worried about our old blog software getting hacked.

I moved nebulous-game.com to Google AppEngine since it is static HTML with a few forms. Again, this was mostly to help us with scale as well as reduce possible attacks on our prgmr box.

Our forum software is currently running on Amazon's cloud service (EC2) which gives you an easily deployable virtualized box.

It's too early to give a solid opinion on whether the change was worth it, but I can definitely sleep easier at night know our services are off of our single box. Both AppEngine and Amazon aren't costing us a dime right now with so little traffic. A huge spike in traffic will definitely cost us, but I think it will be money well spent for people to see our game rather than a dead page.

If anyone would like more info about the conversion process, don't hesitate to give me a shout :)