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...