Took a bit of a detour over the last couple of days to try out an idea for a swordfighting game mechanic that’s been stuck in my head.

There’s a lot that’s janky about this, but it’s been nice to just dive in to a couple of random ideas and explore them.

First:

swordfighting

The idea here was to tackle a number of things I don’t like about first person shooters. I like how immersive the environments feel in first person games; I like 3d platforming, and I like the lack of item trays in your typical FPS. But… I don’t like the shooting so much.

The solution was swordfighting. You can’t see a sword in my prototype, but the idea is you can thrust or slice with your sword, wearing down an opponent’s shield. Every time you slice, you divide the shield into smaller fragments. You can thrust at a small, red-highlighted fragment to destroy it. Really small fragments simply disappear on their own.

So here are some things I had in mind:

hit or miss

In an FPS, if you shoot something, you either hit it or you miss it. True, there’s something kind of satisfying about lining up a perfect headshot (if you can stomach the subsequent gore), but I just don’t find the act of shooting that interesting. Your targets have X health points, each shot does X damage; do enough shots and the target is eliminated. It’s not something that’s expressed in a very visual sort of way.

So here, you eliminate a target when you’ve gotten rid of their shield. It’s pretty easy at first, but when the shield starts to wear down, it can be a little tricky to line up slices in such a way that they cut a maximum number of remaining shield fragments.

I find the act of doing this kind of fun and visually interesting.

abstraction

You don’t fight your opponent: you fight their shield. There wouldn’t be any blood, or dismemberment or anything; you’re not thinking about the damage your weapon might cause to someone’s flesh. As soon as the shield is gone, the opponent can conveniently vanish in a puff of pixels.

(I might have your opponents be all mechanical anyway, because I’m still squeamish about showing harm to living things.)

health bar

Your opponent has no health bar; the more shield they have left, the healthier they are.

variation

Let’s say a shield fragment turns red and can be thrusted away when it has an area of 1 unit. And shield fragments under 0.5 unit simply disappear as soon as they’re created. With that in mind, the following things happen:

An opponent with a shield 0.6 units in area can be eliminated with a single thrust.

A single slice will probably do it too. You can be messy: if you divide the shield into one 0.2 unit fragment and one 0.4 unit fragment, they’re still under 0.5, and both fragments will disappear after the slice.

Go up to 0.8, and you’ll have to be more careful about your single slice, say, dividing the shield into two equal 0.4 unit halves.

At 1.2, a perfectly-centered slice will result in two 0.6 unit fragments that don’t disappear outright, but which are small enough to be thrusted away.

And anything above that size will require multiple slices, which the player will (hopefully) have to put some thought into arranging if there are time constraints of some sort (like, you know, taking damage).

You could even have shield so big you you have to jump up to start your slice and continue it on your way down.

I like this sort of progression. The difficulty scales in a way that isn’t just about spending more time in the fight or taking more damage.

problems

All that having been said, there are a few problems that will probably prove difficult to solve.

animation

I do not relish the thought of modeling and animating a believable sword and jointed sword arm that responds to your movements.

cursor

The mouse is used both for movement and slicing: at present, your sword tip is always at the center of the screen. Besides looking very unnatural when you do actually have a visible sword and arm, it makes placing your slices feel very awkward. While slicing, I expect the camera to stay relatively still.

height

If your opponents are the same height as you, you’ll constantly be looking down at their shields. Again, awkward.

symmetry

I’m having trouble imagining giving the player their own shield that follows the same rules as the bad guys. The controls could be awkward or confusing, and you wouldn’t even be able to see most of your shield most of the time.

camera

Incidentally, I’m also experimenting with a sort of fisheye camera. Your horizontal field of vision is around 120 degrees, but it’s a cylindrical projection, which minimizes distortion on the edges. Of course, this adds some distortion to what would be straight lines in a regular projection.

Ideally, I’d want something that was sort of like you were standing inside a cylinder with the world projected onto it… and then took a couple steps forward. So when you turned, there would be a little bit of distortion, but not as much as a regular planar projection. But that would involve lots of matrix math I don’t understand.

Overall though, I think it feels fairly natural. I don’t like how limited your vision is in most first person games.

to sum up

I think this has potential. Who knows when/if I’ll develop this more; right now, I’m just glad to have the basic concept out of my head.

All done with my first Ludum Dare. You can see my game here.

So have some ruminations.

theme

I really could not have been less enthused about the theme. It was ‘evolution’, and while that’s frequently used as a synonym for ‘growth’, when I hear that word, I think of the strictly biological definition of evolution: groups of genetically dissimilar organisms dying off, and leaving the survivors to pass on their genes, slowly changing the genetic makeup of a species over time, not because the individuals themselves are changing but because the selection of individuals is changing. Growing up in an area where there was a lot of uninformed anti-evolution sentiment, I’m very particular about how I use that word; it’s impossible to have a rational discussion about evolution as a theory if you’re not precise about your terms (theory being another word that doesn’t mean to regular people what it means to science grr).

Anyway. From that point of view, evolution is an inherently impersonal concept. You’re stuck with the genes you’re born with, and you either breed or you don’t.

Which is icky since I’d set myself the goal of making something with a relatable story.

However, after much head scratching, I decided that instead of making the individual — the player — change over time, I’d make the level design evolve based on the player’s choices.

Conceptually, that seemed pretty cool, and a great solution to the problem at hand… but it needed a lot more fleshing out, as I’ll get into later.

scope

The first thing they tell you at the game jams I’ve been to is to be careful to limit your scope.

The level breeding mechanic I had was pretty limited in scope: you wandered down a skinny path with various pits and obstacles and were presented with a fork; each path on the fork would be a variation of the path just traveled. So if you hit a fork and the path on the left had lots of pits and the fork on the right had lots of trees, and you picked the left path, the next fork would present you with options with lots of pits.

From a technical point of view, this was simple enough. I had my branching, evolving paths by the middle of the first day.

The problem was, I wanted to use this to tell a love story kindasorta related to The Road not Taken.

You’d be presented with diverging paths, and while you could not ordinarily ‘travel both / and be one traveler’, as the poem goes, you could find a traveling companion. Then, you would travel together, but you could also travel separately, and share your experiences of two paths, because companionship isn’t always about being together; sometimes, it’s about your experiences apart, because, fundamentally, the only way we can experience everything is to share our limited experiences with others…

…in many ways the scope of this story is massive. Not because it’s epic or generation-spanning or has lots of locations, but because of the emotional complexity of what’s supposed to be going on. Communicating my themes verbally is hard enough; communicating them just through visuals and mechanics would be a truly herculean undertaking.

Getting this to work, I realized very late in the jam, would rely on a couple of difficult-to-express intangibles:

• The player has to have a longing to go back and take the paths they missed before.
• Once the player and their companion are on separate paths, the player has to have a richer experience because of it; the sort of thing that is richer than the sum of its parts.

I barely touched any of this. My one nod to the themes I was going for is the night/day transition on the zig-zag at the beginning and the end; as you’re going down the zig-zag the first time, you’re supposed to learn that, on the upcoming fork, you’re picking day or night. And while you’ll learn that you’re stuck with that choice no matter what direction you take on subsequent forks, at the end, you get a chance to pick again with your new companion and that’s supposed to be kind of rewarding.

In terms of communicating something to the player purely through the physical shape of the level, I’m actually pretty proud of this, if only as a first step. It needs many more more mechanical, visual and aural supports — a sun & moon, changing music, scenery, obstacles, etc. to work properly.

visuals &  music

I’m generally happy with the look of this. The pastel wooden blocks are playful and go with the music; the shattering path effect was a big hit with everyone else at the jam.

I also finally managed to implement a simple version of the crossfading & random music structure I wanted for my Jennifer Ann contest submission years ago. Normally the music has this wood-block sound, but when you get close to a potential companion, some chimes fade in. The music is structured in such a way that when the wood blocks are playing whole notes, the chimes are playing faster notes, and vice versa. So the companion, musically, completes you. 🙂

mechanics

I’ve only done two game jams and the one Jennifer Ann contest, but I noticed something after this jam was over: when thinking of ideas after learning of the themes, I tend not to start with existing game genres at all. Like, I don’t think about how the theme could be applied to a platformer or an RTS or an arena shooter. I think about the theme, and think about what you can do with a game engine and a keyboard and a mouse that fits the theme.

I try to reinvent mechanics from whole cloth.

While this may lead to more original ideas, this sort of thing takes a lot of time and is not necessarily appropriate for a jam. There are things in platformers and shooters that are just known to work, and perhaps more importantly, known to be fun. So even if your story doesn’t work and your approach to theme doesn’t work, well, you could still have a workable game if you start with an existing genre.

Further more, people can just look at something and know how to play it if it fits into established genres. This whole building-a-path-to-your-companion thing I was trying for just wasn’t terribly obvious or communicated very well.

I may have to try starting with a standard genre next time.

Or not. Maybe I just like high-risk experimental stuff.

technical stuff

From a technical point of view, this went extraordinarily well. I barely had to look at the Unity documentation, and only referred to code I’d written for other projects once, for a shader that didn’t even make it into the final product.

There were only two technical hurdles really.

First, I didn’t know how to get your companion to wander down a different path from you once they followed you to a fork.

The second issue was state management. There’s this whole sequence of things you have to do, to win:

1. Create a solid path to your companion.
2. Get close enough to a companion to get them to start following you.
3. Keep the companion from falling while they follow you.
4. Cross a fork while you have a companion.

And basically, the game had no centralized idea where you were in the process. If a companion started following you, new companions would still appear on new paths. If your companion fell, the game wouldn’t know something bad had happened. There was all this stuff going on, but none of it meant anything to the game. Which made it really hard to debug.

summing up

Generally, I consider the game, as a game, a failure; it’s just not clear enough what’s going on and the story just isn’t communicated to the player, at all.

However, as with most of these things, I learned a lot, had fun, and and glad I did it.

Looking forward to the next jam.

Been really out of it lately, hence the lack of posts. Not much in the way of pet projects of deep thoughts to post about.

However, I’m attending another one of those Game Jam things this weekend, and I’m hoping that will sort of jolt me back into normalcy. (That, or I’ll just get even more loopy because Marie is on vacation, I’ll be around a lot of people I don’t know too well, and I’ll descend into one of those forgetting-who-I-am episodes. We’ll see… )

For those of you who don’t know, a Game Jam is where you’re given a specific theme to work on, and have a couple days to crank out a game that fits the theme.

The jam doesn’t start for a few hours, so here are some disconnected tips for myself going into this. It isn’t so much unlike the mental prep work I used to do before TypeCons, I suppose.

Keep my other pet projects at a trickle during the jam.

I fully intend to use some of the weekend doing non-game jam coding and illustration and design and whatnot. Besides my already burning desire to get this stuff moving again, it wil probably help whatever I’m doing for the jam, to take frequent breaks.

Speaking of which:

Pick an approach to the theme that will help me sort out issues with my existing stuff.

If I find myself writing something at the jam that’s about cool mechanics for their own sake or has too-realistic physics simulations, I’m doing something wrong. Ideally, I’ll be able to pick an approach that has a little bit of story, a little bit of that commenting-on-the-the-real-world-through-the-lens-of-abstract-mechanics I want in my other stuff.

Check in with other jammers.

I could easily just hole up and work on my own stuff, and I want to make sure I don’t do that. Unlike my last game jam, I won’t be part of a team, but this is still, in many ways, a social event after all.

Sleep.

Not something I normally have trouble with. 😉 But if I do hit a point where I’m so super excited about what I’m working on that I feel the need to stay up late working, I have to remember that I wrote this: staying up late never, ever helps in the long run.

Alternate skill sets.

I’d like to try forcing myself to stick to a rigid rotation of coding, playtesting, illustration, and music composition — say, a half hour each session — throughout the weekend and see how that goes. My gut feeling is that if I can do that, it will help greatly with my productivity.