There are now 4 characters on screen. Whee.

So, Sully’s Battlesystem had a problem.

It worked well as long as you had character 0 in party slot 0, and character 1 in party slot 1, but as soon as anything changed from that configuration… shit got real.

The problem was due entirely to vergec’s type-poor environment.  In the battle system party[party_idx] and party_idx were used interchangeably.  Hey, they’re both ints and they look the same, right?

After identifying the source of the issue, it was a matter of a global search on “party[” and identifying the spots where it was misused.  I’ve also wrapped this whole operation in a function to give a level of english for humans to see and go “oh, maybe I should give thought to this.”

This whole conundrum is a non-issue in the modern world of programming, what with fancy objects and classes and types.

The most fun part about this is, once I solved the party reference problem, there was a renderstack problem of exactly the same type, where renderstack references and sprite references (which are stored in two different int-indexed global stacks) were used interchangeably. I was already in the mindset to solve this issue.

The whole task is documented between r187 and r197 in the sully svn repository.  Top to bottom the tasks were about 8 hours of braining and typing.

It’s my fault for continuing down this path of madness, but there’s a massive amount of code and effort in this so I have lock-in.  Converting the whole thing to Lua would still have these issues to track down.

I also started work on a map editor coded in vc. If everything goes well, Overkill will be joining in on this on his next update.

Finally, I updated the Sully codebase to the mark 5 render engine: now with fully functional clickable renderstack items! Yay!

Bet you didn’t know there was gonna be
tools… other than me, that is. :(

Today’s Gruedorf update is all about the game’s heads-up display. I’ve been meaning to implement this for years now, but I’ve been putting it off continuously.

The Astrad is inspired heavily by Wild Arms and Lufia 2. The top-left meter will be similar to the Wild Arms 3 encounter meter that lets you skip out on battles, except it’ll (when implemented) be more of a builds-up-pressure type thing than the Wild Arms 3 “countdown” gauge. At least, that’ll be what happens in “field” areas. I’ve got a few uses in mind for it as a feedback device in “Town” areas, mostly for use in conjunction with the equipped tool.

Note, the graphics for the meter aren’t final at all. There’ll be more of a papery feel to the center bit, with a green->red metery type thing, I think. I plan on more pipes and lights (more than the current count of zero, at least) on the widgety area, so steam can leak out of the apparatus when the meter’s in the red zone and lights can blink and such.

You’re such a tool.

The brown boxy area to the right of the metery area is the currently-selected-tool indicator. Currently empty because I’ll be getting to the tools section next update, it’ll have a left/right button to mouse-flip through them, a “help” button to summon a description of the tool and everything that you “know” in game that it does thusfar (ie, you need to be told what it does by someone or need to use it in a certain way before said atom of information shows up on the help screen).

There’ll also be somewhere in the HUD, most likely directly right of the toolbox, a meter showing Onam’s current MP level. This is because some of the “tools” are actually magic spells that can be used upon the environment. And not 0MP spells like Lufia 2′s “Reset” spell!

Out, out, damn spot!

Transitionlicious. The UI fades away when not in use.

In “peaceful” areas, the Heads-Up Display will fade away when the mouse has been left alone for more than three seconds, as long as nothing is changing up there. As soon as an alert summons it back, it’ll come back. Such triggers like flipping through active skills with whatever controller buttons are mapped to that action, moving the mouse, triggering a HUD message banner, and so on

Electronic Rodents

You all may have noticed that last week’s release and this week’s release both have mousey components. Well, The Astrad is mainly a computer game, so it’s foolish to not use the main UI device of the common computo-box for the game. I’m planning on having every element necessary for gameplay accessible both via 8-button controller mappings (that’d be a digital D-pad, A/B/X/Y/L/R/Select/Start just like a SNES) that you can map to the keyboard or a compatible joystick, and simultaneously only need a mouse (if present). Sorry kids, you need a mouse or a keyboard or a controller to play this game. No telekinetic controls yet. :(

Movement via mouse is planned much akin to how Ragecage/Tristan accomplished it in The Snowscape Battle System HoV entry. That being an A* implementation where you click on an unobstructed tile and it tries to find a path. My system will be a bit more picky in that it will only try to find a path through visible areas fairly close to the screen’s visible boundaries. No autowalking across town if there’s a large obstructed area in the way between two visible points.

The Astrad

Today’s last point of order: I don’t recall if I ever publicly explained that “Saga of the Stars” is the translated title of the game, whereas “The Astrad” is the real title. It’s shorter, lexicographically close to the beginning of any name list, and has a properly gruvian level of pretense, what with the faked Latin and the idea of evoking “The Aeneid” and “The Iliad” (which, of course, will not hold even the meanest candle to my finished work when completed. Take THAT, Virgil!)

So, in effect, I’ll probably still call it SotS while referring to it as “The Astrad”. Think of it as PSX meaning “Playstation” due to changing plans. Or whatever. You can retcon whatever story you’d like.

Click here to download the third Gruedorf release of Saga of the Stars/The Astrad/Grutopian Delight/etc etc etc. You’ll be glad you did… unless I’m lying.

…and technology!

It’s that time again, entry 002 into the gruedorf challenge. Things have picked up in this challenge, with ragamuffin me-tooers joining left and right. Of course… none of them get top billing because they are neither ‘grue nor ‘dorf. Or using verge, for that matter. Tsk, tsk. Well… maybe we could make it the Gruedorf Code Challenge, since Code totally is using verge, and he has a suitably confusing nick. I guess to disambiguate we’d then have to make it the GrueDorf-Code Code Challenge. You know. For that ironic sort of disambiguation.

But I digress.

that slime is totally from sully. Thank Overkill.

My current update is a few hours of work into improving and debugging my vc-based Render Engine, lovingly known as the McGrender Engine. Currently in it’s 5th version (#4 is in the current build of Sully), it allows for custom auto-animated sprites, static images, or “roll your own” functions (ie, Callfuncs that get triggered when they’re up on the stack). All this is put into layer functionality so you can turn on/off layers as needed, and, say, render fancy effects between your background and your sprites, or just effect the PC sprite layer while not touching the enemy sprite layer. Etc.

Also in here is bubbling click items. Any image on in the McGrender system can be given clickable properties with a bubble-down effect: that is, if you had three clickable items layered on top of each other, you’d only activate the topmost visible clickable item.

The most notable virtue of the McGrender System in this demo is it’s automoving feature… which, as trivial as it is, is the reason I made mk I a few years ago. I just wanted to throw a sprite that, while animating, would move it’s location at an even rate without me having to worry about it after setting it. Unfortunately, non-linear movements presently need a custom function (whereas an OOP system could have some custom, but more reusable, implementation of the “Hey, I move in some way!” concept), but that’s fine.

Another small, but handy, feature that lets this bitch be largely hassle-free in keeping itself moving is the optional “OnStopMoving” callback function. You can see this in effect in the demo with the close-button’s movement. Everytime it stops, the rebounceX() function is called setting new destination coordinates and sending it on it’s merry way.

Instructions for seeing this in action

Okay, if it wasn’t apparent from the screenshots, talking to any of the flasks in the first room will start you into the rendertest demo. For the interested, the pertinent code is all in ./vc/rend/ with the mcgrender.vc and sprite.vc being the “system” files, and test_render.vc being the implementation of this demo (ignore general.vc in that dir… that was me being laaaazy).

once you’re in the demo, you can click on the slime to watch a demo of the sprite-autohandler (changing from “idle” to “death”) being triggered by the clickable feature, and clicking on the floating winXP “X” will stop the render engine demo, whereupon you can talk to a flask ans start it over. Exciting!

Click here to download the second Gruedorf release of Saga of the Stars/The Astrad. You’ll be glad you did… probably!

One last thing: new music!

Zathras was inspired to make the fourth major revision to Castle Alden’s music, which is far and away the best version to date. It’s much more soothing and gentle on the ears, and has a lot more in common with both Onam’s Theme and Amin’s theme. Nice! You can also check out Zathras/Matthew Steele’s Homepage at the newly minted zath.org. Good times.