This is Bananattack.

Tag: lua

Alive and Lethargic

Posted by Overkill on December 19, 2010 at 10:55 pm under Uncategorized

It’s getting closer to Christmas, and it as approaches, I can’t help but reflect a bit on the past year. I’ve had very mixed feelings on the whole thing. I won’t drag you too far into my life, but I’ll give you a bit of closure. I think it’s the right thing to do, given my large absense.

 

I was 21, and had just finished my second-last semester of school at the University of Guelph. It was good to be back after the stress of juggling several Computer Science courses, and finally having free time to work on projects.

Christmas was fun time with family, and I was happy to be off school. I was hacking away at Molasses Monsoon, drawing a picture for Pixelation’s Secret Santa event, and attempting to make a quirky sim-game for a winter contest with Syn. It was going pretty well, but this wasn’t going to last much longer.

First off, my uncle passed away shortly before Christmas. I felt kind of bad because most of my memories of that uncle were from childhood, and our family didn’t visit nearly as much when I grew up. We went to the funeral a few days after Christmas, and were back home around New Year’s Eve.

On the day of New Year’s Eve, my friends called me up and wanted to hang out. My dad was working on a puzzle in the afternoon, we talked for a bit, and then I was on my way. But that was probably the last fond memory from that break, and the last time I saw my dad feeling well. I came back after celebrating with my friends, and pretty much went straight to bed.

The next day, New Year’s Day, my dad was sick. I figured he had some bad Chinese food, or it was from the celebrations the night before, but it turned out to be much worse. It turned out that he had a stomach flu, but since he had a thyroid condition and Addison’s Disease, this was essentially a death sentence. He never bothered to explain his conditions so I knew very little about what they were doing to him, and he never asked to go to the hospital when he feeling was sick. By the time we took him to the hospital, it was already too late. My father died the morning of January 2nd.

Soon after, I caught the stomach flu, and so did my sister, my aunt and my sister’s boyfriend. Since I caught the symptoms the day of my father’s death, I thought I was going to die at the time. And I was really sick the rest of the week. I managed to pull through.

…I won’t go into further detail than that. It was a horrible time. I only felt that it was okay to disclose this, because it’s getting close to that time of year again, and I know that this Christmas definitely won’t be the same as those in the past.

 

Anyway, I went back to school, pretty much right after I recovered from my flu, and finished my last semester. I took Compilers, where we wrote a Pascal-ish (Pish) toy compiler that emits MIPS assembly, a 3D Graphics course with a bunch of OpenGL stuff, an course on AI stuff, and the obligatory Topics in Computing 4th year course where you do independent research (I made a cheesy painterly renderer). It kept me busy, and I managed to have fun throughout most of it.

Since then, I’ve turned 22, and graduated from the University of Guelph with my Bachelor Degree in Computer Science. I’ve felt no real motivation to do anything amazing with my life. School was like the last big obligation I had to complete, and my father wasn’t even around to see it. I have no real direction anymore, and I feel like I have as little idea about what I want to do with my life as when I was still in high school.

My projects have been stagnant for the most part, although I had a few surges of creativity. I worked on Verge for a short while after I got off school, around May, which you can see about in the post before this.

The next big burst of creativity was learning some 6502 assembly and how old Nintendo hardware worked. I attempted to create an NES game, and although I didn’t make it too far, I managed to make a small tech demo ROM, that looks like this:

It’s a fairly basic techdemo, which has a textbox and a player sprite, and it uses MMC3 scanline interrupts to do funky cloud tile scrolling. It doesn’t have any audio, because sound engines appear to be a tad more work than PPU manipulation. I wanted to eventually make a roleplaying game of sorts for the NES, but that might be a while, if ever, that I get anywhere with that.

Then I realized how tedious it was to type in assembly commands using official 6502 mnemonics. I went about making a 6502 assembler, which I decided to call “nel” (Nintendo Entertainment Language, or something, I don’t know). It was written in lex and yacc, and you can view its source here. For its purposes, it worked, but I felt like I could do a bit better. Lex and yacc were both a bit ancient and frustrating, and the error reporting in yacc was annoying. There were also annoying memory management problems with C++, which I coded the AST in, and it was going to be pain to fix all that. In fact, right now, the memory just leaked until the compilation was done and OS cleaned up. I

I eventually decided to make my own recursive-descent parser in D. D is pretty nice, if you don’t need any external libraries, and only really need file IO and some data structures, which was the case when writing a compiler. It’s also garbage collected, which was good. I got a little bored doing the rewrite though, maybe one day I’ll pick it up. I’m onto the AST-handling junk, which I can more or less port from my C++ codebase, but I’ve been a bit lazy.

 

In addition to a few creative swings, I spent a lot of time looking for a job with no results. I eventually (mid-October) found something through a school friend. I started in November, and although it’s probably a temporary thing, for now it seems okay. It’s a six-month contract for a company called MRX, which has the CHL and CFL as two of its primary web-design clients. So far it’s fun, and there are a few people in my developer team that also went to the University of Guelph.

Lately I haven’t felt an abundance of free time, and usually find myself tired and unmotivated when I get home from work. I watch some TV, or hang out with my flat-mate for a bit, then sleep and repeat. My hobbies like playing games, writing, drawing pixel art, and coding have all been heavily neglected.

I’m writing this now in attempt to stop this idle activity and do something with my time again. Especially since McGrue and Kildorf are back in the race and making progress, and the recent advent of the new vrpg homepage should be inspiring to me.

I’ve done only minor things lately, mainly decisions for Verge in the long-term, but which haven’t been executed yet. Decided to rip VC out of Verge, and to redo the Lua API, to remove FMOD in favor of audiere, and to do some major internal cleanup. API ideas so far for a future Verge version (Verge 3.3) are in my Dropbox public folder, so these files may change as I edit them. Here are some files with the rough ideas about the new API:

Take a look over that, and if you have any feature requests, let me know.

Anyway, this is about all I can write about for now. Hopefully, I will make another post soon, by the next week. I will have to see though.

Tags: , , , , , , , , , ,

1 comment


History repeats, with delicious treats

Posted by Overkill on July 10, 2009 at 2:41 pm under Uncategorized

Hello! Been a while since the last time we talked.

I am an inconsistent person, and I forget things. I quickly fell out of Gruedorf again. And I don’t really have much to show for it yet.

I haven’t been able to find a job since early May, but I’ve still been wasting a lot of time struggling to find one. Sort of depressing, y’know?
 
 
 
Early after my last web job (which ended late May), I started working on a web paint tool, which I dubbed “Laser Toast”. It was pretty fun to make something interactive like that, especially since it was mostly in Javascript (and just a little PHP + JSON). It let you draw a super zoomed 64×64 image. It worked pretty well in my tests on Opera and Firefox. But it would do terrible things in IE7, where apparently it was running out of memory or took a really long time manipulating DOM objects.

I gave up on that eventually after I got bored, but it was a fair deal of fun while it lasted.
 
 
 
In other news, I have been working on a 2D game engine, which I’ve called Plum. (This is actually a revision of Brockoly, but with less ridiculous-to-type/say name. It also has plenty of features that weren’t in Brockoly.) If you want an silly acronym, something funky like Platonically Loving Unicorn Machine, or Poetically Lavish Universe Maker will do the trick.

For starters I’ve got Lua scripting, FMOD Ex for audio, Corona for loading images, zlib for compression, zziplib for archives, and SDL for the input, timing, and video. Nothing too fancy.

I added a packfile loading mechanism. Packfiles ARE pretty useless, but I figure it’s nice to bundle Lua libraries (like splash screens or an ‘rpg’ library) and stuff this way. To save myself time, I just use a ZIP format, renamed to .pit (Plums have pits… yep). I use zziplib to do the heavy lifting. And I made it so pretty much all my code properly uses ZZIP_FILE* instead FILE* for reading. I got to learn about the different ‘read’ callback APIs for Corona and FMOD Ex in the process. Heh.

I’ve slowly been making the implementations for my sprite, tileset, map and world layouts. They are all written in Lua files! I decided this allows a lot more flexibility and less bugs than with that crappy language that I “invented” called Mungo, especially since the Lua API under C is pretty simple to use, and can easily do error checking. I do a bunch of checks to make sure the data is valid, and I also ensure that no control statements can appear by using “return <Value Read From File>” in a dostring.

Sprites are so far pretty much just images with animation strands defined. Eventually I want to add metadata so that information about a particular sprite can be stored in the format itself. But for the most part, it does 99% of the job I want the engine to do. The rest I envision will be user code written in Lua.

Tilesets are a little more advanced, but in different areas. For one, you can specify an externalFile attribute in your tiles table, which the engine will autoimport upon changes (provided that file exists). It saves imported data in the tileset format itself, and it keeps an SHA1 checksum to lower redundant reloading.

The data is a zlib compressed chunk of raw data, which is then base64 encoded so it can be stored in Lua. This was shamelessly ripped from ika.

I am still planning to add the other, more sophisticated features to the Tileset format. It needs a structure for ‘arrangements’ which will denote preplotted tiles and obstructions. These would be useful for plotting an otherwise tedious collection of tiles, for something like a tree. The engine would not be capable of distinguishing what plotted tiles belong to which group without annoying amounts of extra info or sluggish pattern searching. So I decided the engine would know arrangement composition for plotting, but would become regular tiles once plotted. I figure this is a good enough.

There will also be ‘categories’ for tiles, which help classify tiles and give them useful meta information. A tile can belong to many categories. This would be useful for assigning terrain costs to tiles in a tactical game, or as a way to accomodate autotile functionality. Entire arrangements could be added to a category, too, but the engine would add the individual tile components of the arrangement to the category rather than adding the actual arrangement. This is for sanity reasons, again.

And tilesets would have animations that can be assigned to tiles, that would be fully scriptable with strings like ‘F3W10F4W10F5W10R’. Any tile index would only be allowed to be used once across all animations, to allow there to be simplistic grouping, and have it so each tile has a transition into exactly one other tile.

I need to eventually add a cleanup mechanism to my file parser, so that after a data entry is parsed and stored, it can be safely deleted. The reason being, I don’t really want to keep large data strings in memory, if I’m ALSO.
 
 
 
So hold on, isn’t this whole making-a-game-engine thing pointless? You bet!

Do I consider it to be reinventing the wheel anymore? Not really. It’s more like mashing a bunch of wheels together in a horrible attempt to make a Frankenwheel. I’m generously reusing existing GPL/BSD/Public domain code, to save time and effort, and only rewriting the aspects that need to be changed to make this thing flexible. It’s targetted at being portable and fairly lightweight.

It’s mostly there though. In fact, it can do a lot of what Verge and ika can, without maps/tiles/sprites. This steps from the fact, there was a fair deal of inspiration off those. It also my own intuition to make reasonable decisions.

Note that this engine isn’t intent on replacing Verge or ika. It’s an exercise for me, first and foremost. If I can draw the interest of existing users when it’s release-ready, I guess that’s good. Ultimately, though, this is a tool for my use. To improve my software design decisions, to see if I can remedy problems I saw in other engines or if I will fall into a similar trap.

Some of my code was unnecessarily reinvented back in the Brockoly days, but I am really trying to harvest from existing frameworks, to modify and improve. A lot of these ideas are incompatible with Verge, but on the other hand, I could adapt Verge source to fit in my engine. There’s nitty gritty implementation things to blame there. But mostly, this is for fun.

Once I get a reasonable amount of engine done, making games will become much simpler.

If you want to play around with my engine, it’s available at Github under a BSD license. It guarantees only limited stability at this point, and some code needs serious refactoring but feel free to look here.

Git is awesome, by the way. It had a bit of a learning curve at first, but I definitely like it a lot more than SVN now.

My repo includes a silly demo which shows a tileset loader test (might be removed soon), and (if you hit Enter) a simplistic rotating heart screen that does funky things when you click.

My repository also has a demo game called Maximum Yak Maniac, which I talked about last time I posted. It was pretty easy to remake, since it doesn’t require maps, sprites, or tiles. It just uses raw images and audio. Yay.
 
 
 
So there you are. I’m unemployed, and writing a game engine in spare time. I have also been juggling a couple game projects, but I’m not really prepared to talk about them yet. Next time, maybe.

Also I didn’t really check the formatting too much while I writing this, it might be too wordy, in that case tl;dr sorry.

Tags: , , , , , ,

1 comment


We need Verge 3.14

Posted by Overkill on April 9, 2009 at 1:49 am under Uncategorized

Seriously need to sit down with Zeromus, and hammer out a release for Verge 3.14 already. These awesome Lua features are just sitting here being under utilized! :(

Both Textshmup and Resonance have been using the new LuaVerge, and new vx, and I need to share the love. In a more stable form.
When these things are released, I can make sure ustor updates his space game, and other people can convert.

Having this release also means we could possibly pave the way for a functional VergeC to LuaVerge converter. This in turn would mean games with giant code investment, like Sully Chronicles or any number of Verge 3 RPG systems could be seamlessly converted into similar Lua code.

Okay remind me not to post at 3 in the morning again when I am half-asleep and have an exam first thing when I wake up. Okay later.

Tags: , ,

No comments (make one!)


Anonymous Functions, and Textshmup: A retrospect

Posted by Overkill on April 8, 2009 at 8:53 pm under Uncategorized

Some of you may have recently played my 24h game textshmup. As expected, it wasn’t that well received. It was a bad concept to begin with, after all! :D

It was too hard to read quickly and type responses. Audio cues and colored text were added to make the game slightly easier to react to, but even then, it was just too tedious. It was just a randomly generated endurance test, with no goal, and no intermediate tasks.

That said, I had fun making it! I mentioned last time that I made it in LuaVerge. I never mentioned why it was so quick to write.

Well let’s go!

For one, I used the vx library I had written. It came with the spiffy nifty object-oriented class system that I made.

I had my entire game use a single well-divided render/update loop, which boiled down to this:

while true do
    Render()
    Update()
end

I declare two lists which contain all the callbacks done by the render and update events:

render_list = {}
update_list = {}

Here is Render(), in its entirety:

function Render()
    vx.screen:RectFill(0, 0, vx.screen.width, vx.screen.height, 0)
    for i, f in ipairs(render_list) do
        f()
    end
    vx.ShowPage()
end

The Render() function starts by clearing the screen, then it iterates over all entries in the render list, and calls them all. At the end, it shows the changes on the screen. This was ridiculously nice to hook in new rendering events.

Similarly, here was my Update() code, which used frame-throttling so each update callback could be written in per-tick logic:

function Update()
    frame_limiter:Update()
    
    local i = 0
    while i < frame_limiter.gap do
        for _, f in ipairs(update_list) do
            f()
        end
        i = i + 1
    end
    vx.SetAppName(TITLE .. ' ' .. frame_limiter.frame_rate)
end

Both of these worked great for global functions and static methods.

There was one issue with the way they were designed though. Which wasn't immediately apparent, but here goes.

Say I made a class named BlueBox, which has an x, y, x2 and y2. I declare a method for it like this.

function BlueBox:Draw()
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))
end

In Lua, the colon : in that function is syntax sugar for the following:

function BlueBox.Draw(self)
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))
end

Which is syntax sugar for:

BlueBox.Draw = function(self)
    vx.screen:RectFill(self.x, self.y, self.x2, self.y2, vx.RGB(0, 0, 255))
end

See that 'self' parameter? Well, earlier when I'm calling the functions, I go like this:

f()

That's a call with no arguments. If we try and add the method pointer for a particular blue box's render, it will call it without passing self, so 'self' is nil:

-- Won't pass the self parameter!
table.insert(render_list, self.Render)
-- Similarly, won't pass the self parameter!
table.insert(render_list, self:Render)

Thus object instances aren't passed around. Not good!

So how do you pass around the 'self' parameter to this list? Well, fortunately, Lua allows you to create anonymous functions, wherever you want because functions are first-class values. And these anonymous functions can be passed "upvalues", which are local values defined in a scope outside the function.

Using these facts, I wrote a trivial fix to bind method pointers to their objects, and leave Render unchanged! I made a function that did the method wrapping for me:

function MethodPointer(self, meth)
    return function(...)
        return self[meth](self, ...)
    end
end

The function is passed the 'self' parameter and the method pointer to bind together, and it returns an anonymous function which will take care of calling, with 'self' being passed automatically.

Then I can go add to the render_list and update list:

table.insert(render_list, MethodPointer(self, 'Render'))
table.insert(update_list, MethodPointer(self, 'Update'))

This is actually pretty close to how Javascript gets around similar problems, but with its definition of 'this'.

This little tidbit allowed my various components of my game to plugged and unplugged from the main loop as it progressed.

For my text input, I used a callback to process commands when enter was pressed, using the same method pointer stuff. The callback passed around the piece of text, and would return true or false on whether or not the command was permissible. It was very nice.

Lua is just awesome. I love it.

Anyways. As you might see, coding isn't really a colossal obstacle, with Lua around. Instead, the new obstacle is coming up with good ideas!

Something to remember for the next time I try and make a 24h game, and what I always need to consider, while making Resonance.

Catch you later, everyone!

Tags: , , , , , , ,

No comments (make one!)


Textshmup

Posted by Overkill on April 5, 2009 at 3:35 pm under Uncategorized

For my 24 hour game, I made a weird game. A text-based shoot-em-up. Think of a text adventure, played on the console, but the scenario is constantly updating. You have obstacles to avoid and enemies to blast. Your situtation is narrated, and you type text commands to avoid things.

You constantly move forward, and need evade the hills and ceilings of the game’s endless cave.
As a result you need to adjust altitude to avoid things.
Crashing into obstacles results in an instant death.

As you fly along, you will encounter enemies, who need to be taken out quickly.

You have lasers and missiles. Lasers are weak, but unlimited and fast firing.
On the other hand, your missiles are powerful, but limited and slower firing, and recharge gradually as you go on.

Your shields protect you when engaged but gradually decrease in energy.
Your shields charge and replenish when disabled.
Your frame has limited health, and so as you go further in, toggling shields becomes crucial to survival.

At the end of a run, it displays the distance traveled, your score, and the enemies you destroyed.

It was all coded up in LuaVerge, making it ridiculously quick to code up.

So, now that’s it’s been introduced, download textshmup.

UPDATE:
Textshmup now has the ability to speed up/slow down your ship.
The higher your speed, the less missiles you replenish, and the more obstacles you encounter.
So it’s sort of a difficulty modifier, I guess?
Also: it reports the time you were alive. I forget if it did that before, but whatever.

Tags: , , , , , , ,

No comments (make one!)


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 http://www.verge-rpg.com/svn/verge3/ 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
end

And methods inside the class are sort like

function Thing:method()
    print "Hody2!"
end

Objects can be instantiated like this:

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

Their methods can be invoked fairly simply:

mything:method()

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
    end
end

…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
    end
end

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!)


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!)


Composting misspelled off-colour vegetables.

Posted by Overkill on November 16, 2008 at 9:40 pm under Uncategorized

People were right. I was pointlessly reinventing the wheel in an attempt to make something that nobody would’ve used anyway.

I discontinued Brockoly.

I was hitting major roadblocks, and redoing code that I didn’t really want to rewrite from the bottom up. I would never finish by myself in this lifetime.

However, I still assert that I learned a fair deal while suffering of Not-Invented-Here Syndrome. I learned how to write C++ code better, and how to do slightly-complicated software image blitting techniques. I also took a heavy inspection of ways to structure internal file formats like sprites, tilesets, and maps (which I am actually interested in — and what threw me into making my own engine to begin with).

But this madness stops.

Now.
 
 
 
From now on, this engine know-how should be invested smartly. I should be fixing things that are already out there. Things that just need improvement. Fix the wheel, don’t make a new one.

Verge is a great candidate for this. It’s already enough-to-make-games-with, just needs a push to make the whole ordeal of making a fully-fledged game a less tedious experience.

I think the internal engine stuff should be improved. And now let me go on about how.

Entities must have custom animation strands.

The .chr file format itself should allow animations to be scripted. This way you don’t need to write a custom animation system on top of Verge’s. This means that you can tell your hero to strike a victory pose without having to hardcode “F10W10F11W10B” and such in your engine — and it allows sprite editor to handle all sprite animation instead of HAVING to write out code for it.

Entities and Layers should be referrable by name.

So you don’t need to memorize index numbers. So now you can say in your script something like “Move Bob” instead of “Move Entity 34″, or “Change the rooftop transparency” instead of “Change the transparency of Layer 23″. It keeps you a lot more sane, and prevents scripting mistakes from creeping in.

Obstructions, Entities and Zones should be on each Layer.

Allow every layer on the map to have an obstruction channel, zone channel and entity channel. Instead of ONE obstruction layer, ONE zones layer, and so on. This, in turn, allows you to have bridges that you walk both above and below, without hacky tricks.

Maps need Waypoints.

Waypoints would be for a single spot on a map that have a name (constant lookup by name) and allow you to work it into your scripts quite easily. It would allow tile regions on a Layer to be referred to by name.

This is different from a zone, because Zones are for many spots on the map that all share the same events (constant lookup by (x, y) position).

Additionally, this single name to single position mapping means it’s ideal for pathfinding!
 
 
 
So say you have a water fountain, and you want your player to walk towards it. Currently, you need specify an exact path to walk to the fountain through a series of EntityMove(player, "X10Y11U10L10") like commands probably with a bunch of if statements and stuff.

Contrast this with just saying something like EntityMoveTo(player, "fountain"), which could pathfind automatically. It could be pretty quick about its search, and maybe have a restraint on distance to pathfind from, after which you could chain a bunch of Waypoints together and move from point to point.
 
 
 
Perhaps more interesting is, say, when you have a bunch of treasure chests on a map.

You can use zones for their activation on map, and waypoints for actually telling where the chest IS on the map, so you don’t hardcode positions.

So when you return to the map later, and need to set tiles for all the chests again, you can change the tiles at the waypoints! As opposed to needing to write coordinates in your map startup event, which gets messy quickly.

LuaVerge needs to be faster.

LuaVerge, the new twist on Verge, which has Lua instead of VergeC for scripting. Lua’s a language that I figure could replace VC at some point, because it’s much more expressive, and less restricted. LuaVerge has a lot of potential.

Sadly the potential that has gone sour by the fact that the LuaVerge is several magnitudes slower than the VC version right now. Surprisingly, the problem isn’t Lua, or its helper LuaBind. It’s our code that glues Lua into Verge. It was supposed to be fixed a long time ago, but I never figured out how to represent array-of-structure like things through LuaBind directly.

LuaVerge needs to play nice with packfiles.

Right now Lua scripts need to be outside of .vpk files, because otherwise they can’t be included by Lua. In short, this means people who release demos have to include source, which could be fun-ruining. Also I respect peoples’ desire to have their code stay private, just so nobody outright steals stuff.

This is probably a fairly easy fix, just make the Lua code use verge’s I/O stuff instead of the <stdio.h> library that comes with C. Kind of hairy though, since you need modify Lua itself.

I need write tutorials for vx.

So, vx (Verge eXtension) is my little code library that makes LuaVerge even nicer to use. The problem is, I need to write a tutorial on how to use it. Unexplained code means very few people are going to jump on it.

This brings me to my next point…

I need to entice people to switch over to LuaVerge.

Right now almost nobody uses LuaVerge, and I know that’s mostly because nobody has been encouraged or taught how to use it. So we need to get people interested in the newer Verge and to demonstrate how it’s better. Ey, ain’t that right, Kildorf, ustor?
 
 
 
Anyway, that’s a lot to think about. Hopefully I can redeem myself of my grand suckitude. School is murdering me, so I want my dev time to be useful and rewarding. That is all.

Tags: , , , , ,

4 comments


Progress Begins

Posted by Overkill on October 20, 2007 at 9:21 pm under Uncategorized

I’ve been making a LuaVerge middleware code wrapper in my spare time for some time now with the cooperation of Zeromus. I figured this week that the Gruedorf competition would be a fancy way to show off some of the features. It’s fairly spiffy. So I made a sidescrolling engine!
Get it here!

Now I can hear, “This looks kind of neat, but also really useless. What do you actually need a sidescrolling engine for? Why did you even bother porting it to Lua?”. At the moment, yes, it is a VERY useless engine. I put in the basic movement and jumping, nothing splashy. It’s a port of a port of a port of some silly code (VergeC -> Java (trouser engine) -> ika -> LuaVerge). I decided that of these languages, Lua’s probably one of the ones I’m finding most comfortable. VergeC’s crippled, Java’s too verbose, Python’s very nice, but ika’s got a bunch of quirks and a somewhat awful toolset. LuaVerge is nice, since now that I’ve got a useful Lua wrapper, I’ve tackled most of the quirks with using Lua to map nicely to the C functions (like int-to-boolean coercion always being true). Plus LuaVerge means I get to use a fairly nice scripting language, keep some familiar dev tools, and get software raster rendering rather than hardware texture rendering.

Signal is the codename for a sidescroller project that’s been bouncing in my head for months saying “do me, do me!” but I never got around to taking it past the idea stage. The game is going to be set in large explorable two-dimensional world with a nice mixture of action and puzzles. What makes this game different is the player has next to no abilities on their own. The player is in fact, quite frail alone. However, there are transmitting signal beacons scattered all throughout the world that can be interpretted by the player’s suit. When the player’s in range and has good reception, they obtain a variety of abilities and gain physical enhancements to strength, mobility and environmental resistance.

As you move around, some signals die out, while new ones are received. Environmental factors like thunderstorms or magnetic fields will interfere with the player’s ability for reception. Strategy comes into play as you maintain the signal beacons in order to advance, applying repairs, enhancing signal strength, pushing the beacon to another location to get it past environmental factors, or into range. In some areas, signals broadcasted by the beacons can be switched with another beacon’s power.

The signal you receive is interpretted in digital “levels”, where a low level denotes bad reception, and a high level denotes a great reception. As signal levels increase, so do the powers. Your physical appearance will fade in and morph as your strength increases, and you will also be able to see when you’re at risk of losing strength and abilities by a “static” distortion effect on various artwork. This is going to take lots of artwork layered on top of each other, but it’s almost essential to get a nice in-game display. I wanted the game to have a very minimal HUD, since too many little icon things on screen easily get distracting and confusing. Physical appearance changes, on the other hand, make it easier to see, and keep your eyes on the player in situations where it counts, like if there were to ever be an area with both signal interference and intense action. I was thinking when the game was paused, I’d give a more detailed view, but when the game is in action and you have to constantly monitor several factor that can get annoying. That way, you get the best of both worlds.

So what would be on the HUD? Probably just a minimap, your health which fades out when it’s not being affected, and (perhaps) the player’s weapon reception when it changes.

The game is going to try to keep exploration fairly free and non-linear, limited more by your cleverness than story factors. I’d ensure that hopefully the game can be beaten without getting stuck often, but have several rewarding things for those who go out of their way and explore the world in greater detail. I want to have puzzles, but I don’t want people to hate me for unbeatable puzzles in areas that are essential to completion of the game. I also don’t want frustratingly impossible action in the main portion of the game. I think challenging puzzles and intense action will have their place as side-quests, and I will try my best to make it interesting and rewarding enough to inspire the player to get through difficulty. Maybe an unlockable ending or something, but I’ll make sure that the player can actually go back if they missed something, because nothing pisses me off more than New Game+. I mean, it’s a cheap way to force replay. There are some things I don’t want to do over again. I mean, I love rewards. But please don’t make me replay the game just to get them. I mean, sure, I’ll replay games I really liked, but these are exceptions. If somebody wants to play my game once and get everything and be done with it, I want to leave that as an option. None of this stupid starting over and repeating painful game areas over just to get a goofy prize.

I don’t really like backtracking either, so it’s going to be minimized to a reasonable amount, because as nice I think my maps could be, I think variety is important. Exploration implies backtracking to an extent, but I will try to have multiple routes to locations, and make sure that you don’t go back and forth too often. Metroid and Castlevania both do well for the most part, but you can find the odd area where you have to do frustrating backtracking because you fall down a hole or something stupid. I want to avoid punishing the player wherever possible.

Oh, and here’s some old artwork I drew a while ago, but I’m not sure how much of it will actually be used for this project:



The mockup’s especially out of date, because the HUD’s way too cluttered for my tastes, and it doesn’t use the grass or water tiles I made. The grass tiles were going to have dirt tiles underneath, but I couldn’t find a satisfactory texture that had enough realism and tiled well. The water tileset has an example of the old dirt I had, but it’s too simple and flat in comparison to the bushy grass.

Darien drew this very sexy edit of my sprite:

I’d bug Darien to actually give me a hand on the project, but I know he’s busy with school overseas in Ireland. I could modify his sprite, but the problem is, there’s no way in hell I can animate something that large in efficient time. If I did anything it would most likely look ugly and unsatisfactory to me. Meanwhile, my hero sprite is too flat and not worth the time to animate. I’d rather use my weekly updates for code and design than drawing because I’m sufficiently bad at artwork.

Anyway, I’m done blabbing for now. If you are a talented pixel artist, drop me a line. I’ll want a hand with this project, because artwork is a big time-consuming ordeal for me. I’m also looking for a musician, ambient in the deserted map areas, but bombastic and epic in the action-filled areas (possibly with chiptunes). Comments? Concerns? Criticism?

See you next week.

Tags: , , , ,

6 comments