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

No comments (make one!)

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

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: lua, LuaVerge, 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!)

I made a few updates update to Bananattack. Nothing tremendously major, but probably noticeable.

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.

Tags: bananattack

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