Lanny McNie

As the dev mgr, Lanny oversees the technical day-to-day details of production and makes sure things get out the door.

@astrostyle

The Dragon Age ISS

In 2014, we worked with BioWare to create the ISS: an interactive, animated cinematic of a player’s history in the first two games of the Dragon Age series, narrated by one of the characters, Varric.

When we first met with BioWare’s online team to discuss the Interactive Story Summary, we were floored. It’s always a privilege to work with one of the best game development companies in the world, and the ISS presented a challenge that was perfectly suited with some of the tech we have been focused on for the last few years. The goal of the ISS is to summarize the complex narrative and decisions that players have made in previous games in the series, and give them control of those choices leading into their latest chapter, Dragon Age: Inquisition.

Continue reading →

Game Design and Life

I spend a lot of time thinking about video games, from concept to completion and then some. Whether making, playing or being involved with the community, there are a few things I have noticed that I’d like to share.

Game design is equal parts organic and structure, but the more time I spend with both the process and the end product, the more I realize that there are hidden, underlying core values in game design that closely resemble the six human needs. The more of these values/needs the game hits, the subjectively “better” the game is.

Continue reading →

Check. Check. Is this thing on?

It’s been nearly a full year since I last blogged. (Do people still blog? Maybe I should snapchat this instead?) I used to blog a lot, but life became busier, posts became more infrequent, and eventually it stopped being a habit and became a chore.

That doesn’t mean I don’t have a lot to say. It’s just that the last few years have been a crazy and exciting ride, and I haven’t had a lot of time to dedicate to writing posts.

Five years ago, Flash as a platform died. For a lot of shops, the migration was gradual. Not for us. Our clients come to us for cutting-edge tech, and almost overnight, Flash didn’t meet their criteria. We went from almost 100% Flash work, to nearly 0% in less than a year.
Continue reading →

Bardbarian on Steam – coming soon

Thanks to everyone that has played and supported Bardbarian so far! It has been amazing to see what the Treefortress guys have come up with, and we couldn’t be more thrilled with the result.

An update has been posted on the Steam Community about what players can expect from Bardbarian once it arrives. Check it out, and be sure to leave your thoughts.

Bardbarian

If you haven’t checked out Bardbarian on iOS, yet – you can download it in the app store. Keep an eye here, or on the Treefortress blog for more Bard-related announcements in the coming months.

New dev update for Bardbarian!

null

Over at TreeFortress we’ve put together a massive dev update for our upcoming game Bardbarian. To read all about it, check out the TreeFortress blog!

If you’re not familiar, Bardbarian is an iOS/Android game, built with Adobe AIR and the Starling Framework, and is slated for a Spring/Summer release in 2013. TreeFortress is a seperate division of gskinner, focused solely on creating our own apps and games. Follow them directly if you’re interested!

Pirates Love Daisies HTML5 Game Launches!

I’m extremely excited to announce the launch of one of our recent projects: Pirates Love Daisies!

Microsoft approached us a few months ago and asked to work with us to build a best of breed tower defense game in Javascript and HTML5. I was a bit hesitant at first – it’s been quite awhile since I worked with JS and HTML in any great depth, and most of my memories were of fighting browser incompatibilities and cursing the lack of decent developer tools. However, we did some quick code spikes to get a feel for what was possible and decided that this was a great opportunity to gain some applied experience with a new technology while working on a fun project.

Concept

We teamed up with local illustration group Pulp Studios and started brainstorming ideas for the theme of the game. Fairly early on we latched on to the idea of pirates (I mean really, who doesn’t like pirates!), but we needed something for them to defend. We considered going with the typical tower defense model, and simply have the user prevent creeps (enemies) from getting from point A to point B, but I’ve never liked that narrative. What exactly is at point B that’s so important?

We decided that the creeps were out to steal something valuable from the pirates, but we weren’t sure what that should be. Gold was an obvious choice, but it was boring, and it made more sense as the currency for purchasing units and upgrades. Then it hit us… Daisies!

Pirates Love Daisies, Art by Pulp Studios

Why daisies? Because Pirates Love Daisies, of course. The fact that daisies are visually iconic, seemed to be appropriately fun and quirky, and would work well aesthetically may have factored in as well.

With the illustrators working on sketches, we got down to writing code.

Coding

We started out by building core game logic, and a simple library to manage canvas state. We profiled performance, then revisited some of our initial ideas to work with the limitations we found.

Overall, we found working with JS to be a lot easier than we expected. Picking up the language was a breeze, and we were able to apply the processes and approaches we’ve developed from years of working on interactive content with Flash. For me, working with Javascript again actually had a certain pleasant nostalgia to it, as it recalled the days working with ActionScript 1. There is a certain amount of fun and freedom afforded by a dynamic scripting language, though the lack of strict typing, compiler time errors, and language-level support for inheritance (ie. no super keyword) were frustrating but manageable.

We also ran into some browser incompatibilities, though far fewer than we initially feared. The worst of them revolved around audio. It seems that every browser has its own set of irritating quirks related to dynamic audio that we had to stumble our way through. We wound up building an audio manager to resolve these issues that we may clean up and share in the future.

All round, things went fairly smoothly from a coding perspective. We ran into some challenges and had to make some compromises, but we surmounted all the major obstacles and learned a ton.

Pirates Love Daisies

Performance

Overall, I was really impressed by the performance we were able to obtain. Code execution speeds are fairly similar to AS3 (which is impressive if you consider all the extra type data the AS3 JIT has to work with), and graphics performance is, for the most part, reasonable.

IE9 was the big stand out on graphics performance – its GPU-enabled engine is smoking fast, especially with large bitmaps. Interestingly, we found that iOS had terrible performance (when it worked at all) – something like 4-5x slower than Android on comparable hardware.

One other thing we found that’s worth noting is that drop shadows are ridiculously slow in canvas. A few small drop shadows rendered to canvas could drop our framerate in half.

HTML5 Features

HTML5 is actually a collection of standards at different levels of completion, so while it’s easy to refer to this as an HTML5 game, it really just leverages a few of the new features that are included under that umbrella.

Specifically, we used canvas for drawing the game board (terrain, units, creeps, effects, etc), local storage to save local scores, the audio element for all of the sound, and embedded fonts throughout.

Tools and Libraries

One of the challenges we encountered was the lack of good tools. For JS development, we tried a few different options but ultimately settled on Dreamweaver – it’s not a fantastic JS code editor, but it’s decent, cross-platform, and everyone in the office already had it.

The game art was created in Illustrator, then animated in Flash Pro. We built a custom AIR tool for exporting SWF animations to a sprite sheet (a grid of animation frames) which helped out tremendously. We also built a super simple AIR app that preps our JS files, runs level 1 of the google compiler on them, and then runs the result through the YUI compressor. We’re hoping to release both of these apps in the new year, once we have a chance to clean them up.

For testing and debugging, we used the debug tools in every major browser. Roughly half our developers were on Macs using Safari and Chrome, and the other half were using Windows with IE9 and Firefox. This let us spot cross browser issues early on. We also found different problems were more easily solved with different browser’s dev/debug tools.

In our code, we leveraged JQuery, JSON, and a new library we developed called Easel. The Easel library provides a hierarchical display list, similar to the one in AS3, that makes it much easier to work with the canvas element. We released the alpha version of Easel today at EaselJS.com under the MIT license. It should make it much easier for both Flash and JS developers to get started using canvas.

Gameplay

When building a game it’s essential that you don’t underestimate the huge amount of time required to balance gameplay. Our level designer built spreadsheets, graphs, and formula to help model the characteristics of the units, creeps, and maps, but it took hundreds of plays through the game (a sacrifice, to be sure) to get the balance right.

We tried hard to make the game very approachable, with a short tutorial, and easy start, but also layer lots of strategy into it for the more experienced gamer. Our scoring system involves lots of trade-offs. As an example, you get points for defeating creeps and ending waves faster, but you also get points each wave for hoarding gold. You have to decide how to balance these two opposed reward systems.

It was only when, having opened PLD to test some specific feature, I caught myself in my third game trying to beat another developer’s high score (and getting yelled at by my wonderfully patient wife) that I really started to feel like everything was coming together. If you can completely lose track of time while playing your own game, after being immersed in planning, designing, and coding it for a couple months, I think that’s probably a good sign… though it can have a negative impact on office productivity.

PLD-game

Overall

Microsoft was a fantastic client. After suggesting the tower defense genre, they trusted us with all the technical and creative details to make the project a success, while offering great feedback throughout. They put a lot of faith in a company that’s really not known for Javascript or game development, and I’d like to believe it was well placed.

I never thought I’d say this, but Internet Explorer 9 actually looks to be a great browser. It has impressive performance, and seems to be very standards compliant. I would definitely recommend checking it out, you might be surprised.

Everyone involved with the project had a huge amount of fun building it out. We had a great time brainstorming ideas, coming up with ways to tweak gameplay, and spending (way too much) time play testing. We’d love to hear what you think of the game in the comments below.