Prev/Next Blog
by date

updateMove in script

Name:	Ian Omroth Hardingham
Date Posted:	Jul 17, 2008
Rating:	3.5 out of 5
Public:	YES
Comments:	YES
RSS Feed:	or Subscribe with .
Profile Page:	View profile page for Ian Omroth Hardingham

Blog post

Hey guys.

In my spare time away from Mode 7's other activities I'm working on a new swordfighting game which is a follow up/divergence to Determinance called Guile. I'm going to be semi-announcing Guile this weekend so everyone can play the beta if they want to (unlike Determinance, Guile is in semi-open beta. Also, anyone who's bought Determinance gets full Guile for free).

But that's not really what I'm here to talk about.

I find that when you're prototyping game ideas, the most important thing for me is to make the process as easy as possible. I know that sounds absurdly obvious, but every less thing I have to do to try out a new idea means one more I'll try before I get tired and go get a beer. Obviously, one of the main powers of script is to allow easier prototyping.

I'm sure I'm not the first to do this, but I'm doing all of my Player::updateMove logic in script, only needing to go into c to expose and send new members over the wire. I've found it makes the entire process incredibly nicer and easier, and also forces me to generalise new mechanics more in the first place, to make them easier to play around with.

I'm even considering having a script interface for declaring net-sent members with type and what kind of transmission they need (are they part of the priority player ghost packet or just sent to everyone through packUpdate), but I probably don't need to do it often enough to make that worthwhile. I remember Melv and people talking about this a long, long time ago... don't know if they ever got anywhere with it.

I'm sure that the performance will be an issue on lower end machines, but converting it back into c for release should be very straightforward.

Anyway, I wanted to put this idea out there to see how many other people are doing it, and to suggest it to you if you're working on an innovative game. Take it from someone who's been innovating too much in the last five years - this has seriously helped me.

Ian

Recent Blog Posts

List:	07/29/08 - anyone else at Develop? 07/17/08 - updateMove in script 06/20/08 - A call for help to Germany 04/23/08 - Divorcing from TGB in search of nicer TATs 03/01/08 - The best delivery I'll ever receive 01/31/08 - Call for help from Italy 02/23/07 - Determinance Cloth Pack 02/15/07 - Determinance Released

Submit your own resources!

Devon Winter (Jul 17, 2008 at 16:55 GMT) Resource Rating: 4

I like this post because it touches on a slightly larger topic that we all struggle with -- what to script and what to code. Always makes for an interesting discussion. I absolutely agree that when you're trying to innovate, iteration is KEY, and anythiing you can do to make it easier to iterate is just going to be a plus.

That includes putting what might be considered core game logic, things like your move logic, into script. But I do think there are some considerations here.

For one, how much work do you have to do to get the logic into and out of script, versus just grafting it right into player.cc. For me, I'm actually more comfortable plunking around directly in the cc modules than in setting up the console methods and persistent variables to expose everything I want in script. That, and the lack of type in TGE's scripting means I sometimes find myself spinning my wheels fixing stupid typos than iterating over design ideas.

But I do think there's quite a bit to be said for setting somethings up in script as well. One of the things I ask myself is is this something I think would want to be handed off to a designer at some point, rather than always maintained by a programmer. So, for instance, all my AI logic is built in script code. I want the AI code to be flexable and expandable, and more importantly, I want a designer to be able to modify it at some later date without engaging a programmer. This makes it an absolute candidate for scripting.

And, as you alluded to (eluded?) -- it *does* make iteration less painful, and that's always a good thing.

btw, I peeked at Determinance, and it looks like a great game. Good luck with Guile!

Ian Omroth Hardingham (Jul 17, 2008 at 17:00 GMT)

Hey Devon, good to hear your thoughts.

I also used to feel more comfortable in C, and for the exact reasons you put. It just feels more robust and "trustworthy" somehow.

But after a lot of experience of script, I've been pushed in that direction by some things which are just ridiculously much easier.

The best example is anything based on time. Say you want to implement a double-tap dodge or something. In C you have to set up a timer to count up and a couple of state variables. In script is is *so* much easier... with schedule and the fact you don't have to declare or even initialise variables (any variable is "" before it's used, which evaluates to false, so if you presume that's it's rest state then you're good).

In the end, it certainly helped me to get less "worried" about things like typos and so on. I think I save more time than I lose...

Ben Garney (Jul 17, 2008 at 19:03 GMT)

Cool approach, Ian. That's really smart. What does the field definition interface look like? Did you have to expose a lot of additional methods on your player to allow you to handle everything in script?

Ian Omroth Hardingham (Jul 17, 2008 at 19:13 GMT)

Hey Ben, good to see you :)

Actually I didn't have to expose much that isn't very Guile-specific. I use get and setVelocity, obviously, and I needed to expose the surface contact stuff (runSurface, jumpSurface and so on), but that was really it. I think it's probably helped that we don't use *any* standard TGE animation stuff - everything is done using a new system anyway. But yeah, that's all done in script too.

Obviously I call my scriptUpdateMove function with an isServerObject and isThisClientsGhost arg, so you can choose what logic is done only on the server; predicted on the client and so on.

I haven't noticed a drop in performance, but I'm sure all the script vector ops are having an impact. The biggest annoyance is having to use VectorSubtract rather than being able to do something cool like

%v3 = %v1 vSub %v2;

I'm sure that would be pretty easy to set up, but I'm not really a compiler guy so haven't gotten around to it yet. Actually, that does make me think that it would be a lot faster to have a VectorObject (assuming the overhead on ConsoleObject isn't too bad) which holds the x,y,z coords so that I could really cut down on the string processing... maybe I'll look into that.

Jeremy Alessi (Jul 18, 2008 at 15:30 GMT) Resource Rating: 3

Good post. I think it's extremely important to iterate quick and expose as much of the engine as possible when prototyping. You can always move the logic into C++ when the mechanics are locked down if necessary.

You must be a member and be logged in to either append comments or rate this resource.