Hello again, readers.
It has been about 2 weeks since my big announcement, so I think it's time to lift the veil on project #1, Halberd. I've been hard at work getting the project up and running, and it's approaching the point I left off at right on schedule! This might be the second time I ever get a deadline right. But enough rambling, if you want progress then it's progress that you'll get.
What's Done
Overall, most of the foundational pieces of the engine that I had before are in place again. On the editor side of things, I've only made a little bit of progress, just enough to get up and running. You can place and delete tiles, and I've also added autotile support.However, the game is much farther along. You can already walk around and interact with objects, and I've even got some nice textboxes popping up. The textboxes in particular are a very nice feature, because I've polished them up quite a bit. When you tell the game to display text during the game, it automatically handles word wrapping for you based on the size of the text and the size of the box. That's not all, though! If your text takes up too much room for one box, the leftovers will be split up over extra boxes automatically. This one-size-fits-all approach will be quite helpful if I ever decide to change the size of the text(or the boxes, for that matter). It will also be doubly useful for anyone who needs to deal with localization, since all calculations are done based on the size of the text.
What's Left
Of course, this doesn't quite cover everything. There are still two major features left to implement back into the game, as far as I can remember. The first feature is the inventory system. While the game didn't have much to do with it at the time, there was already a basic inventory that could hold(and use) items. I'm not convinced that I'll be doing this yet, since it touches a lot of other features that I would want to address first, such as menu navigation. The other feature, map scrolling, will likely be my next target. As basic as scrolling to follow a character may seem, it's a tad more involved than it sounds. The old game had its' map system set up to allow a large world with no clear barriers, and it achieved this by streaming in map data as the player moved. In addition, reaching one end of the world would wrap you back to the other side seamlessly(as far as I remember, at least). This allowed the game to completely lack any arbitrary 'map edges' that are so common in top-down RPGs, instead mimicking modern open-world games in this respect. This is something that I plan on adding, of course. I don't think it'll be too hard to remake, but since it's such an important feature I want to make sure that I do this right.What's New
If you've been following this blog for a while, you might have noticed that I tend to add interesting new things when I'm rewriting a project. Just as always, it's true with this project. The biggest, most interesting thing that I've been doing so far is the new animation system. This setup is designed to make adding lots of animations to characters and objects easy on the code side of things. To better explain this, let me walk you through the process of adding animations to a character.- First, the artist produces spritesheets for each of a character's animations, in each direction that they can face. For the uninitiated, a sprite is a 2D image-based representation of an object in a game. In a game like Pacman, Pacman's sprite would be the iconic little yellow pizza-like thing that represents him. A spritesheet is an image containing each frame of a sprite's animation(s), usually side-by-side. In Halberd, each spritesheet contains exactly one animation, but it has 1, 4, or 8 versions for each direction the object might face. More on that later.
A spritesheet of AMAZE's explosion animation 
The resulting animation - A 'spriteset' file is created, with parameters for each animation(things like the name, speed, and whether or not it loops). Note that spriteset is just internal jargon referring to a collection of these animations, I don't know of any widely-used terms for this. In-game, the spriteset's animations are collected into a texture atlas. The latter concept is complicated enough to warrant its' own post, so I'll leave it as an exercise to look the term up.
- Because each animation in the spriteset file has a name attached, a scripter can make an object play any animation from its' spriteset, just by giving a name. That alone is incredibly powerful, since we can just some thing like 'animation("attack")' in a script to make a character swing their sword, then return to a neutral posture when done. That isn't even the best part though...
- Remember when I mentioned that each spritesheet has a version of their animation for multiple directions? That means that you don't need an "attack_north", "attack_south", etc. to make a character animate in different directions. The directions are a part of the animation, and the game tracks every object's direction, so you can use the same animation script call no matter where a character is looking at. My hope is that having a system like this will make creating dynamic and expressive characters a breeze. With any luck, I'd like to see characters that can laugh shrug, point, or just sit down on a nearby bench during a conversation when I make my game. I've seen enough RPGs where characters just stand still or walk around, and do absolutely nothing else, regardless of their supposed reaction to what you say, and I'd love to see that change.
As you can see, the process is quite simple. Just draw an animation, toss it in a spriteset, and you're done. I'm hoping to continue improving this system further, to make it easier and easier to give characters lots of actions.
No comments:
Post a Comment