Hello!~ ♥♥♥

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!

Tags: bananattack, gruedorf, website

No comments (make one!)

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: brockoly, C++, game engine, gruedorf, lua, plum, unemployed

No comments (make one!)

So I didn’t remember to mention it, but, earlier this month, me and my housemate decided to make games in a little bit of a game making showdown. A horrible, horrible game showdown.

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.

Tags: compo, gruedorf

1 comment

Yeah, so, a couple posts ago, I mentioned Gamagame (The Game Making Game), which was supposed to be a fun way to keep tabs on what sort of progress I have left.

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.

Tags: gamagame, gruedorf

No comments (make one!)

I remade my first compo game, Quest for Colour for fun this weekend. It was a neat experience. It taught me a lot about my old art and code, and how I’ve improved since then. I had plenty of head scratching puzzle along the way.

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.

Tags: art, compo, gruedorf, map, verge

No comments (make one!)

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: anonymous functions, callbacks, gruedorf, lua, LuaVerge, OOP, textshmup, vx

No comments (make one!)

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: 24 hour game, compo, gruedorf, lua, LuaVerge, shmup, textshmup, verge

1 comment

I’m putting this project on hold temporary, since I have exams. I also want to participate in Thrasher’s 24h compo idea tomorrow, and I want make a twitter app to automate Gamagame.

I will return sooner or later though. Later!

Tags: gamagame, gruedorf, resonance, twitter

No comments (make one!)

So I had earlier abandoned Resonance for another game idea, thinking it was the right thing to do. I figured that Resonance was too complicated, and would require too much work to get anywhere. In a way, I was right, but now I realize that I was also mistaken in these judgements. It was complex, but not to the point of disrepair. It just needs some loving and nurturing.

Upon review I know of several ways that I can make this idea work better. In addition to that, I have a lot of existing code for Resonance, that simply needs moderate updating to work with new ideas I’ve acquired.

I’m thinking of reducing the complexity of Resonance quite a bit, so that it’s more fun, and more structured for use in story and level design. Level design is something I desperately need to improve, but I think I’ve finally formulated some ideas to remedy that. Once I’ve verified that they work for me, I’ll be glad to share them to everyone reading this.

I know how vague this sounds right now, but I intend to turn my development around. Sticking with a project has always been difficult to me, but I think Resonance has many things that I consider good for a full game.

School is consuming my time, and it’s confusing my thoughts. I don’t write things down and plan enough, and this is why I have been all over the place with my development time. I end up adding things to engines which ultimately I don’t even need, or making my life needlesssly challenging by reinventing the wheel. I distract myself with various tiny details rather than working toward a bigger picture.

So Resonance it is. What I need for the game will determine what I spend time on. I have yet to develop a full list of what I need, only ideas.

Thus my immediate task: To jot down what Resonance had before, and what Resonance needs to become a feasible project while not compromising on fun.

Oh and I might also sink some time into making a simple site for this silly Gamagame challenge I’ve imposed upon myself.

Anyway. Until the next incoherent babble post, farewell!
 
 

Summary (as of March 30, 2009)

Productivity Points: 15/21 (-4 for days since post, +5 for deciding on the game idea)
Tasks for the Week (Must sum to 10 points):

• Describe how to scale back the old game system by reducing complexity. (4)
• Decide on how much code can be reused. (1)
• Come up with a rough story outline (2)
• Come up with actually concrete designs for the first level of the game. (3)

Tags: gamagame, gruedorf, resonance

No comments (make one!)

So, after agonizing a lot last week, I came up with an idea. A ridiculous idea that started as a joke. One so ridiculous, it just might work for real development.

Let me present to you a challenge. I call it Gamagame.

Gamagame is a one-player game where the player (literally) plays the role of a game creator!

Starting off
The player starts by deciding what sort of genre and the expected play time of their game project. The player will then be thrown into the world of making games. There are plenty of adversaries and events to overcome in the Gamagame world, and it is the duty of the player to conquer them.

Basics

• The player starts with 14 Productivity Points. This amount is lowered by inactivity, and rewarded by constructive activity. Details on how to gain and lose points is described below.
• The player can have a maximum of 21 Productivity Points initially.
• When the player has 90%+ of their Max Productivity Points, he is “kicking ass”. Streaks should be noted.
• When the player is above or at exactly 30% Productivity Points, he is “okay”.
• When the player is below 30% Productivity Points, he is “crawling”.
• When the player has 0 Productivity Points, the project is considered “idle”.
• When the player has -7 Productivity Points, the project is called “frozen”, and Gamagame should probably end before it becomes shameful. It can be continued though in an attempt to rescue it.
• When the player has -14 Productivity Points, the project is called “buried” with no chance of rescue, and Gamagame ends with shame.

Getting Points

• The player gets 5 points for coming up with the initial game idea.
• After the initial idea, the player splits assigns a bunch of tasks for each week. These can be broad categories for later weeks, but should be solidified ideas when getting closer in time. The player rate each task for the current week, with 10 points to divide between all tasks for that week. Fractional points may be given. The point rating assigned is the reward of productivity points the player gets upon completion.
• The player can announce their intent to get extra work done (that is, tasks for later weeks), for a fixed 2 extra productivity points at the end of the week. The points for the extra tasks themselves aren’t rewarded, only the fixed 2 point reward at the end of the week. Failing to do anything by the end of the week after intending to do extra means that 3 points are lost.
• The player can put Gamagame on hold for as long as they want, if there are distractions like work, school, or various life events interfering. No productivity points will be lost. But all delays should be counted, and for every 14 days spent on hold, 3 productivity points should be lost.

Penalties and Project Progression

• For each day on the project, 1 productivity point is lost.
• When the project is considered 50% complete, the penalties double, and max productivity points goes to 42.
• When the project is considered 75% complete, the penalties and rewards both double (penalties are then quadruple the base), and max productivity points goes to 70.
• These can be adjusted if they’re too ravenous, but make a note of it, and don’t intentionally cheat the system.

Teammates

• If the player is to enrol other teammates, don’t include them in your game score or anything (especially don’t make them play this silly game unless they’re as crazy as you).
• If they complete one of YOUR tasks, you get points for that, but don’t deliberately put their tasks under your tasks for the week.
• The only other effect team members have: any teammate who ends up doing nothing or qutting costs you 3 productivity points when you realize this.

Ending Gamagame

• Gamagame is won when the project is 100% complete and released.
• The player loses upon forfeiting Gamagame, or by being “buried” shamefully for having -14 productivity points.
• Keep track of how many wins, loses, and shames you have. They could indicate a problem with how you’re developing games!

 
 
Also note the fixed reward of 2 points for doing extra tasks each week. This is to somewhat prevent being sidetracked, and to ensure that new ideas are considered ahead of time and waited on, instead of being thrown in for no reason. 2 points alone isn’t enough to save you in the long run anyhow.

Anyway, let’s begin craziness!
 
 

Summary (as of March 26, 2009)

Player Info
Name: Overkill
Productivity Points (-1 per day of inactivity): 14 / 21 PP
Status: Okay

Game Info
Game genre: Sidescroller + shmup (possibly a Shmuptroidvania, we’ll see)
Expected play time: 3 hours

Here we go! Now to hopefully not lose at yet another thing. May my craziness be a rewarding thing.

Tags: gamagame, gruedorf, sidescroller, what is wrong with you

1 comment