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

Get it here.

This screenshot doesn’t do it justice, run the build to see it in action - much prettier when not captured in a still!

Anyways, this distortion effect allows me to add transitions for the player between different their appearances, and also add useful “in danger range” distortion for losing weapons (which I think will be paperdolled onto the player — in a way that it actually looks like the player’s gripping them though) or when close to death. I’m not sure how expensive this effect will be in game, but it splits each row of the sprite and scales it according to a shrinking distortion range, with a slight lucency fade for extra aesthetic points. If it turns out this effect is too expensive to put directly into my game, I’m sure nobody would mind much if I incorporated the routines into v3’s raw C++ internals.

I need to refactor my image splitting code a tad, since the distortion currently assumes a that the image that’s being split is never updated. So if the player were to ever change frames (when I actually have animations), this should affect the strips too. I’m thinking I might be able to get away with just one buffer 1xheight that’s blit on several times and scaled back to the screen, but that might be SLOWER? Who knows.

Oh! I also did another useful thing. Several people pointed out that my player was firing shots from his crotch. So I moved the firing location higher up on sprite. I still need to draw firing frames, jeez! I’m getting there. Art has just lost priority for a bit, since animation is a weakness of mine currently.

I’m looking for eager artists and musicians still! I have a few positions actually, and with it I’ll outline a few basic responsibilities:

Artists: you should be able to draw in a style matching the existing art so that if you decide you’re too busy I’m not stuck filling in and adjusting clashing artwork.
Musicians: Up to interpretation really. A lot of the music will probably be ambient electronica or post-rock. Boss/heated situation music might be a little more orchestral. Old-school chiptunes might be okay in some areas too, but I don’t exactly want to end up with a game comprised only of chirpy beeping and buzzing.
Level design (and for that matter general design): Having another hand in the level design makes my job easier, and populates the world with fun and creative gameplay. You’ll really have to run by me on this one, because if the maps suck, the game sucks, simply put. But if I have a level designer, I’ll get more drive to put in various game features and abilities as demanded. You’d also have some influence on the story, naturally. Cooperation with the artist and musician is highly required to ensure the game’s resources are adequately utilized.

If you know people who meet these criteria who might be interested, please please please get them in contact with me (or leave me info so I can talk to them). I’m relying on you to help me, because you can really help me pump out an awesome game much faster if I have resources at my disposal! I’ll want samples of their work unless I know them already, but this only sounds fair. Of course, this is entirely unpaid work. I’m a college student, I don’t have disposable income, so this is all a hobbyist’s plea for help. You will receive credit for your work and if in the very unlikely instance this game ever was released for profit, I’d make sure you guys received a profit. You at least get the merit of saying you helped Overkill accomplish something great.

Note that I’m not relinquishing my control from this game, but I think that having other team members could make this go much smoother. It reduces my burden in development, because I’m a busy guy, and makes the weekly updates more impressive and less likely to fail!

Love you guys tons.

The minimap is a lot less crappy. It scrolls with the camera and it uses slightly smaller map regions.

Get it here.

Made a Mungo file to store bullet information, called “bullet.mungo”. It makes specifying the similar bullet types made by a single attack much easier.

Lately, I’ve also been thinking some sort of “data inheritance” to Mungo might be useful if I reused this for other games:
* Fighter - name: ? - hp: ? - strength: ? - defense: ?
* Player < *Fighter
- name: Clyde
- hp: 100
- strength: 324
- defense: 112
(Note that this is an example, not actually implemented and it’s not for this game). Where < is an inheritance operator which takes a list delimiter and list item name to inherit from. It would let you get away without having to repeat specifying data in common with multiple things, and also to ensure that information is “implemented”.

Sorry, I have to write this in a hurry this week. But check it out! Weapon levels have new fancy bullets and the minimap looks cooler! Now I’m out. Laters.

Using it, I added a animating health meter to Resonance!

Get it here.

I’m not sure if this is this the sort of health gauge I’m going to stay with, just need something for now. I might switch to a percentage-style meter system which Megaman, Cave Story, Kirby Superstar, Castlevania, and a ton of games use. It’s a little more nice than a tick-style system, in that you get in-between health amounts, but slightly less fun to look at, because there’s less artistic representation usually with these sorts of gauges. Then there’s Metroid, which has several energy tanks and an active tank which has a health rating out of 100 (plus reserve tank which effectively doubles the tanks you get).

Oh, and then I need to think! How will underwater breathing work? Lots of games just let you breathe without penalty (NES/SNES age Marios on levels where water isn’t a deathtrap, Metroid, Kirby), or somehow keep you from going in water until you get a proper ability (Link to the Past), or keep you from going underwater but you can still swim until you get an ability (Aria of Sorrow). Then there’s Ocarina of Time, which had it so you’d just float back up after 3 seconds of diving (unless you get stuck underneath something, then I think you got hit with damage until you surface). Then there’s lots of games where you have limited air supply and start taking damage after air supply runs out. Cave Story took this too far, and just had you die instantly after about 15 seconds (100 air) elapsed without surfacing, which I didn’t like. Then I remember Mario 64 (and Sunshine, and maybe Galaxy, too?) had this wacked out health system for breathing underwater that overlayed your current health. Oh, the dilemma of water handling in video games!

Moving on, you can take a deep breath again, I find thinking about water levels a lot affects my breathing slightly!

I recently cleaned up a lot of unused files, and renamed the ‘chr’ folder to ’sprites’, because none of the sprites use Verge’s CHR system (instead they use Mungo, a simple associative data language!). I might eventually move all my resource files into a folder called ‘resources’ or ‘res’, just to tidy up things and give my data a bit more hierarchy!

Oh, and I renamed my ‘v3′ namespace to ‘vx’ after Kildorf and I decided to rename the ‘LuaVergeRaw’ (internal v3 binding) package to ‘v3′, which was a better name. vx stands for Verge eXtension!

Since I don’t know how much I mentioned it before, vx is a slightly object-oriented approach to wrapping the v3 library, addressing some personal gripes with the classic library and making it nicer to compose with OOP. Kildorf seems to be doing the same thing, but I’ve did it first! I made my library before anyone actually knew LuaVerge existed! Zeromus and I meant it to be the official middleware wrapper to LuaVerge, but unfortunately there were a few things holding it back, and I’ve since decided that the ‘classic’ verge library should still be accessible to those that aren’t comfortable adapting to a new API.

Nonetheless, vx is kickass. Some people might appreciate its slight similarity to ika’s library, but it’s nicer to use in some aspects. For instance, a vx.Image is more powerful than ika.Image and ika.Canvas combined (in terms of how easily it can be manipulated — not so much render speed sadly). I think this could definitely be useful for those ika users who are on the fence but like Lua. Additionally, it can be intermixed nicely with the raw, classic bindings of Verge3 (which are also pretty solid) when this alternative API seems to be too much of a stretch. So if you were interested in LuaVerge, but wanted an alternative library that caters to your Lua script-kiddie OOP-seasoned mind, you might want to use vx! If you have questions about using this library, feel free to post on the regular Verge help forums, since I endorse this, and I want to make a usable game making interface.

I would NOT, however, recommend jumping to a new language midproject. If you’re actually getting somewhere using VergeC, why waste more time to learn a new language, and then rewrite your code? LuaVerge is certainly easier to pick up than VergeC, if you’re starting something NEW though!

Oh yeah, and I have an SVN for Resonance now, for those that are interested: http://www.verge-rpg.com/svn/resonance/ (username: anonymous password: anonymous). The latest version of vx is always included in this SVN (for now, and hopefully forever). And here’s the vx documentation for those who want to see: http://www.verge-rpg.com/svn/resonance/vx/docs/vx_readme.txt (once again, you’ll need that SVN password). (Update: Things changed a bit. Please see http://www.bananattack.com/vx/ for the latest information about vx!)

In other news, Thrasher, the metric unit for failure, has returned. Now I’ll have somebody else to make fun of again!

Now I depart. Look forward to more meaningful progress again on Resonance soon!

Love,

Overkill.

Get it here.

In this release, I also added in a small amount of interaction with beacons, so you have to find and turn on/off beacons to use/not use them by pressing Up on the keyboard. Z still shoots things, you just need to activate the fusion pistol beacon first. Sometime I’ll add new beacons besides just the map beacon and the fusion pistol thing and things will be more exciting and enjoyable for everybody!

Anyway, that’s about it for now. Enjoy, and hopefully I won’t fail next week, and I’ll see you by then. Later!

So this week’s update is pictureless and buildless. Supersorry. Forgive me, etc. I have other stuff on my mind, sadly. I have been thinking about my first area’s setting though and I think as long as I take it steadily, I can make a gorgeous and slightly atmospheric environment for this game. We’ll see though.

Love you and see you next time,

Overkill.

I’ve been doing very, very tiny changes to the engine. I made an exporter for Mungo, and made it so the game will popup messages when you newly encounter abilities. Also, drew slightly nicer artwork. Updated the hero a bit to have a slightly nicer head, and a scarf, and some color enhancements. It actually mirrors well too, finally. Been drawing some other sprites too, but I’ll leave displaying them until I’m satisfied with how they look.

The grass was also given a tiny makeover for more enjoyable aesthetics. The grainy high contrast dirt was hard on my eyes, so I replaced it with transitioning the grass into darkness. Oh, and I added fancy-pants 60 degree angle hills for more landscape variation!

Here’s the updated tileset as it appears so far!

I’m thinking the water will need a redo, because it doesn’t look very pleasant at the moment and I’m not sure how to animate it without looking totally cheap (right now it just goes back and forth).

Oh, and I want to start on this underground mine cart level I had in mind sooner or later, cause that’ll be cool. That requires completely new landscape, with lots of dirt and wooden frames and railroad tracks! It’ll also need rideable carts and, I’ll need to make moveable beacons that can be loaded into the carts. Maybe drippy ceilings with puddles on the ground or even enemies! Cause that’s right, I have an awesome level idea in mind!

Here’s a game screenshot and stuff:

No build this week, since I’m running out of time and there isn’t really enough for it to be worth bragging about. I move back to school tomorrow morning so I can’t do the usual “get up early Sunday morning and slap together another more awesome Gruedorf” routine. Yeah, so I need your encouragement, folks! I don’t want to drop my progress just cause I’ll have a social life and school work to do again. Well, gotta run. Enjoy.

Lots of headway made during this holiday week. Get it here.

I basically decided to not use the verge entity system because it’s incredibly slow for some reason in LuaVerge even with raw bindings, which means something’s wrong. Also, there are some special sprite information things that can’t be easily linked to chr files. So I made my own custom sprite format in LuaVerge, which I like to think is somewhat better (what with custom animations and some other things).

My .sprite format uses Mungo, a simplistic data association language I invented on Christmas Eve, which is easy to write, making it mostly painless to edit a sprite file! It’s a lot simpler than, say, XML (for writing and especially parsing), or YAML (for parsing, and also sometimes for writing), or most language builtin ways of structuring hash tables/dictionaries. The only real pain is having to figure out each frame’s width and height manually, but you sort of had to do that anyways to use a CHRMAK file. I might try and come up with an auto detection thing at some point.

Using Mungo again, I placed in a simple ability system format, automating the projectile shooting and animation scripts for weapons a bit. I noticed that Mungo slightly suffers at doing numeric lists of items, I might try and fix that, or at least allow the parsers to convert numeric strings into numbers, to make for simpler use with Lua’s ipairs() method.

I also made a minimap generation system. It’s pretty simple really. It checks each screen region of the active map, and if the outer edges are obstructions, it places wall markers for those. If the inner chunk of the screen is fully obstructed, then that particular screen region is obstructed and won’t be displayed on the minimap. Then I added the typical Metroidvania map panel discovery thing, where only visited screens appear marked on the map. Eventually, I need to crop the minimap to show only the room close to the player’s position, but whatever, tiny details.

Oh yeah, and I actually associated the beacon system with the ability system! Which is cool. Because now you can watch as things level/delevel from your proximity, and can actually do stuff with abilities. It’s good! So yeah, now the Z key actually actually shoots stuff rather than just making sounds! The beacons in this demo are just demonstrative of course, and have much shorter broadcast range than what I actually have in mind for a completed version of the game.

That’s this week’s Gruedorf! Look forward to more next week (hopefully).

Full with an incomplete jumping frame, cheap looking idle stance! I also separated the box drawing routines from the textbox code, allowing me to reuse the box style in other UI elements. Oh, and I messed around with sfxr a tad and made a few sound effects, only about two of which are included. Press Z to hear an explosive sound effect, and jump around to hear a stupid thump sound! I swear that soon, I’ll put in the ability system and you’ll be able to shoot/attack stuff! ;_;

Okay, this week was completely lame. I don’t even know why, because I’ve had copious amounts of spare time! Must just be me. D:

STOP YOUR ALMOST FAILURE, OVK, AND DO SOMETHING COOL FOR ONCE. Please nag me to start making games again to ensure I don’t get distracted with pointless Christmas stuff this week! Okay?

I’ve also come up with a semi-interesting way to do Resonance’s story. The main player is typical person, no real special powers or something. Then he and a few allies are assaulted by some monster thing. The player defeats it, but then an explosion occurs which propels an antenna tower into him, pinning him to a transformer, and impaling him and destroying him entirely. Several communications towers across the world no longer “work” after this.

The player is somehow given a second chance to live as a magical electrical field thing that has the deceased hero’s form. He initially gains an armored suit in order to disguise his appeareance because he is, by all human accounts, dead. The player is only kept alive by being in close proximity to at least one beacon (that is “broken” by human standards because they no longer transmit communications - but resonate with our player) AND a finite “health” meter.

Initially, things like metallic objects and thunderstorms, adveresly impact the hero by forcibly pulling him along them and getting damaged upon reaching an end. Thunderstorms would displace the player and be near-lethal. Stuff like maybe railroad tracks would “teleport” the player all the way to the other end of the track. Later on, these things will have no effect on the player, but initially, it would help to constrain the player’s exploration in order to teach them some things about the gameplay and it could also make for some interesting story sequences!

The player is motivated by a mixture of causes, but prevailingly a desire to return to natural human form and to explore the scientific mystery they’ve become. Eventually, the player will be capable of returning to their initial human state, but things won’t be the way they were, people will move on, and the player will realize essentially how weak they are outside of their “resonant” form.

In addition, various nit-picky art fixes were made, and I’m still not satisfied. But I may as well just move on for now and animate the damn thing:

Lastly, I made a textbox! A very sexy textbox. Check it out:

Here’s this week’s build, so you can see it in action, and most importantly, hear the really horrible punchline!

Now I’m off. Look forward to more posts hopefully, because the holidays are typically rather boring. Das ist alles.