7 strikes - The "Unwritten Vision" & Finding a Systematic Methodology for Pitching Game Ideas

If this were baseball, the team may still be hopeful, but this is a video game, which includes baseball video games, so maybe hope is alive. Our last three ideas sent to Adult Swim were rejected and may not have been our best yet, although I probably shouldn't speak specifically about any of them, we all felt like the writing of the pitches themselves was very strong. Somehow we're always optimistic sending off these little guys, even though we've been rejected and tell each other that our chances are slim, our hopes always end up high in the sky where they shouldn't be.

"IDEAS! You are grounded!"

It's true, we need to ground ourselves and our lofty ideas of having hope for the future, especially when you offer up the fate of that future to another party for approval or disapproval. Chances are that our notions of which ideas are good and bad have a lot more to do with the "unwritten vision" inside our heads than what the actual written idea turns out to be on paper. For me, our ideas that we pitch turn into a fantasy of sorts, and part of the fuel that feeds that fantasy is the idea of the pitch's acceptance.

"Man, if we get to make this, it'll look like this, this and the player can do this! It'll be so cool!"

But this kind of thinking is counter-productive to pitching a really solid idea to a very critical audience with an even more critical target audience. By doing this we're essentially attaching our own convoluted emotions to the game's worth, that ultimately has nothing to do with the game itself. This ends up being a catch-22 since the hope and excitement of creating our own original game fuels us to work on it really hard, but in the same turn, it also clouds our judgment during that initial process.

"So how the hell do we see with eyes unclouded Ashitaka?"

I'm not exactly sure but I think we'll need a more systematic approach, and I think that's something we're closing in on as we go through this epic journey to save the forest spirit. In my opinion, that systematic approach would be more like a venture into the marketing world as opposed to just "using our gut." The gut is definitely more fun and better suited for our own internally-funded-games, but the marketing approach would probably lend itself to a higher success rate.

Who knows, but I'd say mix in more research, systematic methodology (pop-culture flow charts?), more criticism, emphasize character, and a lot of testing and we may just figure this thing out.

After writing this post and thinking about the nature of our pitches, and Adult Swim's reception of said pitches, I wonder if this is just a case of a generational gap. I think it's safe to say we believe in the web2.0 process of publishing, just getting it out there and seeing what everyone says, then re-iterating until it succeeds, however in contrast with AS's process, they appear to be founded in a quasi-traditional publishing process with just releasing one time, and hashing it out behind closed doors until it's up to snuff.

While that may not have a ton to do with our ideas sucking in the opinion of AS, I think it's part of the frustration we're experiencing.

Josh's response (I hope you don't mind if I add some input here)

The processes being referred to here are agile development for us and waterfall development for Adult Swim, respectively.

It's becoming pretty clear that the waterfall method only works in video games for select cases. That's why you are seeing a pathetic 20% success rate in video games versus the more typical 80% success rate of other media. Most people who analyze such things narrow the causes down to these:

1. The complex nature of video games creates a lot of chaos, which you simply can't plan for. Things go wrong and there's nothing you can do to stop it.

2. The interactive nature of video games creates a huge possibility space for events to occur. When you design a game, it's very difficult to think of all of the possibilities of actions that can occur, all of the problems inherent in those actions, and all of the solutions to those problems.

3. The industry is still in its infancy. We don't have a proven method for designing good games. So far it has been "guess and check."

Agile development tries to solve this by assuming that - whether you blame chaos, limited knowledge of possibility, or lack of established methodology - problems will occur no matter what and that you'll need to rework them to solve them. So get your product out the door as soon as possible to find out what those problems are - "release early." Then, release your product as frequently as you can so that whenever you go to solve your problems, you have as much information as possible about your product to inform your decision - "release often."

The problem with using this process for Adult Swim games is that it doesn't fit well with the website, since it is currently being treated like retail space in a media specialty store like Sam Goody. A small selection of finished, polished products are being presented in a way that assumes those who come across the page will be interested enough to play one or more of the games. The waterfall method will give you a finished, polished product to sell on the "shelf." In order to succeed here with the agile method, though, you need to be late enough in development that you have iterated a few times and came up with a polished product. The question then becomes "Who am I releasing early and often to, then?" And will Adult Swim even allow such a method?

The analogy of the retail space continues. In order to sell units - or in this case, traffic - you need to have an eye-catching cover - or in this case, gameplay video and description. Additionally, the game itself needs to be fun enough that Adult Swim can get more traffic through word-of-mouth advertising from people who have enjoyed it. So these are even two more reasons that it would be more fitting to use the waterfall method.

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.

Shiggy <3 Reggie + Martha = Game Cake

Photoshopping of the beloved Shigeru Miyamoto and Reggie Fils-Aime atop their grand cake. Martha Stewart helped and was rumored to have a hand in the couple's initial meeting.

Another Round of Pitches to Adult Swim

Out goes another 3 pitches to Adult Swim. That comes to a total of 7 now. Although, it seems like we've sent way more than that. Maybe we're just getting used to it now. I don't want to say that we're getting good at it, but I'm not sure how else to say it... I know, we're starting to understand it more now. Yeah, that's it. I don't think any of us have pitched so much in all our lives. It's like we're Clark and Michael now or something.

In fact, we've discussed gathering all of our ideas into an official Rejected Game Ideas list. I bet we could hit 50 at this point. Of course, many of them look like this:

CULTure Shock
You play as an aspiring cult leader and must build up your membership while trying to secure the necessary inventory for the rapture. Run into normal everyday problems along the way; the store is out of kool-aid, run out of gas, rent bills piling up.

Game mechanics?
* Collecting membership and putting them to work building the future
* Devising mass suicides
* Dealing with everyday problems


So it's not like the list would be a novel or anything. This is one of the better rejected ones; some of them are pretty tasteless. I think that's what would make the book so entertaining.

Speaking of that, I think it would be great to compile them into a book and use an on-demand printing company like Blurb to sell the book online. Of course, this is exactly something I would say. I always seem to be looking for some crazy way to get us some money, since, you know, we're dirt poor and all.

Hopefully, we're getting closer to the kind of ideas Adult Swim is interested in. We can keep going, though. If we do, I just hope that we get to the point where we're the pitch-giving equivalent of when you get really, really tired at 4am, and you start to get all delirious. Then it's really going to get interesting.

Game Tunnel's Stinky Top 100 Indie Games List

Derek Yu over at TIG Source has an awesome post entitled Game Tunnell's Top 100 Indie Games List...Makes Me Sad.

"What we have here is an indie gaming news site run by a Reflexive employee, hosted by a Pop Cap studio, running a list called “The Top 100 Indie Games” that is little more than a portal front page."

I won't link the list directly - you can follow Derek's article if you want to look at it. The problem isn't necessarily the list itself, but mostly the intentions of the list, and how it's being treated by the community. The intentions seem to be purely for the selfish interests of Game Tunnell. As Derek indicates, many links in the list have referral codes in them, and of course the games listed are only those that have been reviewed by Game Tunnell in the past.

Even worse, many people in the community are treating this as some representative list of the best indie games out there. It's definitely NOT representative of indie games. People who think so are clearly missing out on a lot of the games discussed at TIG Source, in addition to a plethora of free Flash games. Make no mistake about it, Flash games are most definitely a part of the indie game space. I hope whoever finds that list will quickly ask "What else is out there?" Here's another nugget from Derek's post:

"It’s like someone farted at the dinner table and no one wants to admit that it smells. Over at the Indiegamer forums I just know that the conversation is going like this: “Honey, this chicken is delicious!”

WELL YOU KNOW WHAT IT SMELLS TERRIBLE IN HERE AND IF THINGS KEEP UP THIS WAY NO ONE IS GOING TO WANT TO EVER HAVE DINNER WITH US."

This might be a bit brash, but it is this passion that makes me proud to be a part of the independent game community.

The Professor preys on boats

Recently we nicknamed Prof. Porpoise, "The Professor" due to his extreme agility on the court as well as his radical dissertation on The Crossover: An Application of Metafluid Dynamics and Quantum Mechanics Subsystems to Underwater Basketballs. The Professor isn't all sneakers and snow globes. When he's not drainin' half-court PS-triples he's sinking sea-faring vessels in the name of the Almighty's Reckoning.



So I drew a few of those ships that he'll be snacking on. I'm going to illustrate them fairly soon based on these drawings. Right now we're just gathering ideas on the different types of boats and which would be funnier and more effective. For now this is a pretty good smattering of boats, ranging from early level rafts, to millionaire customized yachts. When I draw I use a ballpoint pen, preferably a Bic Cristal but normally it's just whatever is lying around. If enough people want tips, I'll post something about the technique in greater detail later on.

PP: AFAA Progress Update 1

The official work has begun on PP: AFAA! This project is so important to Intuition, that we've decided to use our secret weapon, a creative think-tank known as Team Yesss (that's yes with three s's). Team Yesss was able to choose a preliminary color scheme, get the professor made based on Ted's design, and get him into Melba Toast swimming around. Great work guys! Some excellent concept art has been sketched up for the boats, too. That should be posted soon. [Update: Greg has a post with the concept art] The next steps are putting in gravity, damping for swimming, buoyancy (a first for a Flash game as far as we can tell), and boats and humans for content. Intuition is confident that Team Yesss can pull this off with no problem. Here's a screenshot of Professor Porpoise in action, enjoying a swim before he partakes in his duties of bringing on the apocalypse.

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.

Professor Porpoise: Adjunct Faculty Advisor to the Apocalypse

It has been over two months since we all decided to get together and start something up and we still haven't worked on any actual games, until now. I don't think any of us envisioned the process of actually starting taking so long, but it has, and it seems to be a necessary evil of looking for funding our development. While nothing has been approved for sponsorship, we have decided to just go ahead and make a game already, something simple, fun and humorous. The idea is to build our brand and portfolio while still searching for a place to lie our creative heads at night.

Enter... "Professor Porpoise: Adjunct Faculty Advisor to the Apocalypse"

He's the smartest dolphin (Porpoise is just his Christian name) in all of the seas. Since retired from the rigorous research of university life, he now looks after a small school of gifted younglings who call him Papa 'Poise. But he has a secret, as a babe he was branded as part of a holy order, and now he must take action in his role as one quarter of the Four Horsemen. The Professor suits up with super-cop spear helmets and magick horn blades, cutting class to take care of business, fire & brimstone style!

We're currently using Mike's Melba Toast engine to make a simple prototype that we will hopefully have within a week or two. The logo above is something I whipped up this evening, and while I'm not thrilled with it, I think it gets our concept across well enough. We'll post more images, concept work, demos, and assets as they get pumped out, but for now I think we're all pumped to make something fun.

Intuition's Slalom - A Scratch Game

On Monday, I discovered a Web 2.0 online community website called Scratch. It looks like one of those sweet MIT experiment project things. You can download the Scratch application, do what is the equivalent of programming with Lego pieces, and post your creation - which would likely be a game or animation - on the Scratch community website for people to look at. I think it's a fantastic way to bring programming to the masses. So I was inspired to make a game.

I've had this idea for a while. The game is called Slalom. You have an avatar, and you must move the avatar to one side of a falling object. The side you want to be on is toward the word that corresponds to the color of the falling object itself. For example, you have to move to the right side of a red falling object if the word "red" is on the right.

The challenge of the game lies in the fact that the words switch sides and eventually switch colors. So the word "red" might be on the left but might be the color blue. You need to be on the left side of the red ball even though the text is the color blue. The little mind puzzle has been around for a long time - psychologists would often do this to mess with people. Recently, this kind of puzzle was used in the Nintendo DS game Brain Training.

Overall, the game took me just a couple days to make. It would have been quite a bit faster, but the Scratch application needs some work in my opinion. It's not object oriented, so you have to workaround ways to get values out of the objects. What really needs to happen is that Adobe needs to make a version of this app that sits on Flash. If they managed that, they would start yet another revolution.

Play the game here and let us know what you think.

Clocky! and other recipes for indie dev survival

How do you actually wake up, instead of waking up every 9-10 minutes to throw your arm at the over-sized snooze button of your oil-burning alarm clock? This is the answer, and of course it's in the form of a robot. Damned robots. If DaVinci went polyphasic then maybe this is the way to do it.

While we're off the subject of anything actually involving game development, or the gaming industry, I've decided to share a recipe, that also help you and I survive, just as Clocky hopefully will. I usually cook in large quantities which make for a good amount of leftovers that I can reheat whenever I want while I am at work. This is one of my old stand-bys that I learned from my very good friend, Shyam.

Red Curry Beans

1 can of black beans
1 bag of frozen stir fry vegetables (use fresh vegetables if you live on the edge)
1/4+ cup peanut oil (vegetable or any oil will work, but peanut tastes best)
1-3 Tbs red curry paste (personally i use Mae Ploy, it's delicious)
3-5 cups of rice (i buy short-grain rice in bulk to save money, $20 for 25 lbs.)

Firstly, if you do have fresh vegetables, I advise you to use at least one or two tomatoes, along with an onion and a green pepper. If you just have the bag of frozen vegetables, that will work, however the final result of the bean curry won't be as soupy, which will not penetrate the rice as much.

Chop, cut or throw your vegetables into the pan (onion first, then green pepper, then tomatoes) with a tablespoon or two of peanut oil and saute on medium. This isn't low in fat, I use a lot of fat when I cook because it tastes better and works for this recipe in particular. Once the onions are translucent or the vegetables are nice and sauteed, add in 1 tablespoon of red curry paste, and mix with the remaining oil in the pan. This should dissolve and season all of the vegetables mildly. If you want it stronger this is the time to add more, tasting as you go.

After you're happy with the amount of heat, keep the vegetables cooking, we want them cooked through pretty well so this will eventually turn into a thick chili-type consistency. Now thoroughly drain the black beans and add them to the pan. Next mix the beans and vegetables together and spead on a piece of bread, cracker or spoonful of rice to taste. If the spice isn't up to snuff, you can add more red curry paste here.

I usually let this cook down on medium-low for a good bit, allowing the heat to breakdown the vegetables and the beans enough to become one substance. Store this in your fridge until you re-heat and serve on top of rice, or any carbohydrate you have around for a well balanced snack or meal. This also works really well for a tortilla chip dip.

Bouncing balls... and cubes?

A few weeks ago, I was getting antsy and wanted to redo intuition's web page with some sleek looking CSS, a web 2.0ey PHP backend and a Flash navigation interface. This might still happen, but not in the near future as we have other priorities... like making games. But around that time, I decided to give actionscript 2.0 the good ol' college try and with the help of the book I posted about on Friday.

While this isn't all the functionality I wanted with this little do-dad, I am pretty happy with the results, and with what I've learned by doing it.

Firstly, is the problem with rotating movie clips in flash. During the later stages, I wanted to be able to scale the movie clip to any size I want, and then subtract a relative value from the global variable: gBOTTOM in order to adjust the world bounds accordingaly, however the problem I encountered can be seen in the .swf below. Also note the jumpy bug was something I didn't care to fix since it wasn't part of the end goal.



While the movie clips in the above .swf are not circles, but cubes, the behavior is the same since the bounding boxes are always rectilinear, no matter what shape lies inside. While it sort of makes for a neat animation of squares, I wanted circles, so the code looked something like this in order to get the radius of each circles.

//ROLLING CUBE BOUNDS

if (this._y >= gBOTTOM - this._height/2) //bouncing upwards bounding relative to size
{
this._y = gBOTTOM - this._height/2;
this.ySpeed = (-this.ySpeed)/2.22;
}

This really didn't work, since the resting point was so sporadic, the circles didn't seem to hit the ground most of the time, but rather float. In this case, I conceded what may have been a victory and reverted my code back to using constant bounds for constant sizes of balls.



Next for this would be collision (and reaction) of all and any balls, and Mike, who has been helping me throughout this, mapped out what that would take, and it looks terrifying. While adding collision detection and reaction to this would be stunning, I think I may tackle that once I get at least some OOP experience under my belt.

Meanwhile here is the code for the entire rollingcubes.swf heavily edited from it's original form as the first lesson in Chapter 10 of the book I'm using from Friends of Ed "Foundation Actionscript for Flash 8." The code all lies on frame 1 of the .fla and if enough people want the .fla I'd be happy to post it, however I doubt this will arouse much interest.

//BOUNCING BALLS SANS COLLISION

function mover():Void
{
this._x += this.xSpeed;
this._y += this.ySpeed;

if (this._x < wall =" 1.22" _x =" gLEFT;" xspeed =" -this.xSpeed/1.22;"> gRIGHT) //bouncing off right wall = 1.22
{
this._x = gRIGHT;
this.xSpeed = -this.xSpeed/1.22;
}
if (this._y < gravity =" 3">= gBOTTOM - this._height/2) //bouncing upwards
{
this._y = gBOTTOM - this._height/2;
this.ySpeed = (-this.ySpeed)/2.22;
}
if ((this.ySpeed <= 2) && (this.ySpeed >= -2)) //clamping the vertical movement
{
this.ySpeed = 0;
this.stop();
}
if (this.xSpeed < -0.5) //friction on leftward movement
{
this.xSpeed += 0.5;
}
if (this.xSpeed > 0.5) //friction on leftward movement
{
this.xSpeed -= 0.5;
}
if ((this.xSpeed >= -0.5) && (this.xSpeed <= 0.5)) //clamping the horizontal movement
{
this.xSpeed = 0;
}
if (this.pressState == 1) //stop everything while pressing
{
this.ySpeed = 0;
this.XSpeed = 0;
this.lastX = this._x;
this.lastY = this._y;
this.stop();
}
if (this.pressState == 2) //link the rotation with the horizontal speed
{
this._rotation += this.xSpeed;
}
}

function dragster():Void //use on press, drag the balls around
{
this.pressState = 1;
this.startDrag();
}

function dragsterOff():Void //use on release, vectors for launching the balls
{
this.pressState = 2;
this.stopDrag();
this.xSpeed = (this._x - this.lastX)/3;
this.ySpeed = (this._y - this.lastY)/3;
this.play();
}

//WORLD BOUND CONSTANTS & STATES
_global.gLEFT = 83;
_global.gRIGHT = 550;
_global.gTOP = 5;
_global.gBOTTOM = 400;
_global.pressState = 0;

//apply event handlers to movieclip instances on the stage
bigBall.onEnterFrame = mover;
bigBall.onPress = dragster;
bigBall.onRelease = dragsterOff;
bigBall.onReleaseOutside = dragsterOff;
medBall.onEnterFrame = mover;
medBall.onPress = dragster;
medBall.onRelease = dragsterOff;
medBall.onReleaseOutside = dragsterOff;
smallBall.onEnterFrame = mover;
smallBall.onPress = dragster;
smallBall.onRelease = dragsterOff;
smallBall.onReleaseOutside = dragsterOff;

Should We Turn to Advergames for Flash Game Development?

Gamasutra posted a great opinion article today from Magnus Alm of Swedish developer Muskedunder Interactive entitled Why The Game Biz Should Turn To Flash.


He beings by explaining why the Flash game industry has seen a lot of growth lately:
• The upward economic trend within the games industry in general.
• Advertisement agencies realizing the need for skilled game design competence.
• A growing online and casual games market.
• And let’s not forget that flash games now are being ported to other platforms.

He then states that those with decent-sized marketing budgets are taking notice of the games industry and using online games as a means to sell their brand. He's referring to advergames here. This avenue can be a very lucrative path for many companies. There's a danger that lies in doing this kind of work, though.

First of all, you are selling out to a certain degree. Now, that's ok, especially if there's no other option for a newbie developer (like us). But as a developer that is essentially doing games as work-for-hire, you have to always be aware that you are at the mercy of your client and you can't just drop everything to go start working on your next artistic masterpiece of a game.

You also have to make sure that whatever you're making is targeting the market that your client wants. This is really a problem that will occur for almost any kind of external funding. With advergames, though, the client will be very adamant about this. Otherwise, what's the point of the game?

Magnus then proceeds to talk about Asia. The online games market in Asia is growing and lucrative. However, it should be noted that the Asian market is incredibly difficult to get into. Between piracy, different market expectations and tastes, and other random cultural barriers, finding success in the Asian market is the exception, not the rule.

The next sections seem to be the most intersting though: finding a path to console development through Flash and exploring new revenue models. He states that the major consoles, plus soon to be the PSP, have or will have download services where players can download games via the internet. He lists Alien Hominid and flOw as examples of games that started out Flash and ended up on consoles. That happens to be our strategy, too. It seems to be a great idea. For revenue models, Magnus mentions the Korean model of free-to-play with microtransactions for non-gameplay items. It seems to be a successful model. In fact, that's our current model for the multiplayer version of Dinowaurs.

In the end, most game developers want to get to the point where they can make the kinds of games they want as soon as possible. There are many ways to get there. Are advergames a good one? Maybe. Just make sure to always be aware that you are working for your clients, not yourself. Alternatives to advergames are out there; those will be discussed later.

Learning to Flash

Intuition has spent a lot of time working on ideas, writing them into pitches for places like Adult Swim and Kongregate, (my user name is: aeiowu) but we haven't had a chance to really flex our development muscle as of yet. So while doing all this "scholarly" writing and whatnot, I've taken on the task of learning actionscript in hopes of helping out the prototype situation later on.

I normally like to learn things on my own, or through the interpipes somehow, but Josh did some research (he's learning, or relearning actionscript as well) and found some promising books for designers who want to code, rather than coders who want to learn a new language. Call me fickle, but I need a book from an author who knows how to relate to me, and given I have more of a design background, is working out very well.

I'm through the first ten chapters at the time of this post, and am working on my own programming problems with the help of Mike. I have made a couple "cool" demos from the tutorials in the book and my own marginally customizable "particle system" (just using the x and y scale of a movie clip). The particle system is really just a jiggly sphere, but the lesson I learned here was how to control the parameters of a function outside of the function itself because I built the function so guidelines could be applied when assigning the function to each movieclip.

function bubbler(thing:MovieClip, jitter:Number, size:Number):Void
{
var xVal:Number = 0;
var yVal:Number = 0;
onEnterFrame = function()
{
xVal = (Math.random()*jitter) - size;
yVal = (Math.random()*jitter) - size;

thing._yscale = yVal;
thing._xscale = xVal;
};
}

//Initialize
bubbler(blob_mc, 22, 222);

Getting my failures out of the way

Hi! I'm Greg

I've been playing games for a long time. I remember the introduction of the Prodigy internet service, the rise and fall of Sierra games, and a jaw-dropping incident with Pong at an uncle's house. Today, I am studying graphic design at Iowa State University, with a heavy emphasis on game development. While ISU doesn't offer a game-dev major, a few classes do help with networking like-minded individuals towards a common goal. Combine that with 3D modeling & animation classes, a background in english at the University of Iowa, and a pretty solid design education, all that seems to be missing is the programming. This blog isn't about any of that though, at least not directly. Instead I will share some of the information and misinformation I've gathered over the last 4 or 5 years with all of you guys, and then once that's over with, which will be soon, I'll post documentation, process and maybe even some tutorials.

So here are some simple lessons that ring true for just about everyone trying to get into this industry at this age (college aged and younger) without much experience.

Make games, don't play them
Sure, you wanna play games, and you should, but game development has nothing to do with high-scores or head-shots, and everything to do with a passion for creation.

Start small
Use flash, Torque game builder trial version, Multimedia Fusion or something like that to prototype your first simple game idea. Make checkers or breakout, you'll learn a lot. If you want to break into the 3D realm, make a mod with the SDK of an existing engine, half-life unreal tournament 2004 and etc.

Sell-out
At least a little bit. You still have to make compromises about your ideas. If you don't have to make compromises, then you're either a rich programmer/artist and don't need funding or you'll never get your game past pre-alpha due to the scope being larger than SPORE and you not budging on any of your ideas with your team members .

Work like crazy
The harder the work, the more you will learn, the better you will be. This industry is not for the weak-willed and throws a ton of obstacles in your way of becoming part of it.

Focus on your craft, prepare for rejection
After a year or two, you shop your stuff around and nobody likes it, keep going. After 5 years, find a different craft, or a better way to do it.

Do it yourself
With nearly all the jobs in the land requiring 2-3 years of experience with a AAA release under your belt, it seems like you're staring down the business end of a catch-22. And you are. However by working on your own portfolio, in small projects and in unfunded teams, you can overcome this gap by investing your time into all your failures. Or better yet, go indy!

Fail first
Failures are a necessary and important part of learning how to develop, especially with such a technical art form, skills are constantly improving, as is software and tools. Learning how to structure a project, gauge feasibility and beyond, are all huge parts of a project's success, and by getting them wrong without anyone footing the bill for it, you'll do your career and your would-be publishers all a favor.

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.