Archives For gamedev

GBJAM Post-Mortem: Void-Dogs

October 17, 2016 — Leave a comment

void-dogs-ss

Last week I took part in the fifth GBJAM. A popular game jam that pays homage to Game Boy games but allows for modern sensibilities to creep in. Initially I had no plans to take part but a developer on the newly formed Icelandic Gaming Industry Slack mentioned it. Soon I and a handful of others decided to join in. The basic format gives you ten days to make a game. There are two significant constraints, a four color palette and a ‘pixel resolution’ restriction of 160×144. After the ten days are up competitors then rate one another’s games.

In the end I spent around 16 hours making Void-Dogs and finished in 82nd place out of 402 entries which I’m pretty pleased with!

Motivation

I’ve been working pretty much continuously for 12 years making games and playful things. My emotional makeup is such that I really invest in the thing I’m making at any one time so I find it hard to juggle multiple creative projects at once. I don’t have the headspace for it. As such I’ve found it hard to work on sideprojects. I’ve made things during both my recent paternity leaves as good contiguous blocks of “free” time. Development time was “luckily provided” thanks to Autodesk laying a bunch of us off in August. Since then I’ve been working for two hours a day on a small game called What Now Earthman?. But that is still a big project I won’t complete for the foreseeable future. So I was already motivated to make something smaller in scope. The GBJAM popped up as a good enough answer.

Development

Void-Dogs took sixteen hours in total to finish. I started a day late but I don’t think that made any real difference. I started off working two hours per day but eventually did a little more from Wednesday onwards. In general it was quite a relaxed affair tucked around child care. Void-Dogs was made in Unity which is probably my favourite engine for making a myriad of games and prototypes quickly. I task tracked with lists on graph paper. I wrote all the code and made all the art and SFX by myself but found some Creative Commons music to use as a soundtrack. My main source of inspiration was the game Space Harrier but I wanted something that involved a little less spraying bullets directly forward. After a bit of brainstorming I came up with the concept of “skydiving in space” and went off to work! You can download and play the result here.

The most interesting technical challenge was creating the sense of depth and motion with a limited resolution. In the end I actually opted to use a perspective camera and Unity’s particle system to create some ‘dust’ that gives the impression of hurtling through space. Another important addition was the use of a ‘sine wave’ shake script I wrote some time ago. I initially intended it for cameras but it works just as well applied to other objects and captures that never still motion of a skydiver falling at terminal velocity, not realistic but it feels good.

spaaaaace

All the asteroids and players are positioned in 3D space with one unit equal to one pixel. This let me simply calculate the depth into the camera where I would get pixel perfect rendering. I initially tried rendering the sprites moving through space directly but the resolution makes for ugly pixel artifacts as sprite pixels pop in and out across real pixel boundaries. This wasn’t an unexpected problem, it’s part of the reason you see games like Space Harrier do 3D by changing sprite sizes (also hardware optimised sprite rendering). Moving to this approach required a bunch of labor to make art assets but is much better visually and thematically. In the end all the sprites sit on the ‘focal plane’ and are represented by colliders and transforms moving through 3D space. I then switch sprite depending on depth and reposition the sprite correctly on the focal plane to simulate the perspective of the camera. Everything is then snapped to the nearest pixel to allow for fluid motion without pixel artifacts.

behindthescenes

Unlike the above image the colliders actually ended up being boxes and pushed back behind the sprite. It seems obvious in hindsight but it felt all sorts of wrong with the collision as it was above. The inner collider is for the asteroid itself and the outer collider is the zone for the proximity bonus.

spaaaaaced-day2

What went well?

Art

My art drew a lot of positive comment and was a reasonably highly scored feature of the game placing 54th in that category. As someone who only started making game art again when I went on paternity leave this felt pretty good. Even more so as I hadn’t made any pixel art or pixel art animations for games before. A lot of this I credit to time spent sitting down cranking out bad vector art for What Now Earthman? it’s getting better but I learnt a lot in the three months I’ve been drawing semi-regularly. I’ve got a much stronger understanding of color theory, shading and other basics than I ever did before. On top of which I learnt that good art takes time (duh!) and not to try to rush through making something. Even a game as simple as Void-Dogs contains a surprising amount of art and it took perhaps half my development time to make it all. Including remaking art for the Itch.io page.

Gameplay

I ended up with my highest placement ranked 48th for the gameplay. I’m pretty pleased with the gameplay mechanics I added and how they work together. There are three essential layers. First the asteroids arriving in patterns forcing the player to dodge through waves of obstacles. Second the player scores more points for flying in proximity to the asteroids adding a risk-reward mechanic for people that find the dodging gameplay simple adding a layer of mastery. Third other divers will arrive next to you and fight for a short amount of time, the only means of killing them is to hit them with a laser bolt that stuns them and have the splat into an asteroid. This sets up a complex timing problem for the player to solve whilst dodging asteroids and incoming laser fire. These were strong fundamentals to build a fun game on and the feedback I’ve received seems to agree.

spaaaaace-day4

The AI itself is a simple steering behavior that has a target, avoids the player and asteroids then occasionally fires towards the player. It’s surprisingly good at hitting you!

Scope

I carefully managed my scope throughout the project. Mostly in the classic manner of frontloading the risky items I hadn’t done before. I also kept a Kanbanish working list also meant I could rearrange and remove tasks easily as I went along. I pretty comfortably worked through to the weekend when the days are taken up by looking after a boisterous three year old and two month old! Then I managed to snatch enough time to pull things together and enter my submission with quite a bit of time to spare even if it wasn’t time I couldn’t use on my entry!

Architecture

Architecture in a jam game? I saved a whole heap of time by doing simple things like separating the component implementing the actions of the diver from the component that controls how those actions are used. Both the player and the AI use the same actions. Similarly the components for sprite scaling and screen positioning were written to be easily shared and meant it was trivial to add in scaling for the enemy entering the game. I have a simple Events system I wrote for WNE that drives a lot of the UI update and game flow between objects that should be decoupled as much as possible. All my bullets and asteroids live in object pools local to where they are used and are drawn from them as needed. Finally the stage design is done within a coroutine and a library of helper functions so it looks a little like this:

Bullseye();
Grid();
yield return new WaitForSeconds(2.0f);
Cross();
yield return new WaitForSeconds(2.0f);
Bullseye();
XThru();
yield return new WaitForSeconds(2.0f);
Grid();
yield return new WaitForSeconds(4.0f);

//fight
AIEnter();
yield return new WaitForSeconds(2.0f);
BigSpiral();
yield return new WaitForSeconds(16.0f);

I’d attribute finishing this game at all to keeping on top of the code design as I went. Then hacking madly at the end! But keeping things neat made the hacks easier to implement.

What went badly?

Audio

I’ve done precious little audio work and it really shows in Void-Dogs. My two lowest ratings were for Sound (#100) and Gameboy Feel (#177). My music selection was a big contributor to the latter, it was the best Creative Commons licensed track I could find which didn’t really suit the Game Boy era and slightly bends the rules on Audio as it wasn’t an asset made for the jam. SFX were made using BFXR and whilst I think they are serviceable as placeholders they don’t really hold together or excite. I think rather than taking on yet another task were I to do this again I’d try to pair up with someone that knows what they are doing. Although I’m trying to get a basic handle on how to make better SFX and where to even start with music just to understand the processes.

Stage Design

I was pretty sure at the start of the jam that I wanted to have hand crafted stages rather than trying to create a procedural generation algorithm in such a short space of time. In the end I only had time to make one stage and iterate on it a little bit after some playtest feedback. Finding fun sequences and building them out whilst also trying to deal with the problems with perspective and the screen getting messy was really challenging! To be frank the result is a mish-mash of ideas in a steady progression punctuated with ‘clone’ fights. One of my biggest missed opportunities was not front loading a clone fight. I think many people probably played the game without reaching the first one! My goal was to have a series of escalating stages that lead the player in but this wasn’t really realised.

Scope

Could I have done better in the time I had? Perhaps? I look back through my notes trying to find places I wasted time and it’s really hard to say. I think I could have picked either the obstacle dodging or the clone fighting as the focus and doing both was perhaps unnecessary for a jam. Though I do think they compliment one another and was keen to push outside of the shooter norms. Mostly I think I wish I had more free time to put into it or had planned on taking part and done some prep work.

The single biggest thing I didn’t budget time for was setting up the Itch.io page which took a lot longer than I thought. Presentation matters in terms of first impressions and to get eyes on your game. Annoyingly the Jam entry page misses most of the instructions and theming which was an issue as I’d included the instructions on the site proper. Hopefully most people clicked through to give it a read but players didn’t have too.

Lessons for future Jams?

This was fun and I’d like to do it again when I have some free time, in particular I think the constraints made for a really fun jam format. The biggest takeaway I have is to team up with other people to cover the bits I’m rubbish at. I’d also like to try my hand at just working on the art and design whilst leaving the lion’s share of the programming to someone else. I like the art process, it’s not what I do in my day job and jams feel like a good venue to practice. Then the usual things for game development in general were really validated for me; have a small scope, make something you know how to do, get the game up and running quickly, playtest and iterate.

In Game Design, Game Development, Game Jam, Prototyping , , , , ,
permalink

The (Bloody Awful) Art of Estimation

September 9, 2014 — Leave a comment

The entire point of Agile is to maintain flexibility in order to deal with the uncertainty inherent in developing software products. To fully display my biases this goes doubly-so for creating videogames as we’re attempting to hit much more nebulous targets like ‘fun’. Planning is still a necessity for most businesses but rigidly sticking to a plan is not. It’s embodied as this value in the Agile manifesto.

Responding to change over following a plan.

If we’re planning we need to be estimating but we know from research that humans are completely bloody awful at it when there are high degrees of uncertainty involved. We cannot see the future and are kidding ourselves if we think we can. In my experience discussions about estimation tend to go in one of two directions. We have the empiricists or Reality Deniers and the #noestimates crowd or the Oblivious Snowflakes. Broadly speaking the first group think numbers have the answer and the second group is in a really unique situation where they don’t really need to do much if any long-term planning for development.

Denial, something, something, something… river in Egypt.

The Reality Deniers take comfort in models and using data from ‘experimentation’ to generate predictions about the future. There are two problems here; context and the applicability of the model chosen. Context is the game development empiricists Achilles heel. If I run three miles several times a week following the same path in sunny LA does the average of my times translate over to how well I’ll run a mountain marathon in really bad weather? No, very obviously not. Newton’s Laws of Motion don’t apply on the really small-scale and the really-big scale but they do work pretty damn well at the scale the experiments to determine them were conducted at. If you want to use experimental data to create models to predict the future you better be damn sure your context is not about to change under your feet. Which, being videogames development it almost assuredly will.

The second problem is the model. As most people use Scrum and Scrum is about tracking velocity almost all future estimates just linearly extrapolate velocity. The problem is not necessarily that this is wrong just that it’s incredibly unlikely to be right. All sorts of things speed-up and slow-down teams and change the way people estimate for an average to be tracking consistently. Further the velocity of a team coming to the end of a project is going to be very different to one starting off. Primarily because the level of certainty and knowledge about the project increases greatly as it nears completion. Small errors in estimation accumulate into big errors over a long period of time and you can’t really be sure that everything has actually been estimated (we’re going to iterate a lot right?). Anyone who has had to write any multiplayer code knows that extrapolating linearly in the presence of even small accelerations is doomed to give you wildly diverging results.

Combine the two together and I don’t think we even need to look at problems with the experiment setup. We want to estimate an uncertain process, with data from a different context using an overly simplistic model, even dressing up in our +10 Robes of Technomancy this seems stupid. Science is rigorous, this approach is not.

#noestimates4lyfe

At the other end of the spectrum is the idea that we don’t need any estimates. I called these guys the Oblivious Snowflakes because their position is often unique and they don’t seem to realise it. I actually have a lot of sympathy for this position as it sounds dreamy and has less of a bad accountancy vibe. #noestimates is the idea of continuously shipping a product taken to the next level. These snowflakes aren’t iterating once a month or once a week they’re iterating once an hour and pushing the results out live. Of course you don’t need to estimate anything if you have already shipped a product and are able to work on it blisteringly fast. Well, in the short-term at least until someone with a tiny bit more vision and urrm… planning comes and knocks your product off it’s perch. Sadly for most of us a system of continuous delivery is a very long way from reality and most games require a lot more effort to create a viable product than a web application.

Reality Check

We’re agile… or at least supposed to be. The answer to this tricky conundrum of what to do with longer-term project planning in the face of a fog of uncertainty is damn well written down.

Individuals and interactions over processes and tools.

Customer collaboration over contract negotiation.

In this instance the customer is not the end-user they are the person paying you to make the game. It could be an investor, the representative of a publisher or your executive producer it doesn’t really matter. What they want is assurance that you’re not full of shit and they’d like this signed, in triplicate, in blood with a firm deadline upfront based on any plan you have. This is a risk mitigation strategy for them and your job is to deftly dodge the contract deadline hammer and convince them to work closely with you on a very regular basis to better mitigate the risks involved in development. However we’ll still need a plan but this is not a plan that can be captured in a contract. It must by necessity be iterated on as development continues and new things are learnt. As we progress towards completing a project our plan will become more certain. It also means that we can early out and still do something else if, despite our best efforts, the project is not meeting expectations. Both parties need to embrace the reality of the uncertainty inherent in the beginning of a project and keep plans vague and the uncertainty in them spelled out clearly.

As the project progresses the plan should be routinely revised and the teams developing the game should be meeting and discussing the game regularly with the customer. At a high level a healthy project should see a downward trend in uncertainty over time. Employing schemes like the development lifecycle can be a good way of tracking progress an deal with uncertainty upfront. In short building the project plan is no different to building the product and the people working on it a virtuous cycle of iteration, feedback and adjustment.

Detailed Estimates Are Still Useful

For teams iteration planning there is nothing better than a old fashioned application of numbers. We want to work at a sustainable pace and the only way to do so is to avoid over-committing to the work we are going to do in an iteration. This is why we should prefer shorter iterations. It’s much easier to estimate and plan one weeks worth of work than it is four weeks and we avoid compound error causing massive deviations in our plan. It’s also much easier to estimate the work we are just about to do because we know a lot more about it than it is to think about the consequences of the consequences of that work in a months time. This is also the point that it makes sense to capture uncertainty in the actual task estimate rather than keeping it as a separate concern. Essentially estimates should be a combination of task size and how sure we are that our size estimate is correct. We then drop tasks into buckets and using recent historical data for the team plus a bit of intuition to bring stories into an iteration such that we don’t over commit to the number of ‘buckets’ we got done before.

In Agile, Game Development , , , , , ,
permalink

The Agile Principles of Game Design/Development

July 1, 2014 — 3 Comments

Let’s face it the Agile Manifesto is very Software Engineer focused. I’m not sure it’s meant to be but it’s a consequence of the background of the people that wrote it. The principles also explain what but not really why or how the principles directly interact with the manifesto values. It’s also a bit hard to frame in your own context sometimes. This is a bit of an experiment in re-drafting the principles to make sense for game design/development. I’ll highlight the changes I make in bold. The original Agile Manifesto which can be found here.

First the values themselves:

We are uncovering better ways of developing games by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Playable games over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The first thing to read is the very last sentence. Lots of people read the manifesto and assume that there should be no process and no documentation. The point of the manifesto is that those things are necessary to a degree but should not be the focus as they have a tendency to take over and work against the primary goal of making a particular product.

Why a playable game rather than comprehensive documentation? What about the Design Treatment, the Preliminary Design, the Final Design and all the other ancillary documentation you might produce? The simple fact is that the value of an idea for a game is much better expressed as a game that you can play rather than abstracted into a document. A document is open to interpretation in a manner that an actual demonstrable game isn’t which means that two people can have wildly different ideas about how the end product might turn out without either of them actually being wrong. A design expressed as documentation and a tangible, playable product is there to be critiqued much more directly with far less ambiguity. Further generating comprehensive documentation rather than a product is a big waste of time as we know that we will be making changes as we go along and a big list of things to implement before the game is ‘finished’ often delays critical iteration.

I re-phrased the Agile Principles as:

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience. This provides us with the best and most direct feedback so as to shape out product direction. It also means our game is continuously in a shippable state. The value of a game is captured in the quality of the experience.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Late changes are a reality of the business.
  3. Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Autonomy, mastery and purpose are the key motivators.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. A playable game is the primary measure of progress. We are making a game, if the game is not changing we are not working on it. A feature designed on paper is not a feature that is playable.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The principles were not originally numbered but I’ve done so to keep the discussion brief, it’s not a statement on which of the principles are more important than the others. Never the less there are a few of the principles that are good to call out in groups.

  • Process Improvement: Twelve represents the engine of process improvement within the agile framework, it’s taking an iterative and evidence based approach to improving the working practices of a team with the rest of the principles representing the yardstick by which to measure them.
  • Game Improvement: Seven details the key indicator of progress. The state of the game itself. Combined with Three and One it provides the engine for evaluating and iterating on the game.
  • The Team: Five and Eleven detail who the team is and how they should be managed.
  • Mindset: Eight, Nine and Ten frame the mindset required to work with an agile process with One as the goal.
  • Working Practices: Two, Four and Six detail important working practices that are part of the reality of working on commercial products with many people.

The entire point of the Agile Manifesto is to define a new way of working that is customer focused, iterative and concentrates on making the best product possible by empowering the people that make it. Hopefully this re-write clarifies how this approach fits game design/development and gives people a good starting point for defining their own processes.

In Agile, Game Design, Game Development , , , , , , , ,
permalink

The Value of Prototyping

March 8, 2014 — Leave a comment

I was speaking about prototyping at a conference in Finland and got asked a question that left me fumbling for an answer.

“How much of my budget should I spend on prototyping?”

I’m insulated from budgets at work and don’t consider them at home. My pretty lame answer to being put-on-the-spot was that I didn’t really know and that I personally consider prototyping an incredibly important part of making anything so I would earmark a lot of budget towards it. It’s a pretty bad answer in hindsight because the most expensive parts of game development by far are content creation and marketing. Trying to place a dollar value on something like prototyping is hard as the value added is mostly a reduction in project risk. Asking “how much time and therefore money did we save by not doing something?” is equivalent to “how long is a piece of string?”

To me the value of prototyping is two-fold.

Value to the Individual

In games we’re seeking a to produce experiences that elicit emotions, the most common being enjoyment of something fun. There is no real way of knowing in advance if a game idea is fun or not or if its something you really want to make. Making videogames is an act of creation and it is a craft. Other acts of creation follow a similar pattern. Writers need to write a lot to get good at writing. Painters need to paint a lot to get good at painting. You need to knit a lot to get good at knitting. To get good at making videogames you need to make a lot of videogames. The more you explore and make things the better refined your process and skills become. You also gain a great deal of knowledge and experience which you can use as future shortcuts. Prototyping is essentially the act of making the core game experience or a feature as quickly as possible to see if it’s good or not. It follows that prototyping lots of small games, systems and other ideas is a great way to get better at making games.

Having a large portfolio of prototypes is also a great way of demonstrating a variety of skills to potential employers.

Value to the Business

As I said above the main business value of prototyping is a reduction in project risk. Early post-Waterfall methodologies noticed this for example Boehm’s Spiral Model. It’s should be pretty clear to most people that the first version of pretty much anything is terrible in at least one aspect. In the Spiral Model development doesn’t move through a series of stages ala Waterfall but in a series of iterations that result in a series of prototypes before the product is finally put into production. It recognizes that we can’t effectively reason about an idea without a concrete implementation. Project risk can be mitigated with prototyping in a few ways:

  • “Fail fast” – Today’s trendy business phrase. But as above there is real value in realizing early that you shouldn’t do something and not wasting resources chasing it in a heavyweight fashion until your realize it is unworkable or rubbish.
  • Improving communication – Ever sat in a meeting room to discuss a design document and found you spent the entire meeting squaring away different interpretations of the doc? Text is a horrible way to communicate ideas about a game which is a complex, interactive, aural and visual experience. You can see this in the drift as a younger generation rely on Let’s Play videos more than traditional journalism to make purchasing decisions. Simply watching someone play the game tells you more about it than the reviewers opinion of the experience put into print. The same is true for prototypes, they give a concrete entity for demonstration, reasoning and discussion.
  • Expose unknowns – Upfront design has long been fraught if you only have a muddy picture of your requirements. Nothing can get much muddier than games where the game at the end can often bear little resemblance to the initial idea. Prototyping at least gives you some insight into what the unknowns will be.
  • Avoiding “Sunk Cost” – Avoiding the sunk cost fallacy is at its heart not “throwing good money, after bad” or better still knowing when to kill a project despite having a large amount of money invested in it. Developing concrete prototypes makes evaluating the project much easier.

There is also less tangible value added by keeping prototyping in mind. Businesses are beginning to realize that like a server a person can’t run at a hundred percent capacity without loosing overall efficiency over time. Google made the practice famous but a whole variety of companies are letting employees take charge of a percentage of their work time. For example here at CCP on the EVE project we have twenty percent of our working time available for our own projects. It’s the lowest priority work and entirely optional but it’s there and people use it. Beyond providing a buffer for work tasks that take longer than expected it also makes sure teams aren’t burning themselves out. Encouraging prototyping in this time has a couple of benefits. Firstly the business can discover new business opportunities. For CCP that paid off in a big way with EVE: Valkyrie, even if the initial prototype hadn’t been greenlit into development the visibility raised must of been worth many times more in equivalent marketing spend than it cost the company. Granted the core team that made the initial prototype eventually put way more of their own hours into the project but it’s an interesting example of these things “going wild” and surprising the executive staff. Secondly it helps keep people motivated, no one enjoys drudge work but it often has to be done and spending a few hours each week on something you find exciting is good compensation.

Whilst I wouldn’t expect prototyping efforts to spin off new products regularly they do also give the business a bunch of products with some ground work already done they could evaluate and invest in when it comes time to do so. Hopefully this sort of culture will experience less downtime between projects and less project risk by having to start all the investigation of multiple ideas from scratch.

Finally the value added by each individual getting better at their craft is not only a tangible benefit to that individual but to the company as a whole.

How much of my budget should I spend on prototyping?

Let’s revisit the initial question. Prototyping is a tool to investigate and conquer the unknown so the budget requirement comes down to how well you really know what you want to make. I guess the answer I’m shooting for now is make it a significant part of your process, especially at project conception and during pre-production.

In Game Development, Prototyping , , , , , , , ,
permalink