First off real quick, after work with a graphic designer I know, I have a new logo which you’ll see emblazoned at the top of this blog. I’m quite happy with the result! With this new logo in hand, I redesigned my home website once again. The results, before and after:
The result is a brighter design with way more space, and a quite sexy logo if I do say so myself! I also used a bit of JQuery in this version of the site, which was nice to dabble in.
The main thing I’d like to talk about in this post, though, is that I put up a game prototype on my website. I’ve been working on it for about a month and a half alongside preparing Why Am I Dead for its release into the wild.
Of course the big issue with it is that there’s no tutorial, so it may take some patience to actually understand what’s going on. I wrote at length about the rules and how they work in that page, so I’ll not do the same thing here. Instead, I’ll talk more about the technical side of things, and why this prototype took over a month to make. Sure, it doesn’t have immediate visual appeal, but that’s not what prototypes are about. And frankly, I did some stuff that I’m quite satisfied with.
1: Menus in menus in menus in menus
The game is turn-based, and, as with most turn-based games, it centers around picking from a range of different options which are on a menu. Some actions may have further options related to those options, which require some other menu. Think about typical RPGs. You can attack, defend, cast a spell, and use an item. But if you select Spell, what spell do you pick? And then, who or what is the target of that spell?
In my case, the details get way, way more complicated. For instance, the actions you can choose from are often restrained by temporary effects. Get hit in the legs, and now you can’t pick Move or Dash. Even more, you can select two actions per turn and sometimes these effects will go away in between those two actions, thus freeing up new actions mid-turn. So, the result is that there will be menus in menus in menus, appearing and disappearing, switching around and changing all the time.
One of my main priorities was to make this as easy and intuitive to program as possible, so that when game mechanics inevitably get changed as the game is refined, actually implementing those changes is painless and straightforward. To that end, I think I’ve succeeded; just about any change in the player menu, no matter how big or small, can be accomplished in several lines of code on the client-side.
2: Customization!
After I got the basic game mechanics in, I decided to implement something I’d only been toying with beforehand; full equipment customization! That is to say, every piece of equipment or weaponry would be represented on screen in battle, and move alongside your character when he attacks and defends, and so on.
The thing that made this a bit more ambitious for me is that I don’t use Flash Professional, or really any tools that might make this easier; I am working in FlashDevelop 100% of the time. Still, it was pretty straight-forward for the most part, if more time-consuming. One of the most vexing issues, to be honest, was making sure that the equipment had the correct rotation and positioning when I flipped the bitmap for the opponent.
And again, I’m pretty satisfied with the results. The work behind making new equipment, as well as swapping between pieces of equipment, are trivial. And though the prototype doesn’t have flashy animations, the poses behind each action are convincing enough to make this effect, at least to me, visually impressive.
So that’s about it. I’d love any feedback on my li’l prototype, since it’s still in an early and flexible stage. I’ll actually be taking a break on this project in order to handle some real-life stuff and other things I’ve been juggling around, but I definitely like the direction this is going in, and fully plan to return to it in the future. With a tutorial, an equipment screen and some kind of metagame, I think this could be a really deep and fun game.
peltastsoftware.blog 