This is Bananattack.

Minty chewing gum.

Posted by Overkill on January 25, 2009 at 2:10 am under Uncategorized

This week, I poured over some more scripting language stuff in LuaVerge. Monotonous work really, but it needed to be done!

As a result, LuaVerge is nearly done. I’m convinced it’s at about the point where it’s usable again.
I added a way to load from .vpk packfiles with Lua scripts. So now require statements will also examine packfiles for source code, meaning that things like vx, and peoples’ games can be packed away in a single file.

I might add override loadfile and dofile too, if it’s actually required, but I figure those are mainly lowlevel things, and most work can USUALLY be done by require. I guess if someone were using Lua as a file format for game data (like a database of items or something) as well, then you’d need to worry about this. I’ll take peoples’ input here, for those Lua users out there.
One of the biger things I spent time scratching my head over was binding Verge’s builtin variables. You see, Lua shoves in getters and setters for variables as functions. So at the lower level, to get the backend variable VC-style entity.x[ent], it calls v3.get_entity_x(ent).

However forcing people to call raw functions rather than assign variables, I’m told is annoying. So, I added support, through Lua’s crazy voodoo magic with metatables.

Since ‘variable’-style accesses to builtins are more expensive than their raw function calls, a bit of optimization had to be considered, to at least lower these costs. After all, the older LuaVerge had issues with speedy access.

This was a bit of a surprise to me at first, but also really neat, local variables have a much faster access time than global ones. Storing local copies of global variables gives a significant efficiency boost. Some report about a 10% lookup for globals, so imagine if it were a nested table of some sort. Caching variable lookups as much as possible would very much improve performance.

So using this knowledge and a few tricks, I think I’ve constructed a way to make fast lookups to LuaVerge builtins. I won’t bore or scare you with the details.

But if you insist, and are curious, all the work is in the source repository for Verge at with username “anonymous” and password “anonymous”.

Particular files to look at are:

So after all this, I started to repair the vx library so it’d work after the giant rewrite. Surprisingly, it wasn’t too hard to repair.

Why? Because vx enclosed all its source in a custom class system. Object oriented code made things compartmentalized and simple enough to refactor.

I made a simple vergeclass function that declares a class, and basically allows you to declare objects of that class after it’s been made.

You declare classes like this:

vergeclass "Thing"

(Whoa! no brackets around the function call? Lua lets you omit them for literals like quoted strings or tables). Anyway, after that point, there’s a globally named class called “Thing” which can be instantiated.

Constructors are declared like

function Thing:__init(a, b, c)
    self.a = a
    self.b = b
    self.c = c

And methods inside the class are sort like

function Thing:method()
    print "Hody2!"

Objects can be instantiated like this:

mything = Thing(5, 3, "tacos")

Their methods can be invoked fairly simply:


The downside, was the original system I had (before LuaVerge was rewritten) was horrendously inefficient, but it worked somehow. Lua is magical and allows you to horrendously hack things that just work.

Anyway, I revisited this code not because of this but for another reason. None of classes could be ‘extended’ or ‘inherited’ from, making the OOP limited. Granted, for vx, inheritance wasn’t necessary, and I didn’t really desire people extending the core objects because I’d much prefer composition.

Basically objects should as much as possible use “has-a” relations instead, and avoid “is-a” whenever possible, however tempting it is. It decreases coupling somewhat that way.
But I had other code, with Resonance’s sidescroller engine that I wanted to salvage. It used a moderate degree of inheritance, which given for free by luabind. Luabind being the thing that glued LuaVerge behind the scenes before we tossed it, and it came with a class system with inheritance… Anyway.

So I added a single-inheritance system to vx’s vergeclass so I could eliminate this old dependency and have working code again. This involved entirely rewriting the old system now that I understand the Lua library, Lua-based optimizations and metatables a lot better.

It was actually pretty enjoyable to overhaul the whole thing, and… weird. Metatables have some godly power to them. Anyway I finished, and even gave two methods of setting up inheritance.

I supply a temporary global function super(...) which must be invoked in a child class’s initializer to ensure the object inherits all the attributes that its parent class has. Later, I might enforce the call be made on every subclass just to ensure undefined behaviour won’t happen.

Now any time a method is called, it’ll look in its own class first, and failing that it’ll look in it’s parent’s class. If a class needs to explicitly call a method of its parent, it can index self.parent and use self.parent.method(self, ...).

So using the Thing example from earlier, the calls to create a child class are either this…

vergeclass("SuperThing", Thing) do
    SuperThing:__init(a, b, c, x, y, z)
        super(a, b, c)
        self.x = x
        self.y = y
        self.z = z

…or this, which I prefer because it looks like Python kind of:

vergeclass "SuperThing"(Thing) do
    SuperThing:__init(a, b, c, x, y, z)
        super(a, b, c)
        self.x = x
        self.y = y
        self.z = z

Either one of them reads “The class SuperThing is a child of Thing”. And there you go! Inheritance! Nifty! Sexy!

I even added one other thing! Properties. Other languages provide properties to declare pseudovariables with functions that are called when their values are accessed or mutated. I do similarly, through a bit of metatable magic.

Let’s take an example of a typical RPG player for a second, who has an HP attribute. To declare a property, you can go something like this:

Player._property('alive', function(self) return self.hp ~= 0 end)

You can then use the ‘alive property like a readonly variable, for instance on a player object named bob:

if bob.alive then print("We're still kicking!") end

I might expand this class system to allow multiple inheritance or mixins at some point. Not a high priority, but it’d be nifty!
So yeah, this has been my week. I’d love to hear about yours too! :D

Tags: , , , , ,

No comments (make one!)


Posted by Overkill on January 18, 2009 at 1:47 am under Uncategorized

School definitely crushes productivity, it’s true. But I figure it’s not all a waste. If school is consuming programming time, and some of it seems moderately interesting to me, why not post a Gruedorf about it anyways?

For my Game Development class project, I taught myself some basic 3ds Max stuff this past week so I could start to make some simple lowpoly 3D models. Here’s a start of the model I’ve been working on so far!

The modelling was done with 3ds max. After some frustration in getting polygons to unwrap into nonoverlapping UV regions, I exported the UV Texture Maps and doodled on Paint Shop Pro. It was rather fun. The palette on the guy’s face and hair is shamelessly stolen from my Resonance hero sprite.

My intent is to hopefully make a face paced hack-and-slash + platformer with cube men everywhere. This might change later, when I feel more creative.
In my Computer Security class, I wrote program in Python that would use a dictionary attack to figure out a password that starts with “R”. It used Python’s telnetlib module, because the login was performed remotely over Telnet, and it used the threading module to perform multiple connections. The target server we were attacking certainly wasn’t very secure… Once the protocol was working, it was burning through about 100 words in the dictionary every minute, until it eventually made it up to “retribution”, the winning password phrase.
In my Image Processing class, the assignment was to write a program that rotates an image and uses bilinear interpolation to smooth the pixels.

This was especially easy since I had code left from Brockoly that did image rotation, and it used the Corona library in C++ to load images. I simply scaled back the code so there was less junk, and made it so images could be saved as PNGs.

Corona once again saved the day there, since it has a PNG writer builtin. Very handy. Also very easy, which makes me wonder why we don’t have png saving in Verge yet, since it’s quite simple — only about five lines! Ahem.

So when I was finished, I had a commandline program that could take any input image, rotation (in radians or degrees), scale, and the name of a PNG output file, and do all the processing work. Sexy.
In other news, LuaVerge works again more or less, thanks to Zeromus.

It’s quite different in how the internals are accessed. On the other hand, the internal variable and function things are successfully shared between Lua and VC code. In other words any feature (that’s not a language feature of VC) is available in Lua too.

The only thing that’s missing is boilerplate magic Lua code so the internal variables’ get/set methods are wrapped up in tables in a nice way. This can hopefully be added soon too, if I’m not too busy.

When that’s caught up, on to shmuptroidvania work and cube man game.
See you next week, folks!

Tags: , , , , ,

No comments (make one!)

LuaVerge: Take Two

Posted by Overkill on January 11, 2009 at 1:43 am under Uncategorized

Hey there.

This week, I didn’t get to work on shmuptroidvania just yet. But this was because there were other pressing issues to tend to.

The big priority was starting to fix LuaVerge so it’d work again. We used to have luabind do the dirty work, but it was too limited and wasn’t very maintainable. A rehaul was justified.

Zeromus and I discussed ways to tackle this, and we figured the cleanest way to make functionality shared by both VC and Lua is to make the bindings call the same internal functions for dealing with builtins.

I’ve added builtin function calls, through a bit of Lua glue and prodding at vc_builtins.cpp which handles the function glue. I also added reading of constants from Lua (HDEFs).

Zeromus has been working on the raw variable (HVAR) binding code, which will use methods like v3.get_systemtime() and v3.set_entity_x(ent, x). The variable-like access for these has yet to be defined though, and is bound to be much slower. But at least THIS time around, the functions that are called are visible to those who need the extra access speed.

These changes called for a lot of stuff being moved from the vc_core.[h/cpp] files to the ScriptEngine class (defined in g_script.[cpp|h]). There’s also a ton of methods in ScriptEngine that no longer need to be there now that luabind is gone, but refactoring that is gonna be hairy.

I am planning to get a packfile loader working with lua sooner or later, and then people can use vpk for lua scripts.

It is my hope that the vx library stays the same to the outside user. But the new variable binding crap should definitely speed things up a tad.

Oh! There was another neat idea being thought of, which while low-priority and possibly difficult at the moment, would be awesome: A bridge betwen VC and Lua directly, so that Lua and VC scripts can talk together. This would lower the barrier to entry, since old VC code could be used in new Lua projects. This means that written game scripts could make a gradual movement to Lua while still working in the meantime, encouraging reuse of old stuff, and giving a boost towards wanting dynamic scripts instead.

Anyway, this was my week. Catch you folks around!

Tags: , , ,

No comments (make one!)

Resonance Grows Stale, Shmuptroidvania Born

Posted by Overkill on January 3, 2009 at 10:42 pm under Uncategorized

So for a short time I was working on resurrecting Resonance. And I actually found a quick and talented artist, Souly, from Pixelation!

However, shortly after school came around, and violated me with some rough mathematics final exam, so I was too busy to work on it. When I was done, I had the somewhat bad idea to host a competition. This meant no work would be done on Resonance for some time. I honestly needed a break from the stress, and compos were good at that.

Me and Toen made a game called Monster Magnet Meow (I will rehost here later probably). Our Briton friend, Zip, was also trying to help, but it seems like he must have been too busy because he left us with an unfinished map and a few new bugs in the code right before the compo ending. Sadly we had to pull his work out from the submission, which is a shame, but maybe if he reappears we can get him to finish it!
But I have other both good and bad news: my artist got hired by a game company! Which is great for him, since Souly definitely is a deserving of a professional pixel art job. I wish him luck. I haven’t really been in contact in a while, but I’m guessing that he has gotten much busier.

Between losing an artist and generally having it drag on in this way, that probably means the end of Resonance’s lifespan, but I still learned a fair deal. I just think if an idea grows stale like this, it’s better to abandon it and move on.
Then I had the idea to the make a new game style, which I call shmuptroidvania

Shmuptroidvania = shmup (“shoot-em-up” arcade space shooter) + metroidvania

Ever heard of the game Air Fortress?

It was an old NES game that had 2 phases: shmup elements leading up to each fortress and sidescrolling elements to explore and destroy the fortresses. It wasn’t perfect, but it had a fairly awesome idea. This is at least proof of concept that shmups and sidescrollers can live under the same title and work.
Combine this mixed-genre game with the modern popularity of metroidvania games. You get a game with a fair mix of action and exploration.

When in your ship, you cruise forward, dodge obstacles and fight through bullet hell action.

When on land, you can run, hop, and shoot things, while solving puzzles and exploring the lands you’d typically ignore from a shmup. But this is interesting! That giant planet you’re nuking, you don’t really interact much with it normally, but this game plans to change that.
How would I keep backtracking in shmup world less annoying? Two things come to mind.

First, a bunch of branches and alternate routes which popup as you go. You can also turn and run away from an area your shmup reflexes don’t feel ready to face yet with the flick of a button (which spins your ship in the opposite direction and then reverses the cruise direction). I’d also reward completion of shmup areas with a fresh, possibly-less-hectic routes the player can travel.

Second, for lengthy travels, there would be an ability to teleport between places, which would also relieve a bit of annoyance.
Anyway, this was just an idea that recently stuck with me, and I have a feeling I can make it work in ways Resonance just wouldn’t.

This also makes me get two sorts of game styles I’ve been trying to get out of my head for a while, and creates a fresh take on fairly commonly made genres.

Tags: , , , ,

No comments (make one!)