Before the waves there was only crashing.

Grab some popcorn and listen in as we discuss how we took Wave Crash from concept to prototype. Design goals, tools, engines, we hold nothing back.

Transcript

(For our friends at work pretending to be working)

NICK: Greetings internet. This is Nick, or Aero, from Not Robot and I am here with my fellow game creators Derek and Ryan, also from Not Robot, and we’re going to give you a quick walk through of our prototype game – Wave Crash. Do you guys want to go ahead and introduce yourselves?

DEREK: Hi, I’m Derek, and you may end up hearing me called Dyno.

RYAN: I’m Ryan, and I may be called Viking sometimes.

NICK: Cool, so as I mentioned before, we’re kind of going to give a walk-through of our prototype for Wave Crash. We’re going to talk about some of the decisions we made and some of the tech we used and just why we did the things in general. So why Wave Crash? First off, we wanted to make sure we would do a game that we could figure out big problems and find the solutions to them. So we wanted to start with a really small scale project, so we decided on a project that we could manage with ten hours per week. So something we could easily do without being too strained on our time. We wanted a game that we could to in only a couple months, and we kind of failed on that a little bit, but we’ll talk about that later. We also wanted to make a game that we thought we could do easily, but would still be a lot of fun. So we decided on a runner type game, but we wanted to put our own twist to it, which is why we have this really physics intense runner that you have in front of you now. So we just wanted to make something easy, simple, quick that would still be fun. That’s why we decided on Wave Crash.

RYAN: Basically, there were a lot of things that we needed to learn how to do, as a company and within the game itself. We needed to learn how to work as a team, we needed to grow our team and become a well oiled machine, in that respect, and we also didn’t want to dive into anything that was a particularly huge problem, or was a daunting task to try to figure out. ‘Well, how do we write an algorithm that does this?’ – things like that. So, we thought it would be best to try to solve small problems first, and constraints could go and in future titles move on to bigger and better things. So we just wanted to focus on something that would be more simple, and we could do super well instead of trying to do a lot of different things and kind of half-ass them. We wanted to do something limited in scope, very constrained game play loop without a lot of variables, so we could both iterate on it quickly, get it refined and working game play wise, but also technically and not have too many huge challenges there.

DEREK?: This is our first project mainly, for the three of us, that’s been a side project, that we are actually taking all the way from initial conception to market. Like Nick and Ryan said, we wanted to constrain the scope, keep this small. So we kind of considered this the first step that we’re going to take of many, and we have really big dreams for the kind of games we create, but this is where we’re starting to make sure we complete it and keep working towards it. And another important thing to us, with the game, is we ran in the past, sometimes, to problems where we would dive too deep into a problem and lose sight of having a fun game to play. At least Ryan and I did in our side projects in the past. So we wanted to make sure to get to a prototype that was fun, we had fun playing it, even as we develop it and add features to make it better. One of the main problems that we have is that we waste a lot of time playing our game, and we’re just trying to test for features.

NICK: Yea, I think we’re all a little guilty of that one. Behind you, we are hopefully showing the video to our prototype. Not sure if you guys have been following along with our other content, but you’ve probably seen pictures of what the game looks like now. So you know that the prototype is super basic compared to what we have now, but its still truly important to recognize that we made the prototype basic on purpose. We just wanted to get an outlet to test our basic idea, our basic mechanics to make sure that what we’re doing is actually something that would end up fun in the end. If you have something that’s not fun, and you add a bunch more features to it, chances are it’s still not going to be fun. So, in the video, you have a really basic game. You have the entire control scheme, the forward and backward button, you have the little vehicle dude that’s running around that you drive, and you have spinning through the air, and then, really importantly, you have randomly generated maps which we thought would be really fun to have in the game. Kind of a dynamic map that would allow us to generate a lot more content on the fly while at the same time give feeling to the players that there’s a lot more content cause it’s different every time.

RYAN: I just want to hit the topic of how basic your prototype needs to be. A lot of people will approach something and think ‘Well, what do I need to make this function?’ and they’ll think all about end concept type things - final art assets, final game play - these types of things. And it’s good that you think about those types of things but if you don’t actually play it, you don’t actually know that that vision or concept that you have in your mind of the game is actually fun. Getting the prototype out there as fast as possible is very important and it needs to be in its rawest and most simple form, and just build it as fast as you can. Get it to a playable state as quickly as possible.

DEREK: I think it’s important to point out the small nuances you’re seeing on the screen right now, and how much time was poured into getting the graphics to be exactly how they are. I think you’re going to notice that the stick with wheels is 50 pixels long, it’s not 49, its not 51, and we did a lot of A/B testing to determine how long it should be.

NICK: Similarly, the orange we picked for our maps is a very specific orange. We tested thousands of red/green/blue combinations on our hoard of unwilling subjects to make sure we maximize the fun potential of our game. We want to maximize that fun, that’s why we started with blue waves, but after some testing we realized that orange is just better. As Ryan mentioned, for our prototype, we wanted the vehicle, which was the player/actor, we wanted the maps, which is what the vehicle’s riding on, and we wanted the vehicle moving really really fast, which you can see it’s kind of ridiculous in this iteration. You can’t really tell where you’re going and you just fly through the air. And we wanted it orange, cause orange is good. Alright, so next we’re going to talk about some of our basic coding decisions that went on in the background, that you might not be seeing just on the video. So I’m going to start off giving it to Dyno/Derek here and he’s going to tell you a little bit about our framework.

DEREK: So there’s a couple different things that you probably need to consider when you’re looking for a framework to work within. The most basic of them is that your framework should lower the amount of work you need to do to get to market. So we did some research on different things that were out there and available, and like I mentioned at the start, this is the first project that we’ve taken from beginning to market and we wanted to make sure that we picked a framework that would keep us productive from beginning to end and not tie our hands at the end when we’re trying to do cool stuff. And we also want to, like I mentioned this is kind of the first step in doing more and more, and so we want something that will grow with us so we can build on the code base that we develop. So there’s a couple different options. Like we mentioned before, our target market is iOS, but we, if possible, we would like to be OS agnostic so we can move to Android, move to the web, move where ever we want in order to grow our company. A couple of the things that we looked at, we looked at Unity, Unity is just really popular right now as a cross platform framework. And then specifically for iOS we started looking at Sparrow. It’s an Objective-C library, but it’s kind of modeled based on the old Flash framework that people are familiar with from Flash development. The problem with Sparrow is that none of us had any Objective-C coding background and we were able to get, what we do is make pong to test the viability of a framework, and we were able to get pong out in pretty much one or two weeks of work, I don’t really remember quite how long, but working at 10 hours a week, you’re looking at 20 hours to get a really good idea on how good a framework is going to be. So, based on using Sparrow, which we really liked it, we also saw that the same people who developed Sparrow developed Starling, and Starling has its roots in the Flash game development era. Starling is build on top of the Adobe Air platform, and the nice thing about Adobe Air is that you can release it pretty much everywhere. It’s almost as ubiquitous as Flash gaming was. After kind of testing those things out, and based on our constraints - that we’re a bootstrapped company starting from the beginning, Starling and Adobe Air work really well with us because they’re free, in addition to being just a good platform to develop on. And so as we mentioned also, we decided to tackle a game with a full physics engine to differentiate us from other competitors and other people who have done runner type games and we just wanted to enable a rich player experience. So in order to do that, we obviously didn’t want to write our own physics library, or we might want to, but it’s not a good idea to. So there’s kind of two ideas out there for the action script environment that people might want to use. There’s a box 2D port. Box2D is just super popular, you’re always gonna have a ton of support when you use it and tons people to answer questions. But what we found in what we saw is that it’s not quite as fast as a physics library called nape when running an ActionScript and in a lot of cases we saw the nape required six times less CPU then Box2D. For our final decision we’re writing Wave Crash in Starling, and using nape as our physics library. And if you’re interested you could tie it together yourself but at the start we decided to use Citrus engine to tie everything together.

RYAN: The greatest thing about Citrus is that it immediately allowed us to hit the ground running. I mean it it we’re kind of out growing it I would say but it just kind of had everything built in from the start we didn’t have to fight anything and as he said, the role of any good framework is to make it so you have to do is little work as possible, and I think where we are now I am we’ve kind of grown beyond it but at the beginning when we didn’t really know Starling as well as we do we do, we didn’t know nape as well as we do… Citrus is really great at getting us to that point.

DEREK: Yeah it’s definitely true

NICK: Cool, so that’s a pretty good overview of why we made some of the big technical decisions and now we’re gonna switch into talking about some other big issues coding wise for Wave Crash, what the big problems were and how we solved them. so I think Ryan you probably know best about that, why don’t you start us off?

RYAN: I think that his biggest issue with our prototype is the physics engine. we talked a lot just couple minutes ago about trying to constrain the scope for the prototype and make it as little as possible but that full fledged physics engine was kinda necessary for the endgame and you do kind of want your prototype to be representative of what the end game will be so to do that without a physics engine would just be an exercise in something that’s worthless. So getting that in the game and getting it integrated into things was a lot easier through citrus than it would have been without. But it still is kind of hurdle how to get things on screen how to make them behave… So you have that kind of problem where you don’t actually know what the right mass for any of your objects is, you don’t know what the right friction or any those types of things for the ground or any other objects in the environment are and getting everything to be congruent and balanced is always gonna take a little while. I think I mean both getting the physics engine in there and then kinda getting it balanced was one of the biggest issues that we had getting the prototype running. If we kinda faked it and made our own home-grown solution it would be buggy, it wouldn’t be what the end game would actually be, so you would play it and you have some expectation of what things are going to be like and it might be fun and then you get the real physics engine and it just puts completely differently. The biggest thing about the prototype is getting a first peek at what your game is going to be. Figuring out how it’s going to be fun and in what ways it’s going to be fun and let you discover things you didn’t know were going to be fun that are fun and you can run with those ideas in flesh them out. But if you don’t actually have it representative of what the game is going to be, your going down the wrong path like a dead end. You are not going to get where you want to be.

DEREK: You can also ask the question when you’re developing a game…Why go through all this headache that Ryan is describing of tweaking the physics engine and basically the idea is just like he said your your modeling a virtual version at the real world and what that enables is just a lot of cool unscripted things that can happen in your game and just reactions that just feel much more natural to people who are playing. And it gives you the kind of scope where things can happen your game that you just can’t plan for but that make for those fun moments for players.

NICK: So next we’re gonna briefly go over and talk about what we think with right in our prototype and then what we think went wrong. To start us off I think we’re all kinda surprised that as soon as we got the physics in and as soon as we got the a map in a vehicle in, how fun it was right off the bat. We had us, we had our friends… the people playing it were just laughing and giggling the entire time at just how ridiculous the prototype was. They couldn’t put it down. That’s something we spent minimal time on was already making people happy. So that was a huge motivating factor for us and this meant we were on to something right off the bat.

RYAN: Yeah I can definitely say that as soon as the physics were working with a vehicle and it was playable I lost a large amount of time that I should have been debugging and making it work just playing it and laughing hysterically at that little car.

DEREK: We all did that. And so when you’re planning for your own game make sure that you add like 10 to 20 percent more time onto your schedule because you’re gonna be playing a game you gonna think it’s fun. And if you don’t you probably need to find a new game to develop.

NICK: next what do you guys think went wrong?

RYAN: I think… This isn’t specific to the prototype but it’s kinda in that prototyping phase and the transition from prototyping to actually writing the game. I think when we got it working and we had the prototype we didn’t ever take a minute and look at what was there and then try and figure out how best to build it at a architecture level wise in the real game. We just kind of took what we had from the prototype and started adding features and growing it organically and I think if we had had that moment where we we looked at the whole project and said “okay here’s what we have here’s where we want to be.” and then kinda draw a map in the middle how to get there I think would’ve been better than just kind of you know get in the car going. Certainly wasn’t terrible but things could have been better. We introduced a lot of technical debt along the way.

NICK: I think that’s kind of it’s own discussion just because we didn’t exactly know where we were going. A lot of the path changed based on what we found found fun as well. So it’s not always possible to plan where you’re going. Half the time you don’t know where it is.

So what you’re looking at now or what you were looking at before was our prototype. After we finished this our next goal was to move to an alpha.In our alpha, we wanted it to be something that kind of built more of the basic features in to give more of a representation of what the game is going to be. And we also wanted add in some low-level art to meet the theme so that people could tell what the player was and what was actually going on. Maybe get some narrative going. So those were our two big things we wanted to push on next after finishing the initial prototype as far as design goes.

Design issues moving forward

DEREK: We needed to make sure that everything we added was something that would make the game more fun. We don’t ever want to add a feature that makes it less fun. In fact there was a time where we kinda… the very first vehicle game was kinda almost too under powered so the game was a lot of fun to play as a jet ski but if your playing as the wake board it just wasn’t fun. You can’t have that first vehicle not be fun. You need to have the first vehicle be a blast and then the next vehicle be a bigger blast. so that’s kinda one of the big design issues that was a little difficult. That you had to progress from from fun to more fun but if you don’t catch em in the first thirty seconds you’re never gonna keep those players.

DEREK: And so moving forward from the prototype that you’re looking at we definitely wanna add more cosmetics get everything looking good add more maps. Just in general- hopefully find some more things that make the game fun and differentiate us.

DEREK: That just about wraps up what we want to talk about, about our prototype. Hopefully you learned something about, you know, what you should look for when you are developing your game and making a prototype. The things to keep in mind are just to keep it fun, make sure your games are always fun. Make sure you keep your scope limited, get to that prototype as fast as possible like Ryan was talking about.

NICK: Yea so hopefully you found something of value. If there is something you hope we touch on in a future blog post or video blog, make sure you leave us a comment and we’ll give you whatever you think will be valuable

DEREK: yeah we basically wanna be just like 100 percent open about everything we’re working on. We figure if we help each other out it makes us all better.

NICK: We look forward to hearing your responses and hearing your ideas. Whether or not they mimic ours in the comments.

DEREK: and it’s also important to keep in mind that none of the three of us are robot.

NICK: we’re not robots, not being controlled by robots. There’s no robots here.

RYAN: Definitely not robots…. …And thanks for watching!

UI Artist by Day, Tech Artist by Night

Diversifying your skill set to improve productivity Continue reading

F2P 101: Acquisition

Published on December 10, 2014

The 10 Hour Work Week

Published on November 16, 2014