Drywall: The Game!

Raph Koster has been very high-profile recently, ’cause of his newly announced system Metaplace, plus a guest post on Penny Arcade. In particular, he posted a write-up for a construction MMOG, and wondered if drywalling could be made into a fun game. When a respondent (named Peter S.) suggested a way, he became excited and challenged me to prototype it. Well, he challenged his readers, but since rapid prototyping of small games is my super-power, I stepped up.

Play now!

Click on the ‘Play Now’ text to play the game right in your browser!or you can

download the ZIP file here.

posted a write-up
Play now!
download the ZIP file h…

Things that get me steeeeeeeamed!

Lisa Laughy has posted about her experience as an older woman trying to learn in a game development school.


This kind of thing gets me STEAMED!!
I am totally on Lisa’s side. As a game industry vet, and a 41yo male, I’ve seen more than enough to support her assertion that the industry 1) is sexist (and racist and age discriminatory, too), and 2) engenders a hacker-boy ethic, which excludes anyone not a young male.

If people believe that it’s just merit-based, and Lisa simply couldn’t hack it, then they don’t have the experience I have. I’ve personally seen:

– management holding critical meetings at strip clubs

– male-dominated offices with bikini posters on the walls and porn wallpaper on the desktops

– Locker-room humor, drawn and written on whiteboards throughout the shop

– female dev team members teased about their sexuality.

Is anyone aware that Dona Bailey, who created CENTIPEDE, was so scarred by her sexual harassment that she left the industry and didn’t return IN ANY WAY for 25 years?

And that the original Sims team was 50% female, which is the only reason children were designed into the game?

And these game development schools are just giving the industry what it says it wants.


The entire time my wife was in law school, I worked at Acclaim Austin, and she said she couldn’t wait to be a lawyer to sue the pants off that company, and it’d be easy, too. I think a nice big age- and sex-discrimination lawsuit may be just what the game industry needs to wake up.

In the mean time, perhaps someone could create a consortium of female devs, and take advantage of the strengths of that dev group to come up with something new and exciting.

These kids today!

I wandered down to the University today, and joined some students in the game development lab. They were part of a team of 12, and they were working together on a 2D RTS+avatar game. They were young, smart, hard-working, and totally my tribe, and I thought my time was well-spent. However, after I left, my mind began digesting the experience, and a new feeling began to creep over me.

I was appalled.
Not at the kids, of course, but what they were learning.

First, they are learning that game development takes place in walled gardens, where "security" is an everyday hurdle. You have to have all the right licenses, and belong to the right user groups (or corporate "clubs"), and your dev machines have to be registered with all the right software. I know that many MMO developers are railing against walled gardens, as applied to MMO systems. But at the same time we’re seeing MSoft and other companies working hard to make development itself into a walled garden situation. I’ve talked with so many developers who speak well of C#. When I point out that C# is part of MSoft’s "Embrace and Extend" policy, and that Sony, Apple, Nokia, Linux, and Nintendo have no intention of seriously using C#, they always say, "Yeah, but it works so well…" Exactly.

Second, they are learning that game development happens in large groups, where each person tends to his or her tasks, and few of the team members have real ownership over the project. If it doesn’t get done on time, well, they get points for having tried. The professor wants to give the students "real-world" experience, and the developers tell him "big teams" and "task structures", so I’m not surprised about this. But I saw a bunch of students who were working together on a fairly quixotic task, and few of them seemed eager to talk about personal game projects, or show me what they had done in the past. My lone-wolf style is probably coloring my discomfort about this, but I can’t say here and now that this teaching choice will hurt them in the long run.

Third, they are learning that game development is about dealing with That One Little Thing (see my blog post, http://thomr.eochu.com/article.php?story=20071008205323104 ). They were spending almost all of their time getting their middleware (.NET and TorqueX) to do what they wanted, and very little time making the game itself. I guess That One Little Thing is INDEED a major part of many developers’ work day, and (as I said) they’ll have to deal with That One Little Thing no matter what tools and tech they choose to explore. Still, it appears that big developers like MSoft are working hard to provide cadillac software to the classroom, when these kids probably need to learn on hondas. Yes, you MUST use .NET in order to develop for the XBox360, but was it wise to give 360s to the kids as target environments? Yes, I’m sure they WANT to make games for the same box they play retail games on, but why saddle them with all that complexity right up front? Do we give art students complex and expensive tools right away? No! We give them pencils and paper.

However. I need to remember that these kids aren’t total newbs. They’ve been through several semesters of computer game classes, and they’re certainly bright enough. In the end, those that wish to will find their way into the industry, and hopefully they will be and have positive experiences. It’s possible that I’m just reacting to the vast difference between my early game development experiences and theirs. But I wish, for everyone’s sake, that they could create their art

1) with total control of their vision,
2) with free tools that make finished games that everyone else can enjoy, and
3) with tools that let them make the game, not fight the middleware.http://thomr.eochu.com/…

Game Test: Truck Racer

A couple of nights ago, for some strange reason, I felt the need to build a little physics engine. A little extra work, and I’ve got a simple arcade racer!

Play now!

Click on the ‘Play Now’ text to play the game right in your browser!The engine in question is called a ‘Verlet’ engine, or spring-based physics. The first thing you hear about such engines is that they require Calculus for the integration step. Calculus! Ooohhh, scaaaary!
Don’t be scared. Yes, to do it right, and competely, you need to accelerate your points * time * time, but if your time step is always 1, it gets much simpler.
1) make some points. I made four, in a box configuration. Make them in absolute space. Don’t make them at 0,0 and expect to translate them somewhere later.
2) make springs between each of the points (so, 6, for a box). These springs are just defined as the points they connect, and the normal distance between these points (called the ‘rest’ value).
3) copy the points to the pointsLast array, so you keep a record of where the points were last frame.
4) copy the points to a temporary pointsNext array, and do all the following operations on it.
5) move the points by gravity.
6) move the points by any controls you want, like gas and brake.
7) move the points by acceleration, that is, move them by the difference between last frame and this frame. This system doesn’t have any speed vectors, as you might assume. Instead, the speed of your car, boat, plane, or ball is implicit in the frame/lastFrame relationship. You can add air friction here too, if you want.
8) detect collision with the points and the ground. If a point is below the ground, simply move it up to the surface of the ground.
9) for each of the springs, compare the rest state with the current distance between the two points. If the two points are farther than the rest state, then pull them towards each other. If they are closer than rest, the spring is compressed, and will push on both points.
This is easier than described; here’s my code:

	// apply spring forces	LOOP(g,0,5)	{		double dist = Distance(blockNext[springArray[g].index[0]].x, blockNext[springArray[g].index[0]].y,	                          blockNext[springArray[g].index[1]].x, blockNext[springArray[g].index[1]].y);		double ang  = atan2(blockNext[springArray[g].index[1]].x - blockNext[springArray[g].index[0]].x,	                       blockNext[springArray[g].index[1]].y - blockNext[springArray[g].index[0]].y);		blockNext[springArray[g].index[0]].x += sin(ang) * (dist - springArray[g].restLen) * springPowerCoeff;		blockNext[springArray[g].index[0]].y += cos(ang) * (dist - springArray[g].restLen) * springPowerCoeff;		blockNext[springArray[g].index[1]].x -= sin(ang) * (dist - springArray[g].restLen) * springPowerCoeff;		blockNext[springArray[g].index[1]].y -= cos(ang) * (dist - springArray[g].restLen) * springPowerCoeff;	}

Be sure not to use a springPowerCoeff > 0.5, as that’s unstable.
10) finally, copy the current points to the last points, then the next points to the current points, and the frame is done.

Here’s a Java implementation that looks neet:
http://www.sevenravens.com/landsailing/XSpringiesViewer/jspringies.htmlPlay now!

That One Little Thing

Mostly I use all my own technology. My engine is written on top of DirectX 8, so you could say I’m using DirectX 8 instead of my own stuff, and that’s true, but beside the point.

The point is, I’ve avoided a WHOLE lot of middleware over the years; Quake, Ogre3D, Gamebryo, Multiverse, Torque, Renderware, etc, etc, etc. Why?

Because of That One Little Thing.

Learning a new…computer language is easy. I’ve only started working with PHP and LUA in the last few months, and the syntax and structure are so close to C/C++, the difference seems trivial. The real problem is when you start using someone else’s code, and run into That One Little Thing.

"Oh, no, you have to call function A *before* function B, otherwise some internal system variables won’t be set properly. And you *have* set up the ProcessExBlather tree, haven’t you?"

"Of course that’s documented, in Addendum 16 of the Rev2.3.4 docs. You have that, right? Wait, I guess that’s not actually in there. Well, anyway, just look at *our* code for the right way to do it."

I’m actually painting a rosy picture here, because it’s not normally easy to actually *talk* to one of the developers of the middleware you’re using. Typically your resources include

– a forum for developers like you, who might know what you’re talking about, and might choose to look at the forums once in a while

– a manual, which is always incomplete, out of date, and shallow, by definition

– a few demo projects, never well documented and over-complex

– other people on your own team who are further down the road of That One Little Thing than you are.

But we soldier on, and indeed, That One Little Thing is just a hump to get over. As frustrated as we can get, as troublesome as That One Little Thing seems when we’re tripping over it, we *do* get over it, and can *usually* achieve what we want. Sometimes we can’t, and then we’ve wasted so much time we feel like crying, because we have to explore some other middleware full of a completely different set of That One Little Thing.

And That One Little Thing is a hole we dig ourselves into. The opportunity cost of overcoming Those One Little Things of one set of middleware is the time we could have spent digging past That One Little Thing of another set of middleware. As a result, we try to stick with the middleware we’re most comfortable with. I’ve been hanging out in a small shop that’s stuck on Torque. They’ve been using it for years now, and even though they don’t get a lot of support, GarageGames keeps changing it on them, and the future of GarageGames is in doubt, they’ll probably continue to use it for the forseeable future, simply because they’ve gotten past most of That One Little Thing Torque has.

Most dev shops understand about That One Little Thing, and won’t try to work with new middleware unless they can get somebody else to pay for it. That’s not hard, because publishers often buy middleware licenses (based on what they think it can do) and then demand that their developers use the middleware. As a result, developers can get stuck on middleware *and* the publisher that holds the license to that middleware.

Edge of Reality is one of the few developers that uses a homegrown engine, and plays well with all the big publishers. As you might expect, their engine and toolset is *very* good, and *very* complete, and they spend a great deal of resources keeping it that way.

When a dev shop commits to some middleware, they often send one of their best engineers down to deal with That One Little Thing first. Then, as the rest of the shop comes on board, they have a local "expert" who can help everyone else with That One Little Thing.

Game artists are just as cognizant of That One Little Thing, but they don’t usually have the choice of creating their own tools, and they most keenly feel the effects of knowing That One Little Thing about the wrong middleware.

But there are a *lot* of people in the industry who don’t get it. They think that any middleware is good and immediately useable, otherwise it wouldn’t be sold, right? So if their dev team takes too long to get up to speed with it, the dev team must not be very good, right? Are my scars showing?


I guess what I’m trying to say here is, the real cost of using someone else’s code/system/tool isn’t found in the manual, or on the forums, or on a check. It’s That One Little Thing. And like sailors and the Sea, if you don’t have respect for That One Little Thing, no developer will have respect for you.

What would make you "live" in a game space?

I’ve got a lot of good assets that I could turn into a 3D game where you hunt zombies in mazes. My vision is both visceral (splattering zombie fluids spray the walls) and strategic (I want complexity and depth). Ultimately, I want a game that’s very "sticky", that players want to keep coming back to. I want players to feel like my game is a place they enjoy "being" in.

If the game was about battling zombies in hallways, what would make YOU want to come back again and again? Here are some individual ideas; please comment and add:

– complexity. endless tunnels of different types, many different monster types, many different weapon types.

– a huge backstory. A deep history of the place. Find books everywhere, which detail the game history. Special places, that you can go to, that are mentioned in the books.

– a realistic and/or historical setting. Aside from the whole zombie thing, everything is correct. Buildings have bathrooms. Real posters on the walls. No alternate universe "Nazis won the war"-type things.

– a player community. An active forum, weekly contests, fan fiction, leaderboards.

– creativity within the game. Complex crafting of weapons and ammo.

– creativity to enhance the game. A level editor. A monster editor. Editable scripts for monster AI and level creation.

– accessable developers. Weekly dev chats. The devs implement suggested changes, or tell you why not. In-depth developer diaries.

– development "life". The game gets regular revs. The developer commitment is total. Never any question that the game will continue to grow and get better.


Excellent game analysis

It VERY rare that I find game analysis like this: In two major pocuments, John Harris (http://www.gamasutra.com/view/authors/1027/john_harris.php) succeeds in showing how to review and study games.


These two long articles are …amazing in their depth, and cohesiveness, but what I really love about them is the attention to the history of video games. I’ve complained before about young reviewers who give terrible scores to games, simply because they don’t understand the history and/or genre of the game (Chocobo Dungeon, anyone?)

Harris shows that he knows all about the games he’s detailing, including their history, and cultural and geographic history, too. On top of that, he’s very up-front about what he’s played and what he hasn’t, which is refreshing.

It looks like these are the first two in a series, and I hope he keeps at it.http://www.gamasutra.co…

Chagrin Falls

My wife and I are going out on this fine day to see Chagrin Falls, a very pretty upscale suburb of Cleveland. Upon Googling and so forth, we find that Bill Watterson, the cartoonist of Calvin and Hobbes, lives there!

There are no C&H museums or anything; word is that Watterson is intensely private, and would not appreciate us stalking him. So we’ll just go for the falls and restaurants. Honest.

Zombie Vs. Ambulance!

For years, the Japanese game market has seen a line of budget games called the Simple Series:

One of the latest, only available in Japan, is a game called Zombie Vs. Ambulance, and the title sez it all.
Drive through the city, squishing zombies and rescuing citizens.Here’s a link to a YouTube page that showcases the Simple Series games:

Now, I just created a little madlibs tool to help spur my creativity, and Zombie Vs. Ambulance certainly sounds like the kind of title you might get from such a random matchup system. The Penny Arcade boys used to have a Baby Vs Rhino t-shirt; kinda the same wacky theme.

But I’m not at all sure that finding creative mashups like these will guide me towards anything groundbreaking. I’m starting to think that, to be really groundbreaking, I have to come up with new verbs, things to DO in the game that no one’s ever thought of…http://en.wikipedia.org…