Felcode, the Magical Computer Language

I just played the demo for Hellgate: London, and as usual I came away with some inspiration. Not about the game, which seems fine (for what it is; Diablo 3). The load screens feature a lot of demonic symbols and magic circles and such, and I looked at it, and said, "Wouldn’t it be great if those symbols were computer code?"

What would it take to make a "magical" computer language, so that part of a fantasy game would be about casting and researching spells by writing a "program"?

What if those arcane symbols engraved down the length of your sword were actually source code, executing every time you stab a monster?

I’ve done some research over the last few days, and…I’ve learned a lot!

1) There are a WHOLE lot of academics who are much smarter than I, and who have delved deeper into the whole "making a language" thing than I ever will. For one thing, they’ve designed some radically different paradigms for coding (functional languages, Lambda calculus) that get a lot closer to the whole "provably correct" dream.

2) There are lots of fan sites out there for obfuscated code and toy languages, and plenty of interesting ideas. Stack-based? Any stack at all? Pointers? Indirection? Branch tests? Registers? Math? Types? It seems like anything goes, and anything works, more or less.

3) the challenge won’t be in building the toy language, but in not making it too hard to understand, while making it interestingly "arcane". I mean, if my target market is me and other hard-core coders, I could make anything I wanted. But arcane or not, I’m gonna want to make a language that neophytes can enjoy figuring out.

As an aside, I’ve found that it’s easy to help new programmers take their first steps. Learning about variables, and assignment, and program flow control, and "Hello World" is easy. And coding experts know that, even if we’re writing hundreds of thousands of lines of code, we’re still just doing those simple things many times. But new programmers have a giant conceptual hurdle; how to use those simple components to write meaningfully complex code. If I want to make the "magical" language easy for new programmers, I should try to concentrate on this.

Initially, I imagined creating a language (and underlying system) called "Felcode". I also imagined that, with a simple font change, I could recast it as an "alien" coding language, suitable for hacking computers aboard alien starships. Now, however, I’m convinced that I can make several toy languages, perhaps creating them all under the Felcode brand, but with markedly different characteristics.

I also imagined that, since Felcode would be inscribed on swords and wands, it would be entirely symbolic. Instead of a text editor, you’d get a drag-and-drop interface and whitespace would simply not be an issue. But, the symbolism could be spatial in some way.

Well, feel free to reply with your own thoughts about what would be cool in a "magical" language, and stay tuned for a prototype!

Love and Attention

My first real Indie MMORPG, Blade Mistress, was a profound learning experience for me. In fact, I’m still digesting its lessons.One of the things I’ve come up with lately is the principle of Love and Attention.

It’s actually not new; I only feel it’s new because I’m changing my mind about how to respond (as a designer, a developer, and as a person) to it.

Many people have…already discussed this in different words. Steve Pavlina of Dexterity.com is considered an elder sage in the shareware game community, and he said, "Releasing your product is the first step, not the last." He meant that you can’t just plop your product on your website and move on; you have to listen to your customers, keep upgrading your product, and thus build customer loyalty.

I’ve said many times that while my Blade Mistress players wanted to play the game, and wanted regular updates, they also wanted ME, my time and presence. I asked them which they wanted me to do, code the game or play with them, and they demanded both.

Several of my colleagues have come to the conclusion that, in the end, nothing matters for an MMOG except community, and they’ve managed to convince me they are right. If you accept that, then you realize that your game can have any form of currency it wants (gold, duckets, quatloos, whatever), but the real coin of the realm is players interacting with other players. And if THAT is accepted, then the GOLD STANDARD of the realm is players’ interactions with the developer.

And giving my time to a player really is something of value! They can go back to the community and gain status by saying, "I just talked to Techbear, and he sez…" They can post authoritatively on the forums, and gain status again. I’m not going to get into the whole developer-as-God thing; it’s not germane to what I’m trying to say.

Now, it’s a given that MMOG players seem to be much more vocal, energized, and possessive then devotees of single-player games. The common wisdom is that the multi-player aspect of the game facilitates greater communication between the players, which in turn forms a stronger community, which in turn creates the sense of ownership of the product, and vocal and energized follows naturally. But there are lots of little edge-cases that lead me to believe that this model is simplistic.

The original nethack was VERY single player, and each game was usually much longer than a high-score game should be. But, with a central score-and-save-game server, nethack has LOTS of devoted players who have formed a strong community. The game itself doesn’t have any real communication tools built in, so the users find and use other tools, like forums and IM.

There are any number of online communities for virtual model railroading. They are even platform agnostic (usually), but they take model railroading (real or virtual) very seriously, with lots of ownership. Again, the product itself doesn’t have the communication and community tools we now think are mandatory in a MMOG.

It’s also conventional wisdom that, all other things being equal, a strong live team and visible support by the developer will make a game more attractive in the long run than a game with no support and no forthcoming updates. It makes sense that, if a developer doesn’t want to invest further in the game, the player won’t either.

I think all of this can be wrapped up in the principle of Love and Attention. We can continue to assume that our game executable is a packet of work and functionality that brings pleasure to those who use it. Or, we can accept that we create boxes of Love and Attention that we sell, and players buy it, open the box, and enjoy that Love and Attention.

Even games that we give away, anonymously, to random download sites, still have an echo of Love and Attention that players feel and seek. In contrast, the storm of Love and Attention that a MMOG player receives can be overpowering.

Ultimately, we developers are producing Love and Attention, not just game mechanics and particle effects.

In some ways, this is a distressing concept. I (like most of us) am an introvert. I want to hoard my Love and Attention for my family and friends, and I don’t make friends easily. I don’t even WANT that many friends. I CERTAINLY don’t want too many people to be dependent on me for Love and Attention. I’m very facile with my compiler; not so much with the whole caring for other people thing.

They say that an extrovert gains energy from a crowded room; an introvert loses energy from it. Thus, most MMOG developers (quite naturally) hire extroverts to be "the face of the company", and they do a good job of giving Love and Attention to the players. But that doesn’t mean that the players will be satisfied. They still crave Love and Attention from every other member of the development group. Just as teen girls know every detail of every boy in the band, many MMOG players seek out personal (and private) information about every member of a development team, for the same reasons. This is a special problem for small developers; there’s less to hide behind.

Bands have dealt with this for a very long time, and (at least their producers) recognize that the Love and Attention they are selling is more lucrative than the vinyl. So they go on tour, go to signings, go on talk shows, and even sell private events for the girls with rich parents. We can learn something from this.

I myself was not expecting my Blade Mistress players to need Love and Attention, and I wasn’t emotionally prepared to give it. I expected that they would be perfectly happy enjoying my game and giving each other Love and Attention. I failed to recognize that 1) I was handing out Love and Attention whether I liked it or not, and 2) I could sell that Love and Attention, a great deal more effectively than I had been.

Embracing the principle of Love and Attention is challenging, and we can choose to ignore it. But for those that are emotionally ready for that commitment, it might be a valuable and lucrative new direction.

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.

http://www.gamecareerguide.com/features/435/i_am_a_game_school_.php

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.

Grrr!

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.
http://www.gamecareergu…

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.
Now, FOR EACH 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?

Anyway.

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.

Thanks!