Intuition & Dinowaurs Progress Update 1

It has been a little over 2 months since our last update. Many of you are probably thinking that the project has been scrapped or the company went under. Do not fear; we just took a blogging hiatus of sorts. Here’s a rundown of some things that have happened over the last 2 months:

Multiplayer Prototype
We completed our 3rd milestone - a version of the game where 2 people could play multiplayer versus each other. At this point we realized that every game would consist of the players building villages as they went along, and then as they got close enough, they would just dumbly fire weapons at each other over and over again. It was pretty boring, actually. Overall, it was a good thing, since we were able to see what changes would make the game better. Furthermore, the prototype seemed to confirm that the game had a chance of being fun.

The Triumphant Return of Greg
Greg returned from Rome!! One of our team was studying abroad in Rome, and returned over the holidays. It was the first chance Mike and I had to work with him since we were working on PP:AFAA in August.

Design Changes 1.0
Based on our reaction to the multiplayer prototype, and a few suggestions by our (awesome) producer at Kongregate, Chris Pasley, we had a brainstorming session and came up with some improvements on our game design. This particular session was an interesting experience. At the time, we didn’t really have any paper to write on, so we ended up using the backs of small, circular paper plates. Each idea was drawn on a plate, and then we’d discuss them. Those we didn’t like, we discarded to the side. The system worked surprisingly well; in the end, we made these changes to the game design:

• Object of the game
1. “Capture” all villages by destroying the enemy’s and building your own
2. Kill the enemy dinosaur with no enemy villages remaining
• Start of game
• Dinosaurs start in the middle of the arena
• All village zones are occupied by a village
• Each player owns all the villages on his/her half of the arena
• Dinosaur death
• When a dinosaur dies, it spawns at the nearest built, friendly village
• Delay for spawning
• Unlimited lives (as long as you have built villages left)
• Villages
• Villages attack enemy dinosaurs, causing enemy dinos to stay back and use longer-range shooting
• No more village modes (production/defense)
• Villages have more health and attacking ability increasingly toward the edges of the arena, represented by tiers of more advanced technology in weapons and village tower architecture
• Weapons
• Weapons split up into tiers, which are unlocked for each new village captured
• Delay between shots (dinosaur is dazed from firing)
• Unlimited ammo

Dinowaurs Alpha
Several important things were delivered for our alpha milestone. Here are the most notable:

• Persistent player accounts
• GUI menu content and interaction
• Accessory attachment system (!!)
• Design changes implemented

Its pretty exciting to see these kinds of things coming together. Players can create a dummy account, create their 3 dinosaurs, and all of the options currently available can be saved to their account. One of the most exciting things is how well the accessory attachment system works.

We’ll save the details for another post, but basically accessories appear to be attached to the dino, since they follow the same positions and rotations of the bones in the dinosaur’s skeleton. In our case, since the dino skeleton is not officially in our engine, we just export the movement of the bones to a file and load that up for each animation. It has become an industry-standard way to attach objects to characters for AAA games (pretty much since the days of Half-Life - thanks Valve!!), and we’ve adopted it to great success considering Dinowaurs is a real-time multiplayer dinosaur combat Flash game. In fact, Mike just finished up refactoring the weapons to use the same system.

Implementing the design changes got us closer and closer to a really fun game. As of now, it’s kind of fun, but we know that we’re still missing something. We can all sense that we’re getting closer and closer to the fun, though.

New Office Space

We finally moved into an official office! It’s on the east side of campustown in Ames, conveniently very close to our favorite Thai restaurant Thai Kitchen. It’s pretty comfortable for Mike, Greg, and I, and there’s even enough room for a microwave and mini-fridge. Surprisingly, we’ve pretty much outgrown the space after just a month of being there. More on why next.

Intuition’s 5th Member: Joe Bergeron
Greg and I have had several discussions over the past couple months about how we’re worried that the amount of programming work for a game of this size would be a lot for one person. There’s no doubt that’s true, which just goes to show how amazing of a job Mike has done as the only programmer on our game. He wrote the Melba Toast engine himself and was able to get most pieces of the game put together so far. Go Mike!

However, we’re now at the point where much of the game has been hacked together just to get stuff in. Most of the components of the game code need to be refactored in order to make it easier to do things like add new weapons and keep the game stable as we near release. With refactoring needed, added features still, and a couple bug fixes to help us test regularly, there are plenty of reasons why another programmer would speed up development to ensure a successful release.

Mike has been hesitant in the past to add a new programmer, simply because of the skill required to pick up Melba Toast and Dino Server (the implementation of our game that runs on the server) in a timely manner, and the time/money needed to find someone at all and then make sure they’re going to be a good fit.

However, one name would come up over and over again as the right man for the job, if he’d only be willing: Joe Bergeron. Mike has worked with him in the past on their game Codename: HSI, and Joe has gained a reputation for himself at VRAC as “the guy who wrote the OpenGL renderer for the Linux version of the Unreal 3 Engine.” At first we weren’t sure if he’d be interested in completely jumping in and joining us as a partner. We’ve actually been (half) joking with him about it for the last couple months.

When we sat him down for a slightly more serious meeting and asked him last week, he decided that now was the time. Welcome Joe!! Everyone is really pumped about it, since we all get along with him really well and he’s such a great fit in terms of skill set. To demonstrate, here’s a breakdown of our unique skills and interests to show how well each member of the team fits in now:

• Mike
• Game programming
• Gameplay prototyping
• Joe
• Engine programming
• Graphics programming
• Ted
• Drawing
• Concept art
• Greg
• Graphic design
• Creative writing
• Josh
• Technical art
• Business-y stuff

As you can see, that’s nearly every aspect of game development, especially Flash game development. Woohoo! We have a pretty well-rounded team now.

This is getting pretty long-winded, so it’s time to wrap it up. Next post: Progress Update 2, containing more design changes and a special treat for all you dinosaur lovers out there.

Progress Update

Our apologies for the lack of posting over the last two weeks. Here’s a rundown of what we’ve been up to.

After working on the press kit a little, we did some more business stuff to make sure we’re going to be ok with Uncle Sam and protected from the “unknown unknowns,” as it is referred to in The Boondocks. Our lawyer Rush Nigut has helped out a lot with that. Thanks Rush.

Mike has been working on Professor Porpoise: Adjunct Faculty Advisor to the Apocalypse, mainly as a means to continue developing features for Melba Toast. He managed to get a simple scoring and health system in, in addition to spawning ships, one type of which shoots at you. He also implemented some awesome explosions that we’ve made in the past, which even shake the screen. So PP:AFAA is now made of action-packed awesomeness.

Check out PP:AFAA here (pardon the debug lines). We’ve decided to treat PP:AFAA as a side project that we’re going to pick at from time to time when we need a quick break. It will be developed more and more down the road. Hopefully we’ll get to see some of Ted’s awesome concepts in action.

An interesting side note about this early version: It’s not fully optimized for performance yet, being so early on in development, but, yesterday I found out that Adobe has released a new beta update of Flash Player 9. I was amazed at the performance increase it has with PP:AFAA. Previously, with a few explosions going off at once, my Macbook Pro 2 Ghz Core Duo would drop down to 10fps or so. With the new beta Flash Player, the game doesn’t get much below 24fps. I think game developers who are working on Flash games will really be excited when this new version gets released officially. I know I am.

Ted, Greg, and I have been spending much of the last couple weeks concepting, mostly for Dinowaurs. One of these days we’ll compile stuff together and maybe post it up for all to see. Greg is now officially in Rome, too. It was sad to see him go, but sometimes you just have to let go. He’ll be coming back to the nest soon enough. Be careful out there, Greg!

I’ve also been learning ActionScript 3.0 from a couple books, including an awesome one by Colin Moock, Essential ActionScript 3.0. His ability to explain the meaning behind things is great. Anyone who has a beginner-level knowledge of programming concepts or higher and is interested in learning about ActionScript 3.0 will really enjoy the book.

Prototype This!!

Finally squared away the actual movement for the Prof himself… This was actually really agonizing and horrible more due to my lack of experience working with the trig functions of Flash than anything else, but damn this took a long time. I tried about 4 or 5 different methods for controlling the Prof both in and out of the water and I finally settled on a hybrid of vectors and degree modification. In actuality, the player is only in control of the directional vectors which move the Prof around in the gameworld, this allows for the easiest level of switching between aerial and aquatic maneuvering, though moving through the air and moving through the water are very different.

Essentially there are two modes of interaction, one for in the air and one for in the water. When the Prof is in the air, the player can “pull up” or “push down” similarly to a flight simulator. Pulling up will create a certain amount of lift, which is always less than the effect of gravity so the best you can do is glide a bit. Pushing down will increase the downward force in addition to gravity and lets you plummet to the ground more quickly. This is the simpler of the two control schemes, as you just have one acceleration vector which has both directional and magnitude. The rotation of the sprite is calculated by a simple trig function.

When the Prof is in the water, however, it gets horribly complex. First off instead of one vector there is now a scalar velocity value and a unit vector which is the Profs orientation. The rotation of the sprite is calculated with trig using the directional vector, just like above. This is the crux of what I was going for, so that the vectors controlling acceleration would be in control of the rotation of the sprite and not vice versa.

I ran into a problem, however, as previously in order to rotate the Prof in the water I could simply rotate the sprite and re-calculate the directional vector. Now that I wanted the vector to determine the rotation, I had to figure out how to change the vector to simulate an rotational object and maintain it as a unit vector. I’ve never used this kind of math before so I was fairly out of my element and I wrote about 3 different methods to attempt to change the rotation smoothly, all of which created a total clusterfuck of random rotations and what have you. I never really figured out what was wrong with those algorithms, even though I spent a few hours trying to fix them. I eventually decided to use pure math to control the vectors with a much more elegant solution.

Here it’s gonna get triggy and wavey, so bear with me. I created a new value, a 0 - 360 control value which represented the current rotation of the Prof while in the water. From this the directional vector could be calculated and from them the actual sprite could be rotated. Why this is better than simply using the rotation of the sprite as my guide I really don’t know anymore, though they seem to be essentially the same thing.

Anyway… The Y component of the vector, which is vertical movement, is determined by a sine wave with no offset. Essentially I use my new rotation control value and feed it into a sine wave every frame, and the control value determines where along a single period waveform the Y component of the vector is. Essentially this means a control value of 90 will make the Y a maximum, a value of 270 will make the Y a maximum negative value and values of 0 and 180 make it zero. The X component is determined the same way, using the same control value, except its waveform is offset by 90, so where Y is zero, X is a maximum (either positive or negative), and where Y is a maximum, X is zero. This is all pretty basic trig, but it took me a while to get up the nerve to trust myself to use it and figure it all out.

The final step was to make the transition from air to water smooth… which was more frustration, but I got it.

This was a pain in the ass, but now it’s pretty much what it needs to be. Now it’s pretty much all about tweaking for proper results.

ALSO, if you play around with the jumping out of the water, you can see that when the framerate is really low you can jump much higher than when it is high. This is ’cause I haven’t decoupled my physics from my framerate… I never had the problem well illustrated to me until this, so It’s neat to see the problem in action.

APEs, Motors and Floaters, Oh My!

So, I spent some time getting back to PP:AFAA today and worked out some hacky solutions to the floaters. Getting buoyancy to look good was actually fairly challenging for my tiny brain, however I created a fairly convoluted algorithm which should supply all the requirements for the prof. This got me thinking hard about the purpose (porpoise? haha!) of Melba Toast and what exactly I am trying to accomplish with the engine. The original intention of the engine was to create a fast, reusable codebase which I could go back to for multiple games and maybe share with other developers (though i’d probably have to start commenting…) who are trying to accomplish similar goals. This is especially important for Intuition as our goal is to create multiple games on a shorter time frame in order to iterate on lots of cool ideas, find a broad market and have fun.

The problem is that engine development is not quick, it takes a lot of work and research to find optimal algorithms for every facet of functionality, and while I can work with the unfinished engine to create quick games like PP:AFAA, I have to fill in the missing functionality with hacks which don’t take as long to research and work fine enough in the mean time. So this gets to my point, which is I am struggling with deciding whether to take a longer time to write solid code now and take a lot longer on development for negligible short term benefits (i.e. PP:AFAA don’t really NEED collision based on separation of axis theorem or a spring system) or do I just hack it up and get it out the door? I need to learn how to do it the hard way, but I’m also a lazy american who wants it and wants it now.

The obvious third option is to use an open source physics library like APE or Motor (though i’m not sure Motor is going to be freely available) though the obvious down side of third party physics solutions is that they are not tailor made to my specific problems and I don’t know their interfaces…

For now I’m hacking it, and if I need to I’ll fix up the code later. That’s generally the accepted choice of game development, from what I understand, but as a programmer I still hate writing code I know is bad and needs to be replaced.

Waves and Toasty Stuff

We’ve been working full steam on PP:AFAA tonight, and I’ve finally gotten back on track with Melba Toast and breaking out teh codez. I actually started out on prototyping water yesterday and thought I’d have an easy time of getting some wave action going… Boy was I wrong.

Actually in theory, it would have been pretty simple to just throw a line on the screen and use a sine wave to do some nice wave effects and the just move on. However, I have decided to use Melba Toast in the most responsible manner possible and that means avoiding shitty shortcuts and hacks. I determined that I wanted my water to be a tile, which means it has to be subjected to all the culling algorithms I wrote for my MelbaTiles. This set me right in the face of one of the two problems my tile engine currently has, the other of which is I have no faculty for actors which are able to move across the tile sectors (see Tile engine tutorial to get an idea of how the tile system works), and I only register tiles with the sector that contains their registration point, i.e. the upper left corner. This second issue is a problem for any tile which overlaps two sectors or especially tiles which are larger than a sector. I decided that the water shouldn’t be split up into multiple objects, a decision I may change later for efficiency, which forced me to solve the problem of super sized tiles before I could even make my water show up on the screen.

So anyway, I came up with 14 different cases of tile orientation on a single sector and was about to write up a massive nested if() clusterfuck when I remembered the collision lessons the Metanet Software crew (makers of N, check it out) released. Using their “Maths”, I was able to reduce the statement to about 8 lines of code and was very pleased with myself.

Long story short, there is no longer a limit to the size of tiles Melba Toast can support, and we got neato water effects, though it’s not too dynamic at the moment. You can use the arrow keys to scroll around, but you can get lost quick.

Also, tilde brings down the console, though the only command right now is fps.

We’re Like a Hot Dog In Search of a Bun

After looking at this image and snickering for a moment, I quickly realized that we are the hot dog. We have a meaty game development substance to us, and are in search of a bun to present our meat in a way that is easy to grab and consume. Not only that, but we’re not sure exactly what kind of hot dog we are and therefore what kind of bun should hold us. We just stand there, intrigued by the opportunity we see before us.

So the search continues to find our proverbial bun. With regards to that, a lot has happened in the past couple weeks.

After Dinowaurs was turned down, we sent it over to Jim Greer and the folks at Kongregate. They seemed pretty interested in the idea, but were thinking more about the game being a multiplayer experience. Finding that out was exciting, because our original idea was for the game to be a multiplayer game. So now we’re working on editing the pitch to be multiplayer. Hopefully they’ll enjoy what we’ve come up with.

Then, all three of our pitches sent to Adult Swim were shot down. However, there was a glimmer of hope. They seemed to really like one of our ideas in particular - Hitchhikémon. As the name suggests, the game is based on the Pokémon franchise. In Hitchhikémon, you cruise the highway, picking up Hitchhikémon who seem like promising additions to the team and battling other Hitchhikémon masters. You must order your Hitchhikémon to fight from the roof of your speeding truck while avoiding oncoming traffic, road debris, and civilian drivers. Utilize strategic thinking to decide what weapons they’ll use in a given fight to develop their skills into a true killer.

So basically, the game is like Pokémon, but instead of walking around, you drive in your truck. Not only that, but you fight with your hitchhikers while you’re still driving - and you have to avoid obstacles. It’s every hitching stuntman’s dream game.

The problem with this game is that the name is a pretty big part of what makes it funny, and considering the ridiculous size of the Pokémon franchise, attempting an obvious parody would be pretty risky for Adult Swim. The good news is that we’re quickly closing in on the kinds of things Adult Swim is looking for.

Mike continues to work on Melba Toast. What is Melba Toast? I’ll leave the details to Mike, but for now I can say that it’s our highly-optimized Flash 9 engine. And it’ll rock your socks off. We’ve been debating on whipping up a really small game with it. Right now we’re thinking of trying to clone Tanks from Wii Play. Man, that’s such a great game. It has this N-type quality to it, where the mechanics are extremely simple, yet extremely well-tuned. Really, the game would end up a poor man’s Tanks because of how hard that quality is to pull off. Stayed tuned to see what happens with that project.