Yesterday I was bored, and one of my housemates was working on a webpage for fun. So I decided maybe I should try my hand at redoing my website so that it has minimal eyehurt and incorporates some of my colorful artwork.

I drew a rough mockup in pencil (which I scanned for interest’s sake):

Then I cracked open Photoshop and went to town. The end result, is what you see now! Here’s a thumbnail of the result anyways (showing the frontpage which is has a larger, more detailed header):

Just used about 3 layers for each image. A background color layer, an outline layer, and a “coloring” layer sandwiched between (The sky also had a separate ‘cloud’ layer behind the banana but in front of the background). I painted them with the regular brush tool + pick, with a few well colors chosen in advance. Screw smudge and sponging and all those extras. Also didn’t use brush opacity settings.

Oh, and of course, a little bit of fighting with CSS and HTML, but not nearly as much now as I used to!
 
 
 
Today I took my rough prototype and mashed it into a Wordpress layout. Was relatively painless since it was mostly CSS changes, and a few elements being shifted around.

Oh, and Kael, Zaratustra, and Andy helped point out the hugeness of my old header through messaging on Twitter. Thanks!

Anyways, that’s all I have to say for now. Games will be mentioned soon, I promise!

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.

We had a few crazy rules for this competition, just to make things more interesting:

• Our game had a random title was generated with the Video Game Name Generator. We each got 5 rolls. At each roll, you decided if you’d keep it or not. If you kept it, you stopped rolling. Otherwise, you decided you would not use that name, and took another roll (you couldn’t go back to old names).
• Someone writes a theme or idea down on paper, and forces you to incorporate that into your game.
• We had 24 hours to make the game.
• No previously created code/art could be used (with the exception of code libraries, and premade fonts)
• We had 30 minutes to brainstorm before the contest actually started, where we knew our idea and could plan, but couldn’t perform real work.

 
 
My friend made Advanced Battleship Mission.
He had to incorporate Cel-shaded Goats somehow.
His game is downloadable here.
You need to protect your battleship from submarines, with the help of your trusty cel-shaded goat advisor!

Controls:
WASD = move
1 = sonar
2 = nukes
3 = mines
mouse = fire cannon.

 
 
I made Maximum Yak Maniac.
My friend was malicious and wrote down it had to be Multiplayer.
Here is what I came up with.
You (and a friend) are yaks with steroid addictions, and must out-do their opponent by having the most destructive roid-rage.

Controls: listed in game.

It was a fun competition, and we said we’d need to do another retarded contest again sometime.

Unfortunately, it eventually got in the way of real progress for making games, along with school and the paid webwork I was finishing up.

So my idea to help me more efficiently make work on games eventually ended up with me become much, much, less effecient, as I got horrible horrible ideas to make a twitter app instead of making games like I was supposed to.

And even before I was obsessed with making a webapp for my progress tracking, the premise of the progress game was a bad one. It was penalizing me for not getting work done, which is fair, but it was based on “progress points” allocated earlier in the week. The thing is, later, I might realize one of the tasks requires a lot more work, and so it can’t be done for a very long time. So those would be wasted points. It didn’t focus on the big picture, so tasks would be arbitrary things, which might not even be relevant to actual game progress.

Anyways, I don’t care to talk about anymore. Gamagame, good bye.

I am going to make progress through traditional methods. Well-crafted design documents, implementation requirement documentation, and to-do lists. Prepare for further announcements, as I discuss recent game development.

Among the improvements was a HUD showing the time limit, bits collected in the current area, and overall completion percentage. Gave the player way way more time. Scrapped the old battle system, and replaced it with a quest to capture all the slimes. Although it’s sort of annoying it’s less so than the battle system that was there.

There was some god awful hideous work-around code, that I commented out and replaced with like one or two lines of new Verge. It shows how both Verge and my coding has evolved.

At any rate, it’s there to download and drool at now.

I can’t say I was fully satisfied with what I’ve done, but I’ve made the thing a little more presentable and thus more playable for everyone. It was a fun diversion. So, go check it out.

UPDATE: Fixed more bugs with the game, and added a difficulty selector. With the addition of hard mode, which IS hard. If you switch maps which you haven’t cleared, all slimes return. Easy mode is the same difficulty settings as last update. Normal mode is slightly more challenging.

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.

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!

Made the lime green unripe banana color in the header a little less pukey. Sharpened the Banana image moderately to look more crisp. I think both of these things make the top area of the page a lot nicer to look at.

Made the font a bit smaller and not-Verdana, and I actually think this improved the readability of most text here. And I modified the way links are presented, so it’s more obvious from a glance which areas are clickable in my messages.

I also updated my About Page somewhat! Now with moderately more awesome.

Oh, and I realized that my posts weren’t displayed tags at all with my custom template. Fixed that. So now you can ‘ooh’ and ‘ah’ at the horrendous categorization metadata you didn’t see before.

That’s all for now. I’m open for suggestions to improve this site more if you have ideas! :D

EDIT: Now with more visible pagination links! And less stupid when there ARE no previous/next pages.

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.

I will return sooner or later though. Later!