Sunday, December 23, 2012

Low Power Mode

I got a job! It is in the industry, but I'm not sure what I can say about it online so the best option is to say nothing. I will be continuing to work on this game with however many cycles I can allocate to it, and I'll try to  post here when I can, but updates will be less frequent for the foreseeable future.

Sunday, December 16, 2012

Have Mercy


Let's see, what did I do this week. Just now changed some code which allows the player to fire weapons in mid-air, exposing some other weird animation issues. The state system for character poses and moves is a little fragile, but I think I can shore up the weak spots, it's just going to take going over the file with a fine toothed comb. Also started placing what I call "Mercy Caps", little invisible two-unit wide box colliders at the edge of platforms. One function of these is that they do give the player a little mercy when wandering close to the edge of a platform, for some reason having the player fall off right at the platform's edge doesn't "feel right", it's harsh and kind of frustrating, that little buffer seems to help. The other thing with these is that platforms are supposed to kill "acoustic wave" projectiles, this is so when the projectile has grown enough it will naturally intersect with the floor or ceiling and disappear, creating a kind of cone of fire in front of the player. I do this by tagging every platform tile as a "wavestopper", searching for that tag on collisions and using it to destroy projectiles. Works great, but if you are standing off to one side of a platform and shoot at it, the platform shouldn't just eat the projectile. By tagging the Mercy Caps as "bouncer", I solve this - the projectile hits the cap, which doesn't register as a wavestopper, and bounces off without touching the platform. Thus platforms will only kill projectiles if hit as a floor or ceiling.

I also see here in my notes that I "solved a problem with physics by ignoring it". I think the gist is, I was reversing "bullets" as they struck scenery objects by using AddForce on the rigidbody, addding an opposite amount of force from what the bullet already had. This resulted in some really off behaviors, things getting stuck, general bad mojo. I eventually stopped mucking about with phsyics, and when the bullet hits an object I just flip its velocity.x. Now it's traveling with the same velocity, under the same force, in the opposite direction! When you set up a simulation system like physics it's easy to forget that you can just reach in there under the hood and perform an Act of Dev if you feel like it. I'll try not to let the power go to my head. In fact I think I wrote something a while ago about why you should never override your own physics simulation like this, I'll have to look that up when I get time...

Much of my time this week was spent watching and taking notes on a multi-hour presentation on Object Oriented Design. This has been really eye-opening to me in terms of the Big Gap between knowing how to write a few lines of code and knowing how to write an application. It walks through several accepted ways to architect software, starting with requirements, use cases, and user stories, moving on through use case diagrams to domain modeling and UML class diagrams. I was surprised (and much relieved) to learn that if this process is done right, by the time you sit down to code you are more or less transcribing your functions and variables from the diagrams you already created, and your mind is free to solve the individual math or data handling problems that will crop up in your individual functions, rather than desperately trying to keep one eye on your code and the other on the big picture.

This is light years away from my current "cowboy style" development methodology, and I am definitely going to approach my next project from this perspective and save myself a lot of hassles. As for my current one, I think I've already hacked in the majority of the objects and features I'm going to want. It was interesting to see some intuitive stuff I arrived at explained to me with some knowledge behind it. For instance, I was originally controlling bullet movement from a script that lived on the "weaponSocketController", the object that instantiates bullets when the trigger is pulled. I realized after having to reach across scripts too many times that the bullet's behavior should live in a "bulletBehavior" script on the bullet itself. Had I watched the design presentation first, I would have learned that it is always best practice for an object to contain the methods and variables required to control its own movement and behviors whenever possible. Well, I know that now.

I have a bunch of other videos lined up that aren't strictly game related, starting with an in-depth C# course, some ASP.NET and MVC stuff, and the ever-popular PhP with MySQL. I don't know how much of this stuff I will realistically be able to absorb and how fast, but that's definitely the path I'm headed down. I will continue to plug away at this project, and of course I have some other ideas I'd like to get to, but I have to spend more time working directly on code. Being able to write a user-facing or i/o or back-end feature, from scratch, within a significant existing codebase ... well, that's where Dice is telling me the jobs are, and not just in games. Code or die is the order of the day. I don't make the rules, I just gotta live by them...



Friday, December 14, 2012

This Level is Too Big mang

Gotta assume this is a standard rookie platformer mistake. No, I'll build up the scaffolding to reach the catwalks in the underground bus tunnel, it's cool, I still have half a dozen props as textures I haven't deployed as 3d objects yet, I Am Dumb About Games.
It's funny because so many of us are designing games visually based on systems like NES, where memory was at a premium. NES would have fired me for this level.


Monday, December 10, 2012

Chipping Away

Nothing dramatic to report for this last week, just grinding away at script tweaks and small art assets, trying to bring the overall picture of a single level of gameplay into focus. A few details:

I finally implemented the player's follow camera, fixing the main camera on an invisible child GameObject of the player called "playerFocus" and located a few dozen pixels over the player's head. Once I could move the player around while keeping them onscreen, I of course had to expand the level, which required a new batch of tiles for the sides of the dirt/sidewalk elevations, and got me excited about expanding the map up and down which will require tiles for fire escapes and the underground bus tunnel ... it's starting to look like the gameplay template here is less Mario and more Ghosts and Goblins; the level will be about half the width of a Mario level but with three distinct vertical regions (ground, air, underground). We'll have a "door" of some kind at the right to leave the level, and some sort of collectible "key pieces" at various places on the map, so you get a few minutes of exploration / scavenger hunt, some combat, maybe a puzzle or two, then it's on to the next level. There are nine levels, each with their own backgrounds, objects and enemies, most of which will be unique but a few will be palette swapped or duplicated from other levels to cut down on overall asset workload (although it is still going to be a heinous amount of work).

I also sketched in the sprite and walk cycle of one of the first Pioneer Square enemies, sort of visible as a blob up there, a skeleton with a leather jacket and green army helmet, wielding a kitchen knife. I needed some generic baddies for this game, I considered robots (may still add some) but I kept coming back to my love for the humble Fighting Skeleton, a classic gaming staple who has fortuitously eluded this decade's rampart overuse of ... certain types of undead. I pictured a classic "lead miniature" type of skeleton, but replacing the traditional buckler and scimitar with accouterments from 70's era gangsploitation schlock like The Warriors. Coming soon, a skeleton with combat boots, a rainbow mohawk and a broken bottle, also a skeleton dog with a spiked collar. that will probably be the next big code bottleneck too (once I get some bugs with the acoustic waves sorted properly): coming up with lunges and stabs and other attack movements for these guys.

The only code funkiness I dealt with this week was a little quirk of C#: while in Javascript it's perfectly fine to manipulate a Vector3 like this:

var cameraPosition : Vector3 = (1,1,1);
cameraPosition.x += 5;


C# will not allow you to change individual components of a complex variable like a Vector3. Instead you have to change the whole thing, formulating it like this:

public Vector3 cameraPosition = (1,1,1);
public float cameraXDelta = 5.0f;
cameraPosition =  new Vector3(cameraPosition.x + cameraXDelta, cameraPosition.y, cameraPosition.z);


I'm not sure why this is the case, but generally the answer to such things is: javaScript is doing it the hard way too, it's just nice enough to hide a lot of the work under the hood. I'm sure one day I'll appreciate the convenience and go back to simpler scripting languages for simpler tasks, but right now I'm all about looking under the hood whenever I can, even if I don't understand half of what's going on down there.




Monday, December 3, 2012

Is This ... The "F" Word?


I've known for a while that this game was to feature players wielding musical instruments who would "shoot out sound waves", but up to now I had precious little idea what that might entail. This weekend I finally got to the place where all my player characters were moving correctly and executing a one-shot attack animation so it was time to start thinking about the projectiles.

That attack animation, as an aside, was a bit hacky, as I was unable to locate a good way to get the length of a RagePixel animation to know when to make it stop. So, I set the attack on a loop and then used a coroutine and yield statement to keep the player in the attack state for a short while after the attack button is pressed, then to snap over into an idle state. So, the attack animation plays on a loop, but the player is only ever in the attack state long enough for the animation to be visible once, which turned out to be around 0.15 seconds, just eyeballing it. This solution is fundamentally goofy and I am not proud of it, but it works.

So, a traveling sound wave... I started with a GameObject and a  Rigidbody component, so I could move the thing by applying a force. I tried scaling the Rigidbody but that appeared to be the wrong idea. I then added a Box Collider and tried scaling that, but the results weren't what I was looking for. Fianlly, I just scaled the GameObject, figuring (correctly) that the attached Box Collider would just come along for the ride. I made the whole thing into a prefab, then wrote code to instantiate a clone of the prefab at the player's "weapon socket", offset along the x and y depending on facing, every time the attack button is pressed.

When I got into the code for destroying these things, I had an idea: if they were meant to be sound waves, what if they could bounce like sound waves? The first time a "bullet" collides with another object, I reverse its' direction and send it back the other way. On the second collision, I destroy it. This means you can fling several of these things out, they will bounce back, hit one another, and cancel out.

It's still very crude, but here, suddenly, is that moment when you try an experiment in your game prototype and something interesting happens. You start to think of various level structures and objects and enemies that could react to bouncing sound waves. You wonder if the player could do this in midair, and what effect that might have. You consider variations on the basic projectile, changes in frequency, force, number of bounces. You start to think you might be looking at a game. Is this ... fun?

Let's not get ahead of ourselves.