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

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

Early on during the last week, me and Toen were having a nice talk about how so many of our projects fell apart due to lack of interest and direction. This led to a bunch of talk about planning, collaboration, and organization, something I’ve always lacked. After some disccusion, he decided to make an entry about how planning is urgent and so often overlooked (especially when working in groups), and specifically in the Verge community,

This inspired me to take a new approach to planning, and begin to write ideas down in detail before actual implementation. I decided, clarity is essential if I ever want to do something longterm. I think this will prevent feature creep, and keep myself from losing focus.

I started outlining general things that I want out of the gameplay, as well as making some level designs for shmuptroidvania. It will be a mix of bullet-heavy shmup action, and platforming with exploration, and the transition between the two modes of will be relatively painless.
 
 
 
But, then for a while during the past week, I just became too stressed out. I couldn’t really deal with the crappy weather, and the monotony of school and responsibilities. Started sleeping in and missing classes, and generally did nothing. It wasn’t until near the end of the weekend that I started to recover from this stress-induced aversion to work.

But I recovered! When I did, I started to piece together some of the final steps for LuaVerge. Got cracking, and finally put in a system for garbage collected resources.

To request a Verge resource be garbage collected automatically, you call a function v3.GCHandle(handle, destructor_name), which returns a reference that will manage this handle’s scoping. When that reference is no longer used, the destructor is called, and the variable is freed. I made this fairly low-level though, so v3.GCHandle have no public variables or any methods on them. They are a simply a mechanism for gc scoping internals. Here is an quick and extremely dirty example of it being used

function LoadImageGC(filename)
    local t = {}
    -- The resource handle, which is accessed from
    t.image = v3.LoadImage(filename)
    -- The returned table has a gc_handle that
    -- manages the garbage collection of this resource
    -- If this escapes scope, the image handle held will become invalidated.
    t.gc_handle = v3.GCHandle(self.image, "FreeImage")
    return t
end

-- A small scope block, allocates an image, and the image
-- will escape scope directly after.
-- Collection will occur on next Lua collectgarbage() event.
do
    local img = v3.LoadImageGC("hero.png")
end

I mainly put this in for OO wrappers, like the vx library, which of course uses it. All handle-style references use it, with the exception of vx.File, since files must be closed by the user anyway (especially if writing), and Verge reuses handles so defered collection could result in some bad issues.

vx.File was something I added today to the work-in-progress build. It basically wraps the Verge File library, which is surprisingly powerful, alongside the string tokenizing functions.

LuaVerge is essentially ready, but I’m withholding release until more tests are done, and vx is successfully updated. We’re getting there really quick! Then shmuptroidvania is back in the foreground.

Anyway, I’m back, and ready to rock through school and game making.

Tags: gruedorf, LuaVerge, shmuptroidvania, verge, vx

No comments (make one!)

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:

• http://www.verge-rpg.com/svn/verge3/trunk/verge/Source/lua_main.cpp
• http://www.verge-rpg.com/svn/verge3/trunk/verge/Source/lua_main.h

 
 
 
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: gruedorf, lua, LuaVerge, OOP, verge, vx

1 comment

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: gruedorf, lua, LuaVerge, verge

No comments (make one!)

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: brockoly, gruedorf, lua, LuaVerge, verge, vx

4 comments

Okay, so I just got home from another year of school. Now that summer’s here, there’s more time to work, and, more specifically, work on games again!

While this isn’t quite Resonance, I added some really awesome functionality to Verge for ustor’s space game.

A way for network sockets to connect to any port! What does this mean? It means that you can use Verge to do things besides just communicate with Verge! You can get it to do all sorts of neat things, like connect to simple websites (port 80), chat on IRC (port 6667 usually), download from FTP (port 21), the possibilities are really endless! This is the magic you get by adding a simple call to void SetConnectionPort(int port); before you int Connect(string ip);, simple stuff!

Only thing is a lot of servers only deal with plain-text messages, which string SocketGetString(int sock) and void SocketSendString(int sock, string message) can’t exactly do. Oh crap. So that means, the port switching was useless?

That means our lives are over.

Our dreams of making a web browser in Verge to compete with Opera, Internet Explorer and Firefox was crushed.

…

But wait! It’s not over yet! Raw string transfer saves the day and gets the girl again.

There’s two magical functions, like two pieces of an elaborate puzzle. When combined, babies are born — er, I mean — communication can be made between server and client.

First let me introduce you to the lady behind this operation. The super seductive string SocketGetRaw(int sock, int length)! They love the slurpy smooth strings the server gives them with raw relentless force. But only up to 4095 characters, let’s not get too crazy here, thanks.

Pair them with the agressive alpha male void SocketSendRaw(int sock, string message)! They throw violent string uppercuts with their violently raw knuckles and aren’t afraid to kick you in the packets. This sends strings back to the server!

Given the sexy and violent nature of raw socket transfer, it is now up to you, the user to know how these strings must be terminated.

For instance, IRC needs a carriage return ‘\r’ and line feed ‘\n’ after each packet, and also expects that your client will see each \r\n terminator as the end of a packet. But this isn’t too bad, when reading just buffer the string somewhere and loop until newlines are found in your string. And it’s especially easy for sending, just append \r\n onto the end.

Here’s a somewhat screwy screenshot, but it works. I think I screwed up the line display on this. But I can assert that it connects to an IRC channel and spews out: “<TheCoolestGuyEver> It worked. Woo!”

You can get it while it’s still hot and fresh from the Verge subversion repository!

URL: http://www.verge-rpg.com/svn/verge3/
Username: anonymous
Password: anonymous

I’ll be back with more exciting verge changes or Resonance action someday soon!

Love,

Overkill

Tags: gruedorf, networking, verge

No comments (make one!)

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: gruedorf, lua, LuaVerge, resonance, verge

6 comments