It's still in early development. No fancy graphics yet, and sprites were rendered in poser in Preview mode. Please tell me if you see any potential in it!
PS sorry for the awful video cropping and the typos.
PS2 On a more technical note, the characters' weapons and gunflares are separate image layers...much like how weapons and armor are displayed in Eschalon
Hi!
Impressive AI! did you design it yourself or is it a build in feature of gamemaker? In c++/c# this would be quite a few pages of code
I also like the animations and characters. Is it a lot of work designing the models the way you want?
I am interested in character modeling and animating as I'm working on a game project as well At the moment I'm using Cinema 4D for this, but where it works out great for the level graphics, it's a lot of work to get the character animations the way I want.
Use Poser for animating characters. It's slow and buggy and crashes all the time, but you can get the job done.
For the AI: Game Maker has some built-in functions like pathfinding for example. But creating an AI and over 800 frames of animation and making them work together requires some work. Here's what I did:
I wrote a nifty script which automatically imports .csv (comma-separated values) files and stores them in lists. I work in Excel, putting nice colors and tabs and notes and stuff, and then I export my work into .csv's. So what is in those csv's?
Well, there are groups of possible motions and actions. Standing idle, crouching or dashing towards a cover spot is a motion, for example.
Firing a weapon (regardless of your current motion), reloading etc is an action. Each motion/action has a certain "propensity" to happen, depending on many parameters, as well as certain requirements. So for example, let's take the "take cover" motion. In order to take cover, there has to be a free cover spot with no enemies covering at the side you will end up. This is a requirement. If a character's health is low, or they are defensive, or they have zero ammo, it's more likely to take cover than doing anything else. That is the possibility for that respective motion. So the program gathers all candidate motions and actions, and (usually) selects those which are more likely to happen. Now, can characters open fire while running for cover? Hell yes. So firing is an allowed action for this motion. A nifty combination of motion,action,character direction and weapon-target direction give us the required animation, from those 800+ frames we spoke about earlier. There is a table of all animations, declaring which frames will be used, which kinds of motions/actions they represent etc. Also, each motion/action has a piece of code associated with them, which is executed every "step" of the game. So you can easily manipulate what your character does, when and why they will stop doing what they're doing etc.
So it's all about tables with carefully organised data and chunks of code. The actual Game Maker code required to present those stuff to the player is about 10 lines. No endless ifs, no endless nests and loops. Everything lies in those csv's, in their proper place. Game Maker has the ability to execute its programming language on the fly. So if I store a piece of code in an array, I can execute it whenever I want. This is how motion/action requirements are met and how their "step events" are executed.
