Tuesday, June 30, 2009

Good Behaviour

Yesterday I had a few hours and started ironing the AI system. So I fixed an enemy range issue, so now the enemy will run up to a place where it can actually hit you, as opposed to acting all myopic and swinging wildly while just out of range. I also got most of the regular stupidity worked out. So it doesn't just stare at you when it forgets what it was doing and now it doesn't fall off of steps, forever. The problem both seemed to stem from the same basic issue - the backing up function and variables wasn't being passed correctly and made the system forget what was happening. So that's better now.

-What is this "Passed" nonsense? In code, most of it is made up of Variables and Functions. Individually, functions are made up of instructions and variables and you can send them. Say, the player placement variable for example. It is used by lots of different functions, like the jumping, running and falling functions. All of those will modify the player placement variable when they run, then the player placement variable is picked up by the next functions. This is called 'Passing the Variable.'
If the code isn't built correctly, the functions that are supposed to do something to that variable may not run. For example, if the Falling Function is told to only run if the player has 1000 hit points, it will never run, because the engine cannot give 1000 hit points. So, any variables that the Falling Function is supposed to alter won't be. They will not be passed.
You can actually pass a function too, but the means are a little different. When you look at lots of code, it easier to break it into smaller pieces. The AI system is like that. The problem that I was having was the Back Up Function and how it wasn't being passed correctly between chunks of the code. Basically, if an Enemy is close the AI for being close is run and it then tells the system to run a big chunk of AI code. When it decides to Back Up it ran the Back Up Function listed in the being close code. However, when the enemy backed up far enough to no longer be considered close, the chunk of AI code for being far away didn't know what to do with the variables it had because there was no code to deal with the Backing Up ability. In other words, the Function wasn't passed correctly.

- Also halfway into the new wall hop ability. Yesterday I got the Jump divided into 2 different types, a straight jump and a running jump. The straight jump has slightly more height (maybe 3-4 pixels worth) and less lateral mobility. The running jump is the same as it's ever been. The next bit is the wall hop itself and for that, I need to check collision and I don't want to. I can either modify the current code and get it to return a variable or I can do a different check like I do for enemies. Either way, I need to figure out if there is a wall directly in front of the player at a certain part of the jump and do something. I'm thinking that moding the original code may be easier and certainly smoother. As I think about it, I can probably add something like:

If Jump = 2 And xJump = 10
Jump = 3 (the wall hop)

I think I didn't think of that before because I wrote the rest of the code after midnight. Hmm, my work day seems easier now.

-In gameplay news (hooray!) after playing it a little, I've noticed that the combat is a little hard. Actually, quite hard. Enemies are fast, furious and slightly spastic. To help myself test the collision I built a little thing that tells me what button to press and I find myself staring at it when I play. Having built a similar system before, I know that the colors will serve the same purpose, but it really helps. After doing it enough times I can block and dodge like a pro because I have the patterns memorized. That also helps.
So yes, it's a little tricky but I'm not worried yet. My test basically has the difficulty cranked way up. Every attack string has the full compliment of 4 attacks and each string requires all 3 kinds of blocks. No enemy in the game (even the last boss) will be that crazy to fight. So if I can beat it consistently on the highest settings without getting ruined, then I feel good that regular people that didn't design the bloody thing could do the same on the regular settings.
It reminds me of something I read once. It was a design rule and said, "Your Game Is Too Hard." No matter what you do, your game is too hard by default. Since the designers and level people and AI people play the game every day, they are Master's of their Universe. The One of their particular Matrix. So they tend to always think the game is too easy. It isn't. To wit, when Bungie was making one of their Marathon games (it's like pre-Halo) they told the designers and testers to only play on the hardest settings and then only play with the melee weapons. If they could still beat it, the difficulty was right.

Monday, June 29, 2009

Bad Behaviour

The Behaviours are done, and now colored in over there. => They don't all work quite the way that I want them to, but they do work. It tends to get hung up just a little doing certain things, but nothing that can't be fixed. So I'll get to playtesting it now and harass The ADA for some animations. Now that the thing is all done I can give a finished list of needed assets. Then it's just a plug and play. Granted, this wouldn't work for most development but this way prevents me from having to throw away perfectly good animations. Generally, if the art gets done and it's on the list, it's in. With animations in I'll get a compiled .exe over to The Tester so he can stress test it.
I'm just glad that the pieces work again and, more importantly, work correctly. Now if they would play nice together, that'd be prime.

- The Block Stun is in there too now. So if you block correctly, you're control is locked out for a moment. It makes the combat easier since you don't have to hold the button the whole time. It'll also look cool later.

- Counter would be the next thing to do, but I may cut that depending on how the thing plays, especially after I speed up the combat movement. So I'll hold on that and get to the Wall Hop next. I'm of two minds on the subject. One part says to have more of a wall run kind of move, where The Thief scrambles up for a period of time. The other says to actually have a hop, so at the top of a Jump the character jumps again upwardly. The difference is in gaps. The first will not work if there is a gap close to the ground. The second will work no matter what, provided that there is a wall at the correct place in the jump.
The Wall Run is a little more flexible though, since I would make it so that the player can cancel out and jump off the wall during it.
I'm left going back to the original reason for wanting it, which is to prevent people from using a Double Jump before they need it. A canned system would work better then. So the Hop it is.

-In something random, the Background Artist has been doing some Punch-Out style drawings and I think they're kind of cool. This, however, will haunt my dreams.

Thursday, June 25, 2009

Flawless Victory

Done. Look at all that orange over there =>. Great development day yesterday, the brain was working in some kind of hyper mode fueled by something magical perhaps. The blocks all work and the throws work now too. It turns out that the problem I was having with the throw animations was the bloody hotkey. You see, the throw references the kind of attack it is to decide how many frames to play and whatnot. Without an attack, it pulls down a zero, and then proceeds to work correctly, play for exactly zero frames and reset. So, now it works and the counter system almost works.
When I went to bed around midnight I was trying to figure it out. I can create a throw situation, which is what the counter AI requires, but without an attack to reference then it will just fail, like the hotkey approach. So, I commented up the throw function so it'll do something a little different on a counter. If the enemy's state is one of the blocks, the code will reference a specific attack instead of the one fed into it. It sounds a little convoluted, but basically, instead of feeding the function a healthy breakfast of variable numbers, I going to serve up a big bowl of constants and juice. It should work, and we'll find out.
Next up should be the AI balancing and making it work with different enemy types, but I'm willing to wait on that until after I have animations. The basic actions are all there, how they interact together (like in the Doc) or doing more specific things in certain places is something I can do later. What is needed sooner rather than later is the Wall Hop ability. Since its inclusion will make a specific change in the way the levels are going to work.
Either way, I need to finish the programming stuff quickly so I can get back into level construction. The clock, as always, is ticking.

- In something totally random I've been writing about code not working and violence and the Google Gods have gifted me with an advert about Windows Mobile, proving that they at least have a sense of irony.

Wednesday, June 24, 2009

Stop Trying to Hit Me and Hit Me

The collision system is done, again. I think it is anyway. It doesn't have the new Blue Dodge working yet, but that shouldn't take long considering. Now The Thief's blocks are all contained within a unified system. Previously there were 3 different variables that controlled it. Well, actually different variables control all the character's actions, which is kind of dumb. Doubly so when I see how well the single variable controlled AI works. Anyway, the block is now a single variable with different settings ranging from 0 for not blocking all the way to 3.
This also has a cute way of simplifying the code quite a bit. Now I can see if the current attack doesn't equal the current block since the numbers match. Nothing really convoluted about it and it works like a charm. Well, it would, if charms worked. Heck, I would love to be the proud owner of a charm that worked half as well as the blocking code does.
Next up for that is the block stun, but I'm coming back to that once the throws are done and the system is unified.
I also got the left facing attacks to work too using the little al-jabr codelet from before. I built a new thing, remembered that I had already built something way better and used it. It's in one of the other posts.

Now the throw controller is dancing and whatnot with inputs, but it doesn't work. I even went so far as to create a hotkey specifically to cause a throw to happen, and nada. I'm not quite sure why since the system is super simple. Just stop drawing the characters, draw the pictures and animations (or frame counter at this point) and then stop later. The ease that it's supposed to have coupled with the problems that it does have makes me want to huck a milkshake at it. I won't since it's a new laptop, so I'll have to find something else to toss.
I'm wondering if the issue is my array isn't being referenced correctly. I'll break it to fix it later.

- While I was ankle deep in the code I thought briefly about having the system auto-block the high attacks. Then you'd only worry about lows and landing your attacks correctly. Now, as I consider it, I think it may be a good idea for the easy setting. So I'll skip it for now and get to it when I get to the difficulty settings. Since they're just damage and continue changes, I can add this later. I think Easy would have you deal double damage, autoblock and take 75% or so of the regular hits.

Tuesday, June 23, 2009

I Want You To Hit Me As Hard as You Can

Good development day yesterday. I finally got the fall down system to work again in the new linear code base, which is nice. It first was doing something stupid with the floor controller, which was dumb. When I got rid of that it made the walls Jell-o. I mean, I would hit an enemy into walls and instead of bouncing like good little physics objects they would slow down inside the walls, like the walls were made of delicious fruit flavoured gelatin. It turned out that the same controller that caused the knockback to fall down was reinforcing the wall code. So after some quick tweaking it works again, more or less.
S0 now, the AI system is working with the pieces playing nicely together. Still does some odd crap from time to time, but otherwise I'm okay with it. It works well enough to build on. So I did.
After some doing I've gotten the combat collision to work again. It's not perfect yet, and still needs the Blue dodge but it does work nonetheless. So I hopped up and picked a fight with the enemy I'd set and said, well, nothing, but in my head I said the title. It then ran up and beat the high hell from me. It's nice in a weird sadomasochist kind of way, but enemies can do something again, they can bring the pain.
Further, they bring the pain at all hours and all frames. Previously, the attack frames only ever went off at a very specific time for every attack, no matter what. Now I control when that is on a per attack basis. The combat is looser already. I can back hop to dodge an attack and the AI can keep up. I'm very happy with it.

-In not news, I'm in the middle of Mirror's Edge. I don't care, the cartoons are cool and no, they don't look like an eSurance commercial. Get over it. In spite of the fact that I'm trying to play the game a very specific way (running, like Lola, not shooting like in every other FPS) I'm enjoying myself, mostly. Basically, when the game works, it works. When I get to run, the game is working on every level. When it's not, it's a little painful. I mean, when I get killed the 12th time by some corporate RoboCop-esque private police I want to throw things really hard. So basically, it hasn't given me a reason to hate it to death, and the nuggets of candy are enough to keep me going for now.
What it does do really well is the flow. I work like a maniac to make sure the game has flow, that it is seamless. Edge was it in spades. Oddly, it's kind of like its own internal feedback system - if it doesn't feel right, you're probably not doing it right. It comes across as very easy, but it's actually really hard to make it look easy.
Right, what I do like is the fact that, so far I can get through the game without killing/maiming/breaking anybody. It's refreshing in a way. Although, I will admit to a short period of fury. I grabbed a shotgun from a guard, murdered him and all of his buddies before that internal feedback thing kicked in. Holding a shotty just didn't seem correct in the context at work here. So, off a building I went, up the load screen came and then I did it again leaving nothing but footprints. It was cool.

...I don't feel pain, won't you hit me again? I like a bit of black and blue to be in the rotation...

Thursday, June 18, 2009

Fall Together

I wonder how long I can keep up the falling puns for the titles. In any event, yesterday the pieces started falling into place (HA! again!) and the system, as a whole started to work together. It doesn't quite work like it should yet => but it does work. The primordial state of it is good, the shapes are still rough hewn, but the shape is at least correct. It's still buggy a little, but it's stable and it's now written in a way I can figure out the last little pieces and polish this damn thing.
So, close up fighting works, long fighting works, pathfinding works, getting hurt works (take that!) and the knockback code almost works. It knocks enemies into the air, to the top of their arc to be specific, and then forgets about them. That's not quite right. But, I can fix that. Shouldn't take long.
Regardless, the next things, the last things really, the counter and the throw shouldn't actually take long. Basically, the Throw system is a canned animation. It would run on a loop, like the attack strings but without all the parts that are confusing. When I say that it'll be a loop I mean it. Basically, "Play this animation, it is X long. When you get to X, stop."
Counter also shouldn't take long, just a quick mod to the Block code because enemies with either block or counter, but never the same kind of both. So, a high block or a high counter and a low block or a low counter. Easy like Sunday morning. Then if there is a hit of the right kind, go ahead and do a thrown animation. At least, that's how it should work.
Oh right, combat collisions, almost forgot. Ah, no, I already have that.
So now, at least for this, I'm seeing the end. I'm so looking forward to working on something else.

-In the continuing story of The Tester he went off for his interview, filled out a few dozen pages of paperwork and had a 5 minute interview. They also gave him a sticker so he could wander around the secure areas. They say they'll call him back. I wonder if that's good. Either way, they took his sticker. Bastards.

Wednesday, June 17, 2009

Trading Places

After 2 hours, it's done, and it works. By "It" I mean the back up code. Other, different things are broken now. Enemies feel the touch of pain, but do not flinch. They also decide to get into a staring contest with you if they happen to do the now working backing up behaviour. They can, and will stare at you for hours. I'd like to think that they're plotting some kind of mysterious plan, some scheme for world domination. They're not though. In fact, they're standing there because some variable wasn't passed correctly and the required triggers aren't being, well, triggered.
But I'm okay with that. The AI code is now restructured and is now understandable by the proud owners of brains. Me for example. Once I got the code restructured, I did almost the same tests I tried previously, but now, I got a result.
The problem was the Range Finder. Basically, it's code that figures out how far away enemies are from The Thief. It's modifiable for different kinds of enemies and pretty sweet. Issue is, it's a basic AI function like the physics model so it runs every cycle. So, when the back up thing was summoned it then ran the Range Finder. When the RF found that there are no attacks going on, it assumed that it needed to change the state of the enemy. That's why enemies would back up for a 1/30th of a second.
So, in the end, it turns out the problem wasn't systemic. But without rearranging the code to be readable (by real humans even!) I probably would have not found it. So, now, finally, I can fix the last little pieces, regression test the bastards and get my bloody throw and counter system installed. I'm trying to organize a meeting this weekend, so I really want to have something new and cool to show everybody. It would be extra cool if it fuggin worked.

Tuesday, June 16, 2009

Turning It Up To 11

That's my problem - 11. The number after 10 but right before 12. The number that appears rarely on guitar amps. The number, that controls whether or not enemies will back away. 11, is the problem.
Yesterday I spent most of my night trying to figure out the why of it. Basically, it goes like this:

"I'm standing around, and I'm not doing anything. I think I'll back up, and nope, fooled you. For real this time, I'm still not doing anything and now I'll...got you again. Hur hur hur. Standing, Standing, wait for it...Standing! Silly you."

This will continue until you exit the program or the universe is taken by heat death, whichever comes first. Since the regular randomizer didn't seem to give me the result attached to the number 11, ever, I told it to make every outcome 11. To, turn it up. In cheeky response it did, well, the thing right above there. I then proceeded to install a wide variety of tests, and notes so the code would tell me something, anything really, that would let me divine the core problem. I'm sorry to say that after 1-1/2 hours, I still don't know.

Further, the whole problem is exacerbated by the fact that my code in this area, is jumbled. It's said that the city of Venice is built on top of the old city and that one was built on top of the older city and so on, until eventually you get down into mud full of Roman junk. My AI code is like that. As I went, each piece works by itself and is stacked on top of the last piece, all the way down.
Oh, and the syntax sucks. It's like it was written by a retarded baboon that typed in the code using only his big, blue ass. Commands nested in commands, that only work when the moon is right and the game is being played by the eigth son of an eigth son of and eigth son.
So, since I can't seem to figure out the root cause in a normal way, I must conclude that the problem is systemic. Today I'm rewriting and, more importantly, re-ordering the AI code, so that it will fall in line better with how the damn thing is supposed to work. Something like this:

If eState = 7
Do Stuff

If eState = 8
If EnemyAttack > 0 and EnemyAttack < 7
Attack things

If EnemyAttack > 6 and EnemyAttack < 9
Block Things

If EnemyAttack = 11
Back the hell up


Then, maybe, it'll work. I can't see what can possibly go wrong.

-In something else, I had another discussion about the games as art thing. I've made my position clear on several occasions (they're not) but I was thinking, "Other than logic and what I think a game is, is there a specific reason that I think that way?" The conclusion that I came to was that I need to.
I'll explain. Basically, I argue that any (good) game can be reduced in some way to its most basic parts. When I do that I find that everything is expendable except the mechanics. Hence, a game is defined by the mechanics, defined by the rules of play. As I've said before, rules are not art. The reason that I feel that way, is because the mechanics are what I deal in. As a Designer, the mechanics are everything. The game can have anything on top of it provided that they either serve the mechanics in some way or do not hinder them. The mechanics are the meat. Everything else is sauce.
Granted, some people play games for the sauce. I don't have a problem with that. But my games are not designed to hold sauce, and they never will be.

Sunday, June 14, 2009


I'm getting ready to jump right into modifying my blocking code (and adjusting all the numbers to ignore the previous space where they were) when I discovered that my code is infested. I mean, I hadn't gone through and regression tested the whole thing yet. So when I built a new bit, I tested the new bit to make sure that it worked. AI, it turns out, is a funny thing. It's terribly susceptible to the vagaries of numbers and logic. Environments don't seem to care so much, since they're working with constants. AI is like trying to juggle pudding. Hot pudding.
To boot, somehow I managed to break the attack animations. They just don't play. The first frame played, and then it decided that it didn't want to play. Further, the only way to get it out of that was to hit it. Turned out the falling code I added broke it by making the animation frame 1 by default. Now it doesn't do that anymore.
I also managed to break the move back code that I spent so much time working on. I find it's okay because I know the specific logic of that code works. The rest of the engine just isn't giving it the right kind of input. I just need to correct that.
Finally, the blocking code is broken now too. Sort of. It flickers. I turned on the debug stuff (invaluable by the way) and found that it would cycle from En Guarde to Blocking every other frame and I don't know why. Yet.

-...and there we go. But it still flickers. Debug tells me it's for the backing up behaviour now. I think the root cause stems from the fact that my AI functions aren't consistent. Some, count up, while others count down. At the time counting up was for things with animations. Counting down was for a timer. Now, I see that it doesn't work. I can't end out a behaviour and feed a specific kind of input to the next behaviour. I need to make them consistent to continue, so I'll do that now.

-...Erk. Behaviours that count down have the ability to be set as variable and/or random, like the block functions. I could randomize them every cycle but that doesn't give me the fine level of control needed. In fact, looking at them it seems that most of them actually count down. So, I have an idea. If an animation is required (and it probably will be, or a really short cyclical animation) I'll figure something out to make it display consistently. Until then, I'm thinking that down is the way I want to go for all of them except the combat functions. Grrr.

-I seem to have arrived at a solution, based on a retarded thing that I did, which is unusual. Basically, the system is running into a problem with the En Guarde behaviour and it's position as the 0 behaviour. I had set up 0 to be the "Okay, great, now do something else" variable. However, when I made En Guarde be that number, it ran into a number of problems, like the flickering and working like ass. So I went ahead and made the En Guarde behaviour the gatekeeper behaviour. So when the system finishes doing something, it goes back to the En Guarde behaviour, just like the Doc says for it to. =>
So the flicker is gone. The AI seems to be behaving now, but now my backup function is gone. I'm trying to figure it out still. It's 11 in the PM, so I'll do that tomorrow.

-In totally random crap, all the times I've used the words AI, Game and Behaviour has broken Google's positronic brain. Clicking through has given me, in no particular order, "Get a Game Degree," "Get over your addiction," and my favorite, "Dog training available." That has nothing to do with anything. Go ahead, scroll down and click it a few times. I'll still be here when you get back.

EDIT: As I checked my list again, I realized that I've already built the animation controller for the throw. It's untested, but built. So, I orangified it.

Wednesday, June 10, 2009

The Law

No game stuff today (although I did work out from a design standpoint what characters counter and which have throws, what kind and how many). Instead, I offer general advice. Having worked at a few different places and with a few different people I've come up with the rules listed below. Sometimes, these rules weren't given by good example, but by bad.

Being in a position where I lead a team, I sometimes read over these to remind myself to not be a dick. When it comes to finding people to work with, my only suggestion is to find competent people and let them be competent. For everything else, here, in no particular order, is The Law.

Everything cannot be first.

The way to fortune and glory is to create something new. One cannot just repackage and be successful.

Always remember why you did or are doing something.

Don't be a Defeatist, and don't try to pass it off as "Realism."

Plan for things you know to be true, not what you assume will happen...and don't be a pessimist.

Be flexible, and create flexible systems.

Do not look for problems. It is okay for everything to be okay. Know when to say "Good Enough" and find something else to do with your time.

Nothing is more valuable than imagination and nothing is more costly than a lack of it.

Anything worth having is worth thinking about.

It is silly to believe that anyone can tell you what you do not know or what you have forgotten.

Never be afraid of having exactly what you want. Do not be afraid of what it takes to achieve it.

There is no need to remind somebody of something they are already doing.

Everybody's time is equally important.

It is vital to know what your employees do, specifically.

Never, Ever belittle or mock the work of your employees. Otherwise they will no longer want to be your employees.

Be honest with your employees since it is not their job to remember your lies.

Nobody ever has to do anything. There are things that should be done though.

Hire people that can tell you "no." Make sure they can also tell you why not, and offer a solution.

Your assumptions are yours alone. Do not blame anyone else for something you assumed was a certain way.

Don't be afraid to abandon an idea.

3 minutes of good design, saves 3 hours of labour.

It is okay to admit to being wrong. The next, more important, step is fixing it.

Saying something does not make it true. Repeating it does not make it any more true.

Do not fear change. Instead, embrace it if it is a better way.

Progress for its own sake is worthless. Progress towards a goal is priceless.

One is never an exception to their own rules.

As you can see, some of them are things I may have already ranted about. Others do sound a little like fortune cookies, but are no less useful. Like, "Anything worth having is worth thinking about." That sounds a little like something Confucian, but in basic terms if you think that you would like something, actually spend the minutes figuring it out. Jumping to conclusions only ever leads to missed opportunities, and in our case here, wasted work.
In any event, disagree if you'd like, but this is how I do things, or at least, try to.

Tuesday, June 9, 2009

False Opportunity

Today I'm smarting from what may be considered a failure in some circles. Not so in others. I'll start at the beginning.
I came across a job doing some in house testing work for a local game studio. It's one of the larger ones, so I'll spare the details here. In any event, I called to get some more information about it. Turns out it's a contract job with a slight possibility of being hired on and/or promoted at some point in the future. Further, it doesn't pay terribly well. Compared to other jobs it does, but compared to the ones that I need to, you know, live it really didn't stack up.
So what? Why does this random crap get a post? The point is, I really wanted this to work. I spent all last night trying to figure out how, and today I see it's not something that is feasible. But, I was hopeful. It never occurred to me (some would say to my detriment) that I wouldn't get the job had I applied. It seemed that in this case, if I could get it to work, if I could figure it out, then I could change my circumstance. But alas, not today. Not today. I do have dozens of floating resumes though. Maybe tomorrow. Or this afternoon.
That's not quite the end of the story though, and I may update this later based on what happens. I sent over all the information to our resident Tester (who's full name / superhero identity, the credits would tell you, is Kevin O'Neil) and offered to give a reference. Just because it's not a perfect fit for me doesn't mean that it wouldn't be good for him. I hope it goes well.

Sunday, June 7, 2009

Plop / Superman

Falling is in now, with Physics! Installed it, got it working and fired it up. When I loaded the Jump Program, whipped out the sword, smacked around the Knight and dropped him off like he was hot. The new Physics(!) kicked in, grabbed the enemy in it's iron Mathemagical grip and he fell to the ground and, it killed him.
I know the term "LOL" has been played out at this point, but I actually did. Right out loud even. Granted, falling down and suffering from what appears to be severe injury is hardly something that would create mirth, but it did in this case. But, since the doing damage function has been removed for testing reasons, it feels good to give some hell to the pixel minions of the game.
All in all, the system works. So that's cool. The player can ambush enemies, knock them off or into unfortunate things and the player can quickly get back to all the running and/or jumping.

-From a gameplay perspective the blocking system works in a way, but it's not hard. I'm thinking I'll install a system that auto-blocks player attacks based on the enemy type. To this end, the Block Stun when the player gets blocked correctly...and no. I won't. Half of the "blocks" in the game are counters, and that would be cheap like an SNK game. No, I'll think of something different.

-Finally, the title. Plop is pretty, um, onomonopeic. The second has to do with something similar. The Thief is pretty fragile. He can't fall too far without suffering damage or, let's say, death. 3 stories or so is the upper limit of what his little British bones can handle. It's also probably the upper limit of what a Traceur could deal with. Compared to enemies, The Thief is Kal-El. They drop 12 feet, and that's the end of them. 6 feet and they feel all hurt. It's one of the advantages the player has.

-Next up is the Throw Controller. I need to build a table with 151 frames in a a row and 6 rows. It shouldn't take long so...done. Now let's build a functions that draws that when a throw would happen. There we go. It's all ready to go. I also got a bit in there so at the end, the character is in the Thrown state. So the animations should blend together and look really stunning. What I'll do is change the final position of the character at the end of the animation, so they'll have a similar thing happen at the end, but it'll start at a different place and appear really organic. It's like in my 3DS Max class, you don't always have to do it correctly, it just has to look right. Generally in these kinds of things, you can fake it.

-Yeah, I said it. The Thief's British. When he speaks I think he should sound like this guy.

Friday, June 5, 2009

Gentle Landing

Huzzah. That's one. Finished, all done, colored in on The List over there =>

The knock down code works, and it's nice and solid, I even have frame counts, so I'll add those to The List too...and...done. It's Orange! That let's you know that it's done.

So yesterday I went in and added parts for the enemies to hit walls and fall where they were supposed to and not fall when they weren't. As I got started I found that enemies would get to the end of their arcs and just stop, stunned like they had just hit the ground. Of course, since there was no ground there, it looked and played a little strange. So a quick tweak later and thy would only get stunned when they hit the ground as part of the arc or at the very end. Otherwise they Fall. This means that the Falling Function for the enemies needs to end at 10, but without the invincibility triggered. I'll get the falling function finished today and the invincibility bit.
Anyhow, after the correct things happened after the arc, I went ahead and added the bounce code, so enemies would rebound off of walls if hit into them. I find this to be actually quite cool. You can knock them off of things, into walls and on one occasion I managed to hit the enemy so that they fell, hit a wall, bounced, hit another wall and then fall down.
Right then, the Failing code should work exactly how the Falling code works for The Thief. That way, the physics modeling in the game is consistent. Plus, I also have the al-jabr (It's Arabic, look it up) all done for that.

-With that done, the counter system is up next, but that requires the animation tables for throws built. Having thought about it a little, I need a table with 6 rows and each with 151 cells (150 animation cells and 1 cell for the total number of frames). That 3 kinds of throw animations both to the left and right. Of course, the only enemy with 3 kinds of throws will probably be The General, but he's designed to be a brutal pain in the ass. In any event, the table doesn't need all the extra information present in the Attack tables, since it is really just a table for animations, albeit a very big one.
Information about how a throw will deal damage will be on a part by part basis. They aren't common enough to devote a huge amount of time to. So things like this will be frequent in the function:

If EnemySkill = 8 ;The General
If ThrowType = 3
If EnemyAttackFrame = 5
HP = HP - 5

I was also having an idea on triggering these things. First, a Counter will go right into the animation, without a starting attack. So if the counter is good, then immediately trigger the throw. No stunned Thief, no chance of dodging. That'll happen a few times with a Fencer enemy (an enemy that has no Block, only counters) and players will pay a lot more attention. Since a Counter has 2 flavours, that will correspond to individual kinds of Throws.
A similar thing will control regular Throw type attacks. For those, when the attack hits that has those properties, then the throw will also trigger. The kind (ThrowType) will correspond to the kind of attack hit. Generally speaking it'll be either a High or Low attack, but on at least one occasion a blue attack. I think that'll work and since it uses code already, um, coded it should be a pretty quick thing to install. Of course the big issue is getting animations that are 150 frames (5 seconds) long.

Thursday, June 4, 2009

Golden Arches

Dammit, the knock the enemies down code finally works. I found that it wasn't the falling function per se, it was all the rest of the bloody things. Basically, if you make an enemy airborne all the cute little things that the AI controls, like turning around at walls and the ends of platforms will trigger. So, it'll think to itself,

"Duh, there is no platform in front of me *drool*. I should walk the other way. What was I doing again?"

The problem is that, when it turns around, it changes the state of the enemy, which then triggered the regular falling down code. In other words, it would knock the little buggers a few feet into the air, and then, like David Bowie, they would fall to Earth. So I went ahead and made the system only do all of that if the enemy wasn't in the process of flying through the air with the greatest of ease. So now, when you hit an enemy 3 times they get knocked back, pop up and arc gracefully through the air until coming to rest on the ground again. I'm going to need to go in and make a few changes to the code so they bounce appropriately. I'm thinking that, since enemies don't have a wall clinging state like The Thief, they will simply change direction if they hit a wall while airborne.

Speaking of The Thief, once the Throw system is installed, I'm thinking that I'll make a small tweak to his Wall Hanging code, so when he is thrown into a wall, he'll stick for a moment before falling off into the Doomed state. OR I'll make him do the same thing that the enemies do for consistency. It should be pretty easy to install, but there's a lot of other things that need doing first.

Anyhow, I was thinking recently, looking back on the project and the List, that this time I may have bitten off more than I can easily chew. But I don't think that's such a bad thing. If you only ever do what you know you can do, then you'll never do anything.
In other words, I'm of the mind that for everything you do, pick something that you think is just beyond your abilities, so they have room to grow. I mean, I've been working for a year and a half at this point and that List => still needs doing. But you know, now I know I can do this. I didn't when I started, because I thought this whole thing was just past what I could do. Actually, it turned out to be far more than what I thought I could do, but I've managed anyway. I'm glad I was stupid in my ambitions. The next thing, I have almost no idea how I'm even going to try doing that, so that's status quo really here at Star Frog.

-Speaking of which, Star Frog Games (or the Star Frog Project - depending on who asks and what my mood happens to be) as a name was originally a nonsense word set that I could find on the Google machine. Then I got to thinking about it, especially in the context of the previous paragraph. I mean, you don't send frogs into space. They have no real way of getting there themselves, it's outside of what it possible. Yet, the logo, such as it is, shows a frog wearing a space helmet. In other words, doing the impossible - just like us. Of course, I've arrived at this far after naming the group, but now I can't think of a better name.

Tuesday, June 2, 2009

Falling Down

I'm working over the AI states, installing the final Fall Down code and getting the Combo system to work on some level. So, 3 hits and the enemies fall down. It'll be a bigger deal with bosses, but what can you do? As I'm doing it, it seems that the Combo addition goes twice per hit. I think it has to do with the Attack Frame variable not updating correctly. I'm thinking that when I put it in the first time 4 frames at 30 FPS was way too fast and so I made it run on twos. I think it's still doing that. I'll make a code notation and make it work for now. I can't fix it until I have the final attack animations anyway.

The Fall Down code is in. It works a little like the PC's Jump Function, in that it has a number that is subtracted from the vertical position and that number is reduced every frame until it is less than zero. In game it creates a very nice arc. At least, it's supposed to. Once the bad guy in airborne, the Falling Function takes over, stopping both the backwards X-Axis Movement and the pretty arc. I think if I modify the Falling Code to assume that the Fall Down state is a kind of platform it should work.

- For those of you at home reading this (yeah right) that don't know that E3 is going on right now, shame on you. Go ahead and click the little link and then come back. There are lots of other places to get news about that, and I've ranted about this previously. I'm totally let down this year. If the best thing that I have to look forward to is a green controller to match my 360, then somebody someplace is doing a terrible job. E3 is the pre-Christmas for gamers everywhere, when we get a sneak peek at all the stuff we're getting for Christmas (or Chanukkah, or Kwanzaa I guess). Like when I was a kid I would rush to the mailbox and pull out that Toy R Us catalog, rush back into my house as if the sunlight would irrevocably damage it and then proceed to circle most of the stuff in it. E3 is supposed to be like that. Except this year I ran out, grabbed the catalog and found it full of socks and crap I already own.
Granted, there are the games, sequels as far as the eye can see (I'm staring at you Nintendo). I get it, sequels are safe, but I'm getting really tired of sequels. I want the new. So, I've got a very short list of things I want (controller included - which ironically comes bundled with a sequel), not the least of which is The Last Guardian. I have no idea what it is about and yet, given the pedigree I want it yesterday.

-Speaking further about E3, I realized that you can go if you have a reason to be there. Generally speaking, the reasons can be pretty lax. I know of at least 1 person that got to go because they draw a web-comic. So, I'm thinking that if it isn't too expensive I may see if anybody on the Team wants to go. We are industry professionals is a way.