Wednesday, August 17, 2011

What would be the point of having developer's blog, if there wouldn't be anything on programming. Oh yeah, that's where the things got hot. This is where it works, this is where it fails.

Since launch of the SDK, probably lots of people started struggling with that fancy scripting language - AngelScript. I remember I did. Experienced some successes, failures, helped finding some bugs, worked my way out through this language, started appreciating it, started even liking it (now I see it was indeed quite a good choice). That's why I think we could from time to time talk about scripting in FOnline SDK, talk about the AngelScript, share some common pitfalls, solutions that worked out good, and even the ones that weren't.

Of course basics of angelscripting is required, there won't be any tutorials whatsoever.

Objects

Blah blah blah, everything you can model in your OO language is an object, yeah, we already know that and it sucks (I'm getting a little bit off topic right here). Ok, it does not suck, in fact we're gonna often rely heavily on that fact, and we're gonna put large part of our logic into objects. And we're gonna tie those objects to the in-game objects (critters, items, scenery, maps, locations).

Say we've got a class for objects that are gonna make us some nice abstraction layer over default item functionality:

What's going on here? We wrap an item type in some class, and we're adding some useless code to operate on it? Why the hell would we want it? Well, think about the interface you've just gained and you can use throughout your scripts. You may now call: something.Bar() instead of item.Val0++, which shows what you want to do, and not how are you going to do. That's the difference if you want to write good code. Less imperative, less verbosity, less bugs (yes, I know that example suck, and you would want that for far more reasons - think about having some additional data, that's not stored on the wrapped item, but it's one of the class' fields - it's not saved anywhere, but still may be useful).

Wait, did someone say interface?

interface ISuperFoo
{
void Bar();
}

Oh great, now we've got the interface that allows us to call Bar(). And we don't even know what's called in the implementation class (in fact, we don't care, this is what interfaces are for).

So far so good, but FOnline scripting engine works in a way, that you can attach your functionality to the handlers for default events.

Let's start of course, from creating an object. If we want to attach it to the item, we need to do this in the item_init handler.

Yeah, whoops. We're gonna loose the reference to the newly created foo object as soon as we leave the function. Unacceptable, we need to store it somewhere.

Object Managers

This is also common solution. If you've got many objects in your program, you need to manage them somehow, store the references to them, maintain their lifetime, give the references(via interaface) to those interested.
We're gonna use basic generic array type for that.

Oh what a horrible piece of code we've just made. Yes, we've got our array, and function to add an object for an item (which we can use in item_init) and get the interface of such object for existing item. But there is that horrible loop in GetFoo, we need to scrap that. The best would be, if we could perform fetch with direct index to our array. We can do that, if we're able to store the index, at which our Foo is located in the array. Let's store it in Item::Val1 field:

So, we're now adding our SuperFoo object every time we call item_init, and we can fetch it in any script module (any module that imports this function of course), by obtaining an interface, that's not coupled in any way to the implementation class, nor coupled to the item object. Nifty.

Donate!

We are working in our free time on FOnline, we don't get paid and FOnline will never become pay-to-play. But running the server costs money. So, if you like the game and would like to support us, we would be very happy if you could donate some money to keep the server running.

Amount:

Currency in:

Powered by Online Quest.

About

"FOnline: 2238" is a Fallout game based on the FOnline engine. Currently, it is only available in English.

The game is set in 2238, 3 years before Fallout 2. The world has been expanded and includes both the Fallout and Fallout 2 game areas.