SpindleyQ's picture

My non-KotMK wrecking time lately has been going into a SECRET PROJECT.

The vision? A game-making tool, built to allow realtime collaboration between designers (think Sauerbraten but 2D and with K&P-like rule-editing), and useful collaboration between designers and programmers (the idea being that programmers can tweak the editor and scripting language to accommodate the kind of game you're making).

As you can imagine, this, uh, isn't a small project. But I won't be happy until it exists, so I'm working on it. There's nothing up on the screen yet, unfortunately, so I don't even have a cool screenshot to show off. I've been concentrating on the data and scripting models, instead. You can comment if you're interested in helping out, though.

Anyway, remember: SECRET.
Don't tell anyone.


kirkjerk's picture



peer to peer or client/server? what technologies?

SpindleyQ's picture

The idea, technologically,

The idea, technologically, is that I build the game engine, build the editor on top of the game engine, then build netplay into the engine. Thus will the editor gain collaboration support for relatively cheap.

My current plan is client/server, with perhaps some peer-to-peer sprinkled in later if latency gets too bad for netplay in general. You'd set up a server, like a svn server, that just ran all the time, and whenever you wanted to work on the game, you'd have to connect your editor to the server. No "work offline then merge"; I've been working on merge at work for like a year and I don't want to write another merge algorithm right now thank you. (Your merge problem is much different in the realtime/netplay world because the server can just pick someone to "win" -- you and I both trying to change the same line of code at the same time is the same thing as you and I both trying to pick up the same health pack at the same time. One of us just straight-up does it first.)

I was planning on using XNA (and thus C#) and porting to SDL .NET for Mac and Linux support, but then I looked more closely at XNA and it kind of rubbed me the wrong way in terms of what the framework took care of for you (you don't have very good control over when update and draw get called) and what it didn't (you get no notification of state changes of the joystick), so right now I'm using SDL .NET and maybe porting to XNA and/or Silverlight later.

Are you cool with C#, proper Hungarian notation, writing some scripty code in JSON syntax until we've got an editor off the ground, and the concept of coroutines? If so, you are eligible for getting in at the ground floor!

Also, you didn't ask, but although I am obviously planning on sharing this delightful beast with my friends here at Glorious Trainwrecks for free, I am much less sure about its eventual freeness in general. Thus the secrecy.

kirkjerk's picture

Heh. I uh... know Java. Can

Heh. I uh... know Java. Can deal with proper Hungarian I think -- in the sense that you only use it when you have different representations of the same concept...
JSON syntax, heh. and I uh... read the wikipedia page on coroutines.

Ugh, I dunno -- most of my projects of this ilk have been independent things, I haven't done non-work dev team collaboration. It sounds like at is heart a lot of this might be a one man show? But I'd be willing to help out as it seemed useful...

SpindleyQ's picture

Well, I mean, I have a

Well, I mean, I have a fairly concrete vision for what this thing is, so in that sense it's sort of a one man show. Perhaps volunteering will be more fruitful once the groundwork has been laid? A lot of effort is going to end up having to go into defining and implementing scripting commands, which is maybe a better floor to get in at than the ground floor.

Re: Hungarian, I think you have it backwards -- it's very important when you have different concepts that are represented similarly (see Joel). Though in practice it's actually very useful to use everywhere, as it forces you to be very precise about what you're talking about -- surprisingly, initial crypticness is hugely preferable to vagueness. But this is probably a discussion for email, if you're actually interested.

Re: Coroutines, okay, so imagine a section of script for an adventure game. It might look sort of like this:

  say("I'm Guybrush Threepwood, mighty pirate!")
  walk([200, 124])
  say("So don't you fuckin' fuck with me, motherfucker!")

You can't write code this way in C# or Java, because this is merely one simple thread of logic that has to go on. While Guybrush is walking, other animations can be playing, the player might hit F5 to bring up a save-game dialogue, he might hit ESC to skip this cutscene, you've got to draw the screen 60 times per second, maybe you're ticking down a timer to interrupt this scene with another cutscene, whatever. The game world should still be alive while Guybrush is walking, and other scripts should be running. If "walk" is a function call that only returns when Guybrush is done walking, in a non-multithreaded environment, we're fucked. However, A) shared-state threading is something that is incredibly dangerous and that you absolutely do not want to make designers suffer through, and B) you can't start threads for every little object running scripts in your game; there could be hundreds or thousands doing piddly little jobs, and the overhead would be enormous.

What many games do is punt; they say, "here's a function that gets called sixty times per second; keep track of your intermediate state yourself." So you have to build a state machine where, after you finish walking, you set some bit, and then the next part executes. It's hard to understand and harder to change without breaking. For adventure games this is particularly ridiculous, but I believe it's a tremendous waste of effort in a lot of other situations, too.

So instead you say, I know exactly when I want to wait for something to happen; that is the point at which I want to stop running this script and start running the next script. When that thing happens, we can wake this script back up at our leisure and let it do its next chunk of work. This way, you keep context switches down to an absolute minimum, you can run umpteen million scripts, all written in a natural style.

Doesn't that sound nice? I think it sounds pretty nice. Thus far, using these ideas in practice (with Hax0r and Alien Zit 2000 being sort of trial runs at the engine, using Stackless Python instead of rolling my own interpreter as I'm doing now), it's been pretty nice. So, that's where that angle's coming from; it's a fundamental part of my scripting model.



kirkjerk's picture

I think I try to get some of

I think I try to get some of the advantages of Hungarian with bigHonkingHugeVariableNamesThatSayWhatTheyreAllAbout.
though that might be missing some of the "smells" aspect