A Hopefully Intriguing Prototype

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.

You can find it here!

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.

prototypedemo2 — Good thing none of this is confusing!

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.

prototypedemo — Yes, it’s kinda choppy. Yes, vectors would rotate better. But bitmaps have more charm!

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.

My first game launch, as it were

I got off extremely lucky compared to many other North-easterners regarding Hurricane Sandy. In my area there were power outages and the occasional tree falling on some poor sod’s car, but no floodings or fires or what have you. I wasn’t even one of the people who lost power, I just lost internet for several days, and I’m pretty grateful of that.

And not long after my internet returned, my first game is now online!

YOU CAN PLAY IT HERE

As my first game’s launch, this is kinda how I feel right now:

The image is taken from this article written by Derek Yu, which mirrors my thoughts and feelings on finishing a game in a myriad of ways. I mean, I had kinda already finished Why Am I Dead a long long time ago, but only sort of finished it. This time, I finished finished it. And it feels good. Oh, here’s another image from the same article that seems appropriate:

Anyway. With all this excitement, it’s pretty much impossible for my standards of success not to be met.

“This game is too short!” == My game left people wanting more. Success!

“This game confused me.” == My game got people thinking. Success!

“This game was impossible to beat.” == My game was ambitious. Success!

“I absolutely hate this game and I want to injure you.” == My game, uh…created an emotional response. SUCCESS!

…On a more serious note, I’m looking forward to getting feedback and growing as a developer/designer from the responses I get. And of course, other projects are in the works, one of which I’m very overdue on talking about!

Website work, and a new project

For the past two weeks I’ve been doing a mix of website work and programming. My site at peltastdesign.com was quite rough looking, so it was about time that I put more effort into it. This involved more seriously learning HTML/CSS than just the previous dabbling, which turned out to be extremely straight-forward. The result is a cleaner and snazzier, if still minimalist, layout. If you check the site out and have some feedback on it, feel free to shoot me a message.

As is though, the website feels a bit bare under the “Projects” section. That’s because I’ve spent my time working on only a few very time-consuming projects; Mandate was/is a hugely ambitious project, and I spent more time polishing Why Am I Dead than I did programming it. And I can see the strategy game that I’d mentioned beforehand becoming just such a huge, time-consuming project, so I’m putting it on the back-burner. I may still work on it here and there for fun, but it won’t be the focus of my attention.

Instead, I’d like to shift tracks and work on smaller projects which take less time, are inevitably less polished, but still demonstrate a game concept successfully. Not only will this make it easier to keep momentum, but it will be far better practice for me; while there is something to be said for really polishing and smoothing out a game, it doesn’t teach me as much about the artful design of game mechanics. When an artist is starting out learning the human anatomy, do they spend their time inking and coloring their studies, or do they just sketch it out and then move on?

So, since last Wednesday I’ve been working on a smaller idea. It’s a bit of a blend between lots of different things, but could be summed up as a turn-based action game, I guess?

Alpha — Terrible placeholder graphics, ho!

As you can see, it centers around two people duking (or stabbing) it out by selecting different actions during their turn. It draws influences from games that in my opinion make turn-based combat work, such as the Persona series, a Flash game called Sands of the Coliseum, and Pokemon. My brainstorming also involved some very non-intuitive sources, such as Dark Souls, the fighting game genre in general, and Poker. I find that this format (which is usually seen in RPGs) is satisfying because it’s good at abstracting action and making it purely an exercise of decision-making; but usually it ends up hiding behind number-crunching rather than making actually interesting decisions. So my goal was to make a game somewhat reminiscent of back/forth RPGs, but with underlying mechanics more akin to fighting games, which can stand on their own.

The core mechanic is something of a rock-paper-scissors; attacking beats dashing, parrying beats attacking, and dashing beats parrying. Unlike a lot of turn-based games, the results happen simultaneously, so there’s no situations where the first person to move wins. You also submit two actions per ‘turn’, so you have to guess what your opponent’s two actions will be. For instance if I feel pretty confident that my opponent is going to attack me the very next turn, I would submit a “Parry” action to counter his attack, and then submit an “Attack” action to take advantage of my parry. But there’s also the possibility that he waits for his first action and attacks on the second!

You’ll notice the graphics of a body at the top left of my prototype screen; there are five different parts of the body that are separate targets: the head, torso, left arm, right arm, and legs. When you take damage, rather than simply losing “health”, one of these parts of your body is damaged. And if one part of your body gets damaged too much, you lose. Likewise with the opponent. And depending on which part of your body is damaged, certain actions will be restricted. For instance, take too much damage to the legs and you can’t move.

You also have to keep track of stamina, which automatically regenerates and is used for physically taxing actions. You can put down as much stamina as you want on an attack, for instance, and in the case that you and the opponent attack similar targets, the attack with the higher stamina investment wins out.

There are more details about the exact rules of the game, but you get the idea. I expect some of the mechanics to change as I finish the prototype and see which ideas work and which don’t.