[Super Dungeon Smashers][Roguelite][Devlog](pre-alpha)

[Gravedust]

[Super Dungeon Smashers][Roguelite][Devlog](pre-alpha)

So I decided to start a new game project to mess around with GM2, and since I like to talk about what I'm doing when I'm developing, but nobody else I know really understands what the hell I am talking about, I figured I'd devlog it here so my friends and loved ones no longer have to spend as much time nodding and looking confused as I try to explain what the hell it is I'm doing.

The working title for the game for the moment is Super Dungeon Smashers. This is a terrible name but also probably not the final one, so we'll just roll with it for now.

Basically it is a Diablo / Gungeon influenced action rogue-lite. (because what isn't these days?)

The hooks though are:

• No preset classes, you choose abilities from a long list of mix-and-match specializations, and can adjust stats to work with whatever your build is.

• You can have multiple characters in a 'stable', and bring your own characters into dungeons with you as companion NPCs.

-Since this concept can use a bit more explaining: Let's say you play out a character to level 10. Then you exit the dungeon and go back to the Hub, make a new character, and take the level 10 you were just playing with you as you re-enter the dungeon. The L10 will use all the weapons and skills you were using when you played it last. So basically you can run the game solo, or build a 'team' of characters. (Which are all you! Sort of.)
I like playing around with AI a lot, so getting this working seemed like fun.

Anyway, That's the basic concept. I'll probably get more into the specifics later, but at the moment I am still nailing things down.

What I've been working on so far is the basic character controls and how characters are going to be displayed. I like to start on character movement as early as possible since it's the one system the player will always be using, and due to the nature of the game I'll have to try some new things when it comes to drawing the player characters. (And backgrounds. I've never actually done a 3/4 view game before)

Since this is a game with many different characters that I want players to be able to choose unique appearances for, many different items they can wear, and no set classes, we need a character drawing and animation system that can handle a ton of different faces, sprites, weapon types, animations, and so on and so forth.

The game is intended to be silly as hell. Full of weird stuff and general nonsense, as well as huge swords and pretty armor. Thusly for the game's visuals I am planning on using an art style I've been using for a while, very bouncy and cartoony.

ex:

…Except done in pixel-art style, partially because I want to try out GM2's image editor, and also because it's fast to do. >.>

I am not great at pixel art, but I have a little bit of experience, and so here we have Tess, our test player sprite:

As you might immediately guess, she is actually made of a bunch of separate sprites, layered.

And as you might also guess, each sprite in a layer has a 'back' version.

Since the positions stay the same all you need to do is switch from the 'front' sprite in every layer to the 'back' one.
And by setting image_xscale according to which way the character is 'facing' we can make her orient to the left or right.
And of course we can change any of the individual sprite front/back pair to change her face, hair, or what she is wearing.
(Since the eyes and mouths are separate from the face, I can also do facial animation)

So that gives us our 4 directions and changeable gear in a way that looks decent, with a fairly minimal amount of bother. But the result is really static. Since we went to the trouble of cutting our sprite into pieces and drawing each one separately, what other things can we do with that?

Well, we can add a little life by adding some timed X and Y offsets that will bob a few pieces up and down or left and right a pixel or two every so often.

And since we already are bothering to control the offsets directly, we can modify them based on what the character is doing.

We can make them 'lean into' their run cycle. (Or recoil from a hit, when we get to that)

(that's a placeholder run animation, by the way)

Or scrunch down on landing, squash and stretch style.

In both cases I am using offsets and some tweening to control the action of the arms into a fake run cycle. It's not amazing, but I have other ideas for the arms in the future.

There is one thing that simple x/y offsets can't handle though; showing a knocked down or dead character. (or any orientation other than standing, really) The easiest way to do that wound up being to rotate the whole sprite stack.

…Which also lets you do awesome if physically unlikely flips!

Unfortunately, the one thing I probably can't work around with rotation and offsets are the motion of the legs for running. So I am relying on sprite strips for the time being. This is a bummer because it means developing leg sprites will literally take 50x as long as every other part. because of this I am considering using Spine to handle character drawing and anims. But I may just bite the bullet and deal with drawing leg anims in order to keep things simple.

So anyway, that about covers the first few days of development. (or the parts you can see anyway.) Looking forward to having more to show in the near future, I'm pretty excited about the project presently. My first goal is to get an minimum viable product with:

- Multiple floors (Procedural generation not required yet) and a means of reaching the next floor
- At least 1 fightable enemy
- Increasing mob difficulty per floor traversed.
- A fully controllable Character, nameable, with attacks.
- The ability to save and use multiple characters. (not necessarily useable as NPC companions yet tho.)
- A basic equipment system. (1 sword, 1 chest armor, and the ability to swap for items on the ground)
- Items with randomized stats (Dropped from enemies.)

So hopefully I'll have something to fiddle around with soon.

 

[Gravedust]

Quick update!

Have been messing around more with player animation. After some consideration I may be stepping away from pure pixel art with no antialiasing, in favor of something that handles rotation a little better. (Because I am now rotating the character's head to 'look' at the cursor.) The plus side is that the in-game art can now look more or less exactly like the promo art, since it's now produced in exactly the same way. Plus there's now more room to add details to the smaller parts. I am also considering increasing the character size, but I want to see it in-game first.

ANYWAY. Updated sprite art in the newly proposed style:

Smooooooooth...

And a simple sprite for a test enemy:

…Lamentably completed before I decided to maybe not do pixel-style, but it should work fine for now.

Behind the scenes I have been notepadding the basic interactions of the combat system and player/enemy stats, etc.
Looking forward to blowing a few hours this weekend putting things together.

 

[Gravedust]

Progress!

So I've got the test character art and animations to a point I am basically happy with. Animating the legs took as long as I was afraid it would, unfortunately. It's be just fine if I only had 1 character to do but I'd like dozens if not hundreds of armor sets, sooooooo... I am considering going to Spine more strongly now, but I'm not yet sold on it for this project. We'll see how it goes.

But anyway, the bottom line is I now have something that looks decent and works well enough for this stage.

I the background I have been doing more notepadding regarding core systems, some notes about how I'd like combat to work, and have started building up some parent objects.

The first test enemy is in!

…but hit detection is not.

I believe the next step will be to introduce combat basics, work out how I want to do backgrounds, and get started on AI control for player characters. It won't be done for a long time, but it's pretty core and I've been looking forward to getting started on it.

 

[Gravedust]

Whew. Busy few days but I got a few hours to work on SDS.

A lot of stuff had been done, but it's still mostly planning, and transferring functions from my test objects to my new parent objects. So there's nothing really to actually show on that front. Basic weapon interactions are in (dealing damage, basic knockback, etc.) but there's a lot more to work on in that department before I'm really done.

What I can show off though is more animation stuff!

So as I was mentioning before, the character object sprites will be more like a 'stack' of interchangeable sprites layered on top of one another.

Well by giving say, a mouth sprite multiple frames and switching between them in code, we can do things like have a character 'talk':

Since we have both mouth and eyes separate, that means we can do a pretty decent range of facial animation with just a couple of frames.

As well as have reactions to attacking:

Or being hit:

So that's fun. Anyway, just a quickie update before the weekend, still looking forward to reaching my minimum viable product milestone. At this rate it'll be a while, but I'm having fun in the meantime.

 

[Gravedust]

Well, most of the time since the last update was spent moving furniture, but I did make some progress.

Most notable was implementing a persistent inventory system, which was a first for me, coding wise. But you can pick up objects, move them around in the inventory grid, swap positions, drop them again as item pickups, etc, and the contents are saved and preserved between games. Also has support for item stacking, etc. Pleasantly, it is also pretty modular, meaning I can probably cross-purpose it for other games that need an inventory.

BEHOLD:

It still needs some work before it'll really do everything I need it to,(handle multiple separate inventories and passing items between them, saving and redropping complex items like weapons which can have effects and multiple scripts on them. etc.)

But it's a good start.

 

[Gravedust]

Post-weekend update:

All kinds of progress, but most of it was all code so there's not much to actually show. But the Inventory features have been pretty well hammered out; you can now trade and swap items from one character's inventory to another as well as shared 'stashes'.

Dropped items and items in inventory now have proper text labels which are MMO-color-coded by item quality (gray, white, green, blue, etc,)

The next steps will be implementing Stats/Equipment panels to allow for equipping new objects, and then enabling full character saves.

Once those are finished I'll be back in familiar territory coding-wise, so progress toward the minimum viable product features should speed up quite a lot.

Also, I finally had the idea I should have had weeks ago: Using Spine to- [blah blah blah blah blah] -and turn that into a sprite strip. …The point is I can (maybe!) cut out 80% of the time involved in animating run strips by hand, and maybe also have separate boot and leg sprites. Which is great!

One thing I did have time to do last week was do a few more component sprites. Mostly just to have a look at the time involved. I did hair front/back, and a chest front/back in I think 3-4 nonconsecutive hours. (hair takes a lot longer than armor.)

Here are the new pieces alongside the original set. These are shown at 2x current game scale (and 1/2 working scale) They are weird in a few spots because they're rendered to look good at the final scale and not this intermediate one.

I'm a bit bummed that the character size in game isn't large enough to hold all the detail I'd otherwise like to put into gear and faces and all else. Sigh.

 

[Kestril]

I like the clear artistic style you've got going on. I also rather like the way you keep it simple with the attacks in a way that works with the art. I've been experimenting with what stylistic elements to work with my game to very little success. Nevertheless, it's really inspiring to see it done early on from someone else.

I don't have much to give feedback-wise, just wanted to drop by and say keep up the impressive work.

 

[Gravedust]

Hey, thanks.

I probably pay too much attention to visuals too early, honestly. There's nothing wrong with Programmer Squares as art when a project is just starting. …But I'm a graphic designer by trade so I care too much, and getting to do art and animation for my own projects is like getting to eat frosting.

As far as developing your own style, it's mostly just a matter of seat time. You'll eventually gravitate towards something you're happy with, just keep making art and hopefully have fun doing it.

If do you have any questions about technique tho I can try to answer them as best I'm able.

 

[Kestril]

If do you have any questions about technique tho I can try to answer them as best I'm able.

Yeah I get the theory for the most part. I've painted lots of miniatures and canvas so I know when to highlight/shade and contrast things for the most part. Problem is I have very little experience with photoshop and other digital programs that would make this a lot easier (like flash).

Funnily enough the only animation I really know is traditional frame-by-frame from my early days mastering freeware stick figure animation programs, so it's butt-in-seat time for me to catch up with these new gizmos nowadays.

Anyways, looking forward to your next update. Since we are both in pre-alpha now I think we can keep this devblog-comment tennis up for a while and hopefully see each other through the projects.

 

[Gravedust]

Yeah, sure thing.

Seems like you've got the basics already, which by far is the hard part. I draw in analog but all my coloring experience as been digital… I don't have much experience in animation either, did a little in 3D a long way back and have been messing around in Spine some. I still have a lot to learn; this project ought to do me a lot of good in that department. By necessity most of the player anims will be handled by sprite puppetry, but I'm hoping to do all the enemy animation by hand.

I can make one suggestion though; If your project is mostly about machines, space rocks and other inanimate objects, you might want to give Adobe Illustrator a try, if you have access to it.

It's quite good for rendering machines, and the resulting art is very easy to modify.

( Sprites are from this thing. )


...But if you're interested in a pixel'y look then it's probably not the way to go.

 

[Gravedust]

I'm back!

And boy did I screw up!

So the inventory system earlier looked like it was working fine, but in fact that it was doing was failing in a very specific way while looking like it was working correctly.

So me trying build some extra grid functionality into the system made the entire thing explode catastrophically (in harmless programming terms, anyway.) It took me a while to figure out exactly what was happening, (a certain script I wrote wanted a grid index as an argument, and I screwed that up by passing it a grid reference instead of the index from a different script, and GMS has some interesting reactions to not being able to find the grid it's looking for.) but after that it was just a matter of doing some script adjustments and resolving to be more careful in the future.

So, while progress this week has been slow, I'm excited to start making headway again and I have high hopes for accomplishing some cool stuff this weekend.

Not much to show visually, except I have hammered out a piece of test headwear:

Still a bit WIP-py, but you get the idea, probably.

 

[Eclip5e]

These Sprites look really awesome man! Do you maybe know how to make an object/sprite look like its glowing? I need this for some projectiles and as you can make cool sprites you may know

 

[Gravedust]

Sure.

There's a couple of ways to go about it, but If you have access to a program that does transparency and gradients, the easiest way (IMO, anyway) to make a glow is basically just to give a bright-colored object a 'nimbus' by placing a transparent gradient disc over or behind it:

And that's the basic technique for glows, more or less. You can experiment some to find what works for your particular project. If you don't have access to transparency though, you may have to get a bit more creative with colors and animation.

Another thing to look into though is drawing your bullets (or whatever you want to glow) using the bm_add blend mode. That can really help sprites really stand out and appear luminous.

 

[Kestril]

So the inventory system earlier looked like it was working fine, but in fact that it was doing was failing in a very specific way while looking like it was working correctly.

So me trying build some extra grid functionality into the system made the entire thing explode catastrophically (in harmless programming terms, anyway.) It took me a while to figure out exactly what was happening, (a certain script I wrote wanted a grid index as an argument, and I screwed that up by passing it a grid reference instead of the index from a different script, and GMS has some interesting reactions to not being able to find the grid it's looking for.) but after that it was just a matter of doing some script adjustments and resolving to be more careful in the future.

So, while progress this week has been slow, I'm excited to start making headway again and I have high hopes for accomplishing some cool stuff this weekend.

Isn't it funny how under-the-hood stuff can help or hinder so much but show very little when it comes to came content things?

I really make a conscious effort to use the minimal amount of making assets until I'm as sure as I can be that the under-the-hood programming system more-or-less works like I need it to.

Hang in there buddy! Hope to see more next week!

 

[Gravedust]

Hehe, yeah. Code optimizing and implementing new background stuff is always a bit wierd, like when someone asks you've been doing for the last 7 hours and all you can really say is "A bunch of stuff that you can't see but trust me, it's really cool."

The bug delay was annoying but I'm not at all unhappy with my current task since I am learning a HUGE amount, and this is stuff that will also benefit a backburner project (the space game I posted a vid of earlier, which needs saveable ships and ship Inventories) and I'm sure a lot of future projects as well. So in a lot of ways my time right now is being multiplied.

The other big coding expedition I will probably have to undertake is to hammer out some A* pathfinding with a few extra bells and whistles and handles because I think there's some really cool stuff I could do with that. That probably won't happen for a while yet though.

 

[Gravedust]

And we're back!

Despite lots of indications to the contrary, I have in fact actually done quite a lot of work on this project, just nothing that was really glamorous or interesting, at least not till it was all the way finished.

So after shooting myself in the foot spectacularly with my first attempt at implementing the inventory, I essentially rewrote the guts of the whole thing and I'm much happier with the result, which is loads more stable and extensible. Yay. Also, tackling the features we need to get the inventory working also meant fleshing out a bunch of other systems, so in addition to a working inventory we now have:

- Basic 'Complex' item generation. Yes, it's an oxymoron. What I mean by 'complex', are items like swords and armor that have unique stats which need to be randomly generated and saved.

- We now have a system to generate item stats based on Weapon type, tier (which basically corresponds to game difficulty), and quality level, along with choosing appropriate(ish) names for them, and automatically assigning them icons. Right now it only does swords and axes (and not very intelligently) but we'll expand on that in the future, the framework is all there.

- A system for saving and loading weapons and other complex items. (As well as getting rid of their saved info when it's not needed anymore.)

Anyway, check it out:

All art and text style is placeholder for the moment, I know it's difficult to read, please don't judge too hard. -_-

- Oh and dual-wielding is a thing:

- We now have a basic stat display.....

AND SURPRISE!!!!!! An equipment grid.
It doesn't do much right now, other than let you equip weapons.

- Also, I found time this weekend to test-implement the solution to the 'I don't want to hand-animate every single set of leg sprites because it would drive me to shrieking madness' issue. So far it seems to work! More testing will be required, but I am cautiously optimistic.

- And lastly, I have the verrrrry basic groundwork for the friendly NPC AI. At this point it's just a bit of code that inhabits the same kind of object that the player controls. It's mostly only there at this point to prove that the animation code performs correctly when scripts are calling the shots instead of someone at the keyboard.

But look at that, showing off already.

 

[Gravedust]

Quickie update:

The Implementation Festival continues!

- Since we're getting into menu stuff and all our menus are going to be mouse-driven, I finally got around to adding a button parent object. Buttons just run a script when they're clicked, you define the script and the arguments in the creation event and you're good to go. With a bit of extra code you can change button behavior on the fly, such as having it disable itself of some criteria aren't met, or even change what script they run when pressed. They can be placed via code, or just dropped into a room to make a menu or whatever. They draw their own title text on top of a sprite which has frames for mouseover, clicked, and disabled. Simple, neat, and modular, should have done this WAY SOONER so I could have used them in other projects.

- The facial animation system I was talking about earlier is now in. Will need some tuning and integration, but it works and is largely automatic. You just tell the player object what emotion to show and for how long. In the future I'd like to expand this system a lot to give the player characters a lot of personality; as in a really aggressive character might show an angry face for much of the time or a 'nervous' character might show a scared face in the presence of too many enemies. Lots of fun possibilities, looking forward to messing with it later. While not implemented yet, 'personality' is planned as a character creation option. It won't effect how a character reacts, but it will effect what they say, and how they emote in certain situations.

- Basic character creation is now in. Verrrrry basic, as in you can choose a name and that's it. Really the thing that's stopping me from expanding this to more full customization right now is the lack of sprite art. But hopefully that'll be fixed soon. But the important part is you can now create and save unique characters. Previously test characters were placed in rooms directly and had their differences set up in the creation code, but now we can create them from scratch, and have a system in place to spawn them into playable rooms.

- You can also delete characters, which correctly removes all their data from the game's save file. Amazing.

Anyway, with that, I think we may be done with backend stuff for a while, and unless yet another unexpected dependency arises I believe the next step will be to flesh out the combat system a bit more, while I build up enough art assets to let me flesh out character creation. Yay.

 

[Koohyar]

This looks promising. Keep up the good work!

When is a demo going to be out?

 

[Gravedust]

This looks promising. Keep up the good work!

When is a demo going to be out?

Thanks!

Well, it's hard to guesstimate when I'll have a playable demo, since the amount of time I have to work varies pretty widely, on any given day.

But here's the progress made of far towards a minimum viable product;

• The ability to save and use multiple characters. DONE
• A basic equipment system. (1 sword, 1 chest armor, and the ability to swap for items on the ground) DONE
• Items with randomized stats (Dropped from enemies) DONE
• At least 1 fightable enemy DONE(ish) (still needs basic attack AI)
• Basic combat system (attack types, multiple weapon types/attributes) IN PROGRESS
• Multiple Dungeon floors (Procedural generation not required, yet) and a means of reaching the next floor
• Increasing mob difficulty per floor traversed.

Once all those boxes are checked the plan is to put out a public version for folks to fiddle with, while dev continues.

So there's a bunch of stuff left to do, but most of the 'hard' stuff (i.e. the things I didn't know how to do already) is now completed, and most of the rest of the list is in territory I'm comfortable with. So things should go a bit quicker from here.

It's looking like friendly AI development may proceed at the same time as fleshing out the combat system, so despite not being included in the original MVP list, working basic NPC AI may be a possibility.

 

[Gravedust]

Ugh. Well I wound up getting really sick this week, and as a result didn't get to do much dev work, as my time was pretty evenly split between being asleep, wishing I was asleep, and wishing I was dead.

Since barely being able to think is not a good environment for serious programming, I didn't do much more than notepad out the basic flow of the attack system, and notepad some of the very basic groundwork of the AI.

But even with my higher brain functions commented out I can still art, and since I haven't done much non-sprite art that's just for this game, in my free time I did this:

…I guess you can call it concept art? Really though I was just having some fun, since it's been a while since I worked on anything full-sized.

I'm feeling a lot better now, thankfully, so I'm hoping to get some more serious work done this weekend.

 

[Gravedust]

Quickie update; did a bit of sprite work over the last couple of days, in preparation for adding more functionality to the character create system. (You can't really save appearances until you have an appearance to save…) So I've added some new eyes, hair, mouths and face shapes for player characters, as well as cranked out male tops for the existing armor sets, and modified the green set a bit and fixed up the helmet some. Fun!

Haven't had much time to so any serious coding in the last couple of days, but I have added some minor features and slapped some polish on a few things. I have a few significant coding tasks in mind for the weekend, but we'll have to see how things turn out, schedulewise.

 

[Koohyar]

Awesome graphics! Nice job.

 

[Cpaz]

This looks pretty interesting! I would highly recommend putting as much into the feel of the art and sound as humanly possible. Especially since there are already so many rogue-lites on the market.

I'm a bit bummed that the character size in game isn't large enough to hold all the detail I'd otherwise like to put into gear and faces and all else. Sigh.

Really? I thought the size of the sprites would be plenty. Are they scaled down in-game?

But reguardless, I'll keep an eye on this! I'm interested to see where it goes.

 

[Gravedust]

Thanks!

Yeah, by pixel art standards I guess I have a ton of space, I really shouldn't complain. Unless otherwise mentioned, all game art has been posted at the intended resolution, so pretty much everything is at game scale except for the two larger sprites I posted a while back.

Anyway, figured I'd quickpost what I was working on today, a generic energy blast for testing:

'cause things are definitely gonna need some blasting.

 

[Gravedust]

Weekend update!

Got a decent amount of dev time, not as much as I'd hoped, but fortunately it's stuff I can show-n-tell for once.

Most of the new sprites I made have been imported; and I have started but not finished the character creation screen.

One of the technically simple but fun things I did complete though is an expansion of the character animation system.

So now we have characters that can do emotes!

Huzzah!

In addition to random cheering we can also add a little life to some other actions,

Like picking up an item:

Dropping an item:

Or getting mad when they can't pick up an item because their inventory is full.


And something I finished last weekend but didn't talk about: Charge attacks.

Basically, if you press and hold the attack key, your weapon will start to charge up. At charge levels 1 and higher instead of the normal 'just hit them in the face' attack, they will do whatever the weapon's charge effect is. This could be increased damage, increased knockback, a larger attack template, a projectile attack, or any change involving the standard weapon variables. Not quite yet but eventually charge effects will include running scripts, running scripts on your target, or giving your target scripts to run on themselves every second or every step. So at that point, weapon charge effects can be basically anything.

So I'm looking forward to that. :3

 

[IndianaBones]

Awesome work there! I like the modular animation system a lot! Especially the way you can add many different facial expressions to different actions, gives the game a lot of character.

I also like the fact you can build / train up your characters and then take them with you on the next quest.

How many characters are you going to allow to be taken with you into a dungeon? I was started to imagine being able to take a mini-army of previously created characters into battle with you. When there is a particularly tough area / boss, you take everyone you can get.

Also, if a character you take with you dies, do they get resurrected or are they lost forever as per standard rogue-like?

If it's too early to answer those questions, no problems, I just think that your basic idea has a lot of rich possibilities on what you could do with it.

Great WIP!

 

[Gravedust]

Thanks!

I'm not yet sure what the maximum number of characters in your party will be, but it will probably be between 4 and however many becomes just too utterly ridiculous and/or overwhelms the GUI with stat boxes. >.>

But since we obviously don't want the solution to every combat problem to be 'just throw more guys at it!' the game will probably react to a really big party by spawning more enemies and increasing their stats. So if you do want to go after SuperMegaBoss, Drinker of Tears, or a really tough area, it may be better to assemble a team of your 4 or 5 best guys, since taking more people may increase the difficulty beyond what everyone can collectively handle. But steamrolling a level that's not on the edge of the difficulty curve with a ton of dudes for fun ought to be a possibility.

What happens to your NPCs (or your character) when they die depends on what difficulty you are playing on.

On Casual mode, a character that gets knocked out will drop out for the rest of the dungeon (If it's you that gets knocked out, you will take control of another character.) and you can get them back at the Hub. They might also lose their accumulated XP towards the next level as a bit of a penalty that should start off fairly mild but start to matter later.

In Mediumcore (or whatever I wind up calling it) characters that get knocked out will lose all their gear, but otherwise be okay.

In Hardcore, the character dies and is gone forever along with all their stuff in typical sadistic hardcore style.

 

[Gravedust]

Quick update regarding the character creation screen:

(it works!)

It's Placeholder City at the moment, but it does everything it needs to for now.

So we can change most aspects about our appearance... Let's click ourselves some 'Randomize':

Some of the combinations look a little goofy and certain sprites will need some adjustment... There are a few extra skintones and other bits that don't get shuffled into the random settings, because while they work, more often that not they look really ridiculous without a guiding touch. But everything can be accessed through the arrow buttons. And of course a lot more options will be added as things move along.

The "emote' button will make the character do a facial expression, so you can see how your eye/mouth combination looks when smiling, upset, etc.

And that's that. Movin' on something else!

 

[Gravedust]

Quick update before the weekend:

Charcreation (and armor implementation) needed a 'starter/default' set of armor, so now there is one:

I also added a new hairstyle, and started updating an older one (still a bit WIPpy)

And here's a random weapon sprite I like the look of:

The rest of this week's work has all been notepadding in preparation for some more stuff regarding combat and weapon generation, The gist of which is basically: Adding more weapon types, differentiating them in terms of role, and trying to make attacking with each type look nice.

I also need to fix a minor problem with how I saved sprite info (by index, like a dummy, so every time I add or remove a sprite it shifts the indexes around and things get… Weird.) Should be an easy fix*, but I'll miss loading up and randomly having my char's torso replaced by an item icon.

*Thereby jinxing myself to 28 hours of tortured reimplementation.

 

[Gravedust]

Well despite appearances I've been hard at work, but I've been doing a lot of behind the scenes stuff regarding weapon types (specifically adding animation and inventory/equipment support for 2-handed weapons, and enabling custom animations for different attacks and idle poses for holding different weapons, etc.)

Much good progress, just nothing to look at yet. When I'm done I should have a good show-n-tell post.

But in the meantime, let's talk about game AI!

I really like coding game AI.

Here is the first complex enemy I ever coded: (the bladed shooting thing)

(my pride insists I mention this was a testing build)
I'd hesitate to call it an AI, it was really just a state machine that chose randomly what it wanted to do. (shoot/keep shooting, fly onscreen/offscreen)

My next try was enemies for Kensei:

Which had discrete 'modes' they would drop into; if they see the player object they path to it try to kill it, running specialized scripts that tell them how to attack based on what class they are. (you don't get to see too many attacks in the video, the way the game is, if they get to attack it usually means you made a mistake. >.> ) If they lose sight of the player (You don't really see it in this video either. -_- ) they will hunt him for a short time before going back to their idle state and returning to their origin. They also had some provisions for recognizing when they were stuck on something and trying to correct that.

But so far the most complex AI I've done was for my space Sandbox/RPG/RTS/TDS chimera Lacustrine:

Lacustrine ships understand factions, can choose targets intelligently and maneuver to employ their weapons effectively, automatically avoid obstacle objects in a non-pathgridded environment, move in formation, try to escape when damaged, and automatically decide which ship systems to route more power to (shields, engines, guns, etc) based on the situation. They can also obey orders given by the Player (waypoints, attack targets, escort, patrol, etc.) and the player can hot-swap into or out of an AI-controlled ship at any time without interrupting anything. The same AI package controls enemies, friendlies, and every ship class from fighters to battlecruisers. My computer can handle 150+ of them duking it out in a combat stress test and keep it's framerate.

I'm sure folks can do better, but I think that's pretty decent.

So what are my plans for SDS?
(Spoilered because quite long)

Spoiler

Well as mentioned, one of my major goals is to give the characters as much life as I can. As mentioned (…somewhere) above, it will be possible to choose a 'personality' for the characters you create, which, while it will have no effect on the character's choices in combat, will effect things like what they say in and out of combat, and how (and if) they react to certain events. So while you may not really consider it to be a part of AI, I will be integrating a system to intelligently control dialog and emotes in and out of combat based on what's going on.

But of course the majority of the work (and the fun stuff) is going to involve combat.

First and foremost, I want the combat AI to be an asset. While it ought to be possible to 1-man the entire game if need be, I want NPC companions to feel like valuable contributors and worth taking with you. The player should not feel like the NPCs are liabilities, or slowing them down. So they should be efficient and capable.

But I also don't want them to feel inhuman. This was something I had to work on in Lacustrine. AI can react (much!!!) faster than any player can, so for Lacustrine I actually slowed down their reactions and put big pauses in-between their decision making, as well as purposefully dithered their aim points to prevent them from intercepting every target with every shot perfectly, like they are absolutely capable of doing. I already feel like the SDS AI will need some similar toning down.

I also want to make sure the AI plays by (nearly all*) of the same rules the player does, when they're controlling their character. This is especially important given that the player can 'hop' into an AI's shoes at any moment and take over; so AI being able to ignore the normal mechanics is just not going to fly. *I reserve the right to teleport AI to the player if they get lost, or otherwise /unstuck themselves if need be.

So basically the NPC AI has to know how to play the game. And I think teaching it will be a lot of fun.

Another thing to note is that while I want the AI to be very complex, I want the player's exposure to that complexity kept to a minimum; I really want the player out and adventuring, not hanging around the Hub fiddling with AI sliders. (Though I totally get that that's fun for some folks. I'm one of them, obviously. >.>) Ideally the Player shouldn't need to think about it at all if they don't care to; it should just work. But for cases of fine tuning, my plan is to also include some basic controls in the form of telling an NPC what Role they should fill:

-AI ROLES-
TANK:
Try to attract the attention of as many enemies as possible. Get in close, stay defensive, heal yourself if you can. Never retreat. RRRRRRRRR!

ATTACKER:
Hit things really hard (Melee or Ranged preference is determined by weapon/magic/skill loadout). Prioritize doing damage above healing or CC. Run if you're hurt.

CONTROLLER:
Prioritize debuffing and crowd control over doing damage, but hit things when it's convenient. Run if you're hurt.

HEALER:
Prioritize healing. Stay out of trouble. Deal damage when everyone is fine, but don't use MP on attacks unless the battle is easy.

AUTO:
Figure it out yourself! Choose one of the above roles based on your skills, weapons and armor.

AUTO will be the default, (and will note whatever Role and character AUTO'd into, as in "AUTO(Tank)", "AUTO(Attacker)" etc.) When Auto-choosing roles, attention will be given to party makeup, to try to form a more or less balanced party. But if it's not doing things how the player wants, they can set Roles themselves.

The second layer of granularity the player has access to is Role Tactics, which mainly governs finer points of prioritization. So for instance, an Attacker role might have access to the following Role Tactics:

<…incomplete example list…>
Destroyer: Prioritize using AOE attacks when you can hit multiple enemies.
Assassin: Prioritize targeting Healer or Controller enemies.
Opportunist: Prioritize enemy with the lowest health% (weighted by threat rating)
Challenger: Prioritize the enemy with the highest threat rating.
Player: Do what the player would do!

So that last one seems pretty cool? That's the thing I hope I can get working the most. I'll talk more about how I'll try to implement it later, but basically, when the player is inhabiting a character the game will record things about how they played that character. And when the player isn't on that character, It'll then try to 'mimic' the player by trying to use the same tactics it has observed the player using, (in terms of attacks, skill use, positioning and target preference.) This info will be saved with the character's other data.

---------------------------------------------------------------------------------------------------------

So how am I actually gonna do all of that?
(Spoilered because also quite long)

Spoiler

Well I don't know for sure, and some or most things will probably change and I stand by nothing at this point. But here's what I'm gonna try:

I will have some sort of controller object (Let's call it obj_combatcontroller) to collect information on the battle situation (what enemies are involved in a fight, a generated 'threat' rating for each, and misc. info that is useful to have like HP, defense, resistances, which areas of the battle are 'hot' with AOE or lots of mobs, etc.) It will refresh this info every few steps or whenever it needs to. This should make for a nice place for the NPC AI to look at when they need to figure out what to do, without having to iterate through the actual enemies. (And also it will have info for enemy AI to use as well…. >.>)

The combat controller will also handle Calls. Calls are sent by the AI when they need something. So for instance if an AI hits low health, it will place a Call on the combatcontroller. Then when the next AI checks in with the controller, it will see the Call and know that somebody needs healing. They can then evaluate their own ability to answer that call. If they decide they can/should (I've got healing skills, I've got high MP, and I'm already in range), they set that as their 'what I wanna do' and flag the Call as answered.

As a side note: A convenient aspect of assigning Roles is it helps the AI figure out what to do. For instance a Healer role looking at two healing calls, would weight the Tank's call over the Attacker's call when deciding which one to actually heal.

There are obviously some caveats that can screw a system like that way up, (I bet you're thinking about one right now, aren't you…?) which will need to be accounted for, but that's the basic gist of how I see the system as working. In addition to "CRAP I'M DYING!!!" AI might issue calls for crowd control, or try to attract attacks onto a high-defense target they can't do much damage against. In general it seems like a fairly low-impact way to get useful coordination between units; each one evaluates it's own situation and if a need arises, it advertises the fact where other units can potentially decide to act on it.

Individually, AI will try to decide what to do using a system of weighted options, working from general to specific:

Main Option Categories:
+ KEEP DOING WHATEVER YOU ALREADY ARE
If the AI previously decided on a task but hasn't finished it yet, this will be pretty heavily weighted, but with every AI update the weight will be reevaluated to give a new category the chance to take the foreground. If the task was just completed it will be reset to 0.
+ OFFENSIVE OPTIONS
From Lacustrine I learned that it's usually effective to have Offensive have a more or less static value (in this case most strongly modified by Role) that other categories compete against.
+ DEFENSIVE OPTIONS
Defensive in this case means anything that helps the unit's own survivability, that is not Healing. This category becomes very heavily weighted when at low health or under a lot of threat. Usually it entails using a defensive Skill, or just moving to a safe area of the map and/or Calling for healing or other help.
+ CONTROL OPTIONS
Control options entail things like sleeps, stuns, slows, and/or anything that reduces the enemy's ability to attack and/or allows a friendly character to escape. (may or may not include debuffs which might get their own Category.) As with Offense, the Control option is largely static, but notably effected by Calls, as well as the threat rating of potential enemies.
+ HEALING OPTIONS
Healing pretty exclusively refers to skills that restore health. Weighting is pretty simple, and based on the amount of missing health of party members, and how hard the fight is.

Once the AI has decided on a category, (well, I say 'decided' but it always chooses the one with the most weight) it looks at the available skills (or attacks) it has available that are classified as being in that category, and weights each of those. Eventually choosing the 'best' option available at the time. Pretty standard AI stuff. Offensive has a few extra steps in order to evaluate targets and which skill will be the most effective against them. The offensive tree will probably be pretty huge. -_-

Once it knows what it wants to do, it then decides 2 more things:
+ The Action target: Basically; who am I going to do this action on? (It probably already knows this, but it is officially set as a specific ID at this point)
+ Where it needs to go: Skills and attacks have associated ranges, so if they do not already meet the parameter for skill use, they have to choose an appropriate spot to go to.

And once those have been set, the main decision tree ends and doesn't get called agin for… a while, probably on the order of a second or two. However there will be methods of forcing a recalculation for certain events that warrant it. (like a sudden drop to low health, a Call, etc etc.)

So with the main decision made, the AI then goes about getting to it's destination point, and seeing if the parameters are correct to do it's action. (am I in the right spot, is skill off cooldown, or at the right charge level if it's a weapon, do I have MP, etc.) This is basically a step event that moves, checks, moves, checks, moves, checks, until it either gets the right conditions, or the main decision tree decides to do something else. When the conditions are right it does it's action, flags the action as completed, and calls the main decision tree.

And that's basically how it works. Or basically how I hope it'll work. We'll see how hilariously wrong I am when I decide to code the thing. As of writing I am not really ready to start. There is still a lot of implementation to be done in the weapons department (as mentioned above) and I still need to do a lot of work organizing skills, but I think once weapons are in I can start testing, at least on a limited scale. So, soon-ish!

Anyway, above I was talking about trying to teach the game how to mimic the player - Let's talk about some specifics!

So, behind the scenes, skills and weapons will have some common invisible stats that help the AI know how to use them. These haven't been fully fleshed out yet since I'm still messing with weapons and haven't even started messing with Skills. But, to use Weapons as an example: a Greatsword for instance might have the following hardcoded 'AI stats':

rangeMin = 50; // minimum range to target (do not attack if CLOSER than this - the template will probably miss)
rangeMax = 120; // maximum range to target (do not attack if FURTHER than this - the template won't reach)

Which set some boundaries that tells the AI where it needs to go to hit a target with this sword: A point_distance the average of rangeMin and rangeMax from the target, or at least between those two values. Well and good, the weapon can be used effectively.

But the player of course won't know what these invisible values are. They can of course visually see how much area a Greatsword swing covers, and immediately know that's about how close they need to get. So the player approaches and swings, hitting the mob. When this happens we do a quick point_distance(x,y,target.x,target.y) and set a variable:

rangePlayer = 95; // average player swing distance

And maybe you can already see where this goes. The AI can use rangePlayer as a reference point for how close to get to swing a greatsword, and the more the player attacks, the more the player 'teaches' that AI how to use the weapon the way they do. Maybe they like to attack from the outside envelope to stay out of the range of a possible counterattack, maybe they like to attack closer in to try and hit more than one enemy with their swing. These preferences will be passed down the the AI, which will then use a greatsword differently than any other AI in the game. (unless you train another one to do the same thing.)

Attack distance is just one of a ton of possible data points, of course. To better approximate the player's playstyle we'd have to use a lot more. So we will.

I'll have a better idea of what to track and how to incorporate it into AI tactics as the game moves along. But some fairly simple examples of other things to scrutinize are:

- At what health% does the player usually heal themselves on this character. At what health% do they heal others?
- Which Option Category does the player seem to weight most highly on this character (Offense, Attack, Control, Healing, etc)
- At what range does the player prefer ranged over melee options. (to shoot rather than to move in)
- Does the player prefer charged attacks or single swings? (per weapon category)
- Which kinds of enemies does the player prioritize attacking first?
- and so on and so forth.

I believe we can get a pretty decent picture of a player's habits and basic strategy by examining this and other data, and reflect the weights of their choices in the decision making tree the AI uses. I'm not going to say that the AI will be able to perfectly mimic a player's playstyle, but I pretty firmly believe we can have AI that behaves in recognizably different ways in combat, with the player able to steer AI decision-making via their own actions and without having to personally fiddle with any settings.

So that's my big experiment for this project, pretty much. Again, everything is up the the air and things may not work out exactly as I have mentioned here, but I will push hard to accomplish this, and will be very bummed if I don't.

Anyway, thank you for traveling through this wall of text with me.

Hopefully will have a more visually interesting update ready to go soon.

 

[Gravedust]

Update time!

First off, the little things:

Added a leg frame switch to make the jumping look a bit nicer:

Also made some small adjustments to run cycle animations and torso lean.

Small things, but they add up.

Anyway. On to the fun stuff!

A big expansion to the weapons and animation systems means more types of weapons we can handle, and prettier, more unique animations for each class.

So we can have axes that go chop,

And swords that go stab.

We also now have support for the first of our 2-handed weapons, the Greatsword.

Greatswords won't be the only 2H class, but they are typical of the 2H breed in that they're very slow compared to 1-handed weapons but have a broad attack range and can hit multiple enemies in a swing:

Also I have done some fiddling around with different charge attacks

*360 noscope not indicative of normal gameplay.

So far I'm happy with how everything has been turning out.

Next on the To-do list are implementing leveling and stat gain, and finally giving enemies attacks and proper AI. After that will probably be actually assembling the levels to play in.

It's taking a really long time, but we're getting there.

 

[Gravedust]

Heyy, it's time for the not-at-all regular friday update!

First off, did a little bit of spritework this week, added a few more weapons and a new hairstyle:

The rest of the work this week hasn't been very visual, but kind of important to overall progress.

Basically I added a (placeholder) method of adding/removing characters from your party in the HUB, and correctly spawning and setting up your selected party when you move to a game level. I also implemented hot-swapping between party members. ( …well technically it was in before, but now it looks nice.)

I also implemented fullscreen and added views. I also needed to build a draw order controller since depth= -y doesn't cut it any more. Friendly Cosmonaut has some very nice youtube tutorials on how to do this which probably saved me a couple hours of figuring it out myself.

Also added pause behavior to most game objects in preparation for some menu work to come in the near future. So the game will stop while you're doing things like leveling up, which will likely be my next Todo along with a rework of the character stat panels.

So yep. Doin' stuff.

 

[Gravedust]

Howdy folks, been a while. This is in part because I like to have something visual to show for updates, and I haven't been doing much visual stuff lately. But I did do another hair, and additional eye and mouth sets:

( It's animated. But since it's meant to be the 'deadpan' eye set and the point is to show the minimum amount of emotion possible, it isn't much of a showcase. -_- )

I also replaced the current meatball hands with slightly better rendered ones, and made them two sided (like the torso and leg sprites) so they can show either the front or the back of the hand based on how the character is facing. (Hand sprites will be visually replaced by whatever gloves/gauntlets/etc your character is wearing as armor) I am also looking into using multiple hand sprite frames to show different hand gestures, (pointing, waving, etc, maybe something for spellcasting or whatever. Could be fun.)

But really, most of the work since the last update has gone into making the player UI statboxes fully functional. They now properly show HP/MP/XP levels, have separate panels for gear/stats and inventory, and reflect player stats. Stats have now been fully implemented, including derived substats which are based off primary stats. I also implemented a level up panel where you can assign the bonus stat points you get when you level.

I also introduced a placeholder bar for character skills and hotkeys. While these are not really ready to be implemented yet, I wanted to reserve the UI space for when they are.

Statboxes can change position, so whichever character you are controlling will automatically slide to the upper-left-most position, and the rest will re-organize themselves. Max party size at the moment is 8, though I have had 16 following me around with no problems.

Of course now that the UI overhaul is done I can see 11 ways I could have done it better. So I've already got plans for rewriting the whole thing, but I probably won't do so until after I get an alpha release out the door.

Anyway. Now that stats, XP, and leveling are hooked up correctly things are a lot more gamelike, which is gratifying.

It looks like my next step will be improving enemy behavior, giving the friendly AI temporary code to allow them to follow the player around and make attacks, and then starting on level construction basics.

 

[WarpDogsVG]

Would love to see more screens that aren't just the character!

 

[Gravedust]

Would love to see more screens that aren't just the character!

Right at the moment the character sprites are pretty much the only art assets I have since I needed them to set up most of the animation systems, etc.

Until I start working on level layouts I won't really know how to spec my background tiles and such and so there's a limit to what I can work on efficiently. But hopefully I'll be at that point soon-ish.

Will definitely post tiles and level art once they are completed.

 

[Gravedust]

Howdy folks, time for a quick update!

I'm elbow deep in the AI!

So far so good, I've been building the separate pieces without actually implementing them yet, to keep everything fairly easy to alter if I decide things need changing.

One big change that has occurred already is the reconceptualization of player weapons and skills into a single data set, because it'll be easier for the AI to figure them out that way, and skills and weapons share a lot of variables anyway. So essentially weapon attacks are now skills, and weapons are 'containers' that save skills that are randomly generated from a number of presets based on the weapon type. (In terms of how the game looks at them, NOT how they will be represented in the actual game/gameplay) In addition to being a lot easier for the AI to digest, this will let us get a lot crazier with what our weapon effects can be without needing to do a lot of extra work, and also opens the way for fun stuff like copying or stealing skills from enemies.

I've also put together the groundwork for the combat controller object, which basically stores information that the AI can access quickly (without having to check actual instances) and use to make decisions. I added a basic detection system where enemies can acquire their targets and go into combat to pursue/attack them, switching targets or reverting to an idle state if the lose track of their foe for too long. I also have a system to deactivate enemies when they don't need to be loaded, standard stuff, yadda yadda.

So things have actually been progressing pretty well, but here's the problem: I was initially intending to leave out a lot of the more difficult / time consuming parts of the game until after I did an Alpha release.

But I'm realizing now that most of the cool stuff I want to do is tied in with the long-term stuff.

For instance, custom A* pathfinding (custom so it can take AOE effects and enemy positions into account when choosing paths, as well as look at the influences that movement skills might have) was supposed to be a much later feature, but in order for the AI to really shine, it needs to be working. The 'learn from the player' AI system was another long-term project, but if I'm going to be implementing AI anyway, I may as well make it full-featured from the start rather than have to weld it on later or rebuild from scratch, and since the skill system is tied closely in with how the AI evaluates it's options, that sort of needs to be implemented as well before I can really call the AI 'done.'

Aaanyway. The point of all this is I'm changing my tack to not releasing even a test alpha until all the major systems are working.

So the new Minimum viable product is now:

- Full AI for NPCs and Enemies. (Combat evaluation on strategic, tactical, and skill use levels, coordination betw. units)
- Fully implemented item generation, including Weapons and Armor.
- A decent number of skills available to Player.
- Procedural level generation (because at this point, why not??)

AND IT'S GONNA TAKE A MILLION YEARS!!!

Well not quite. But I will not be at all surprised if it takes the rest of this year.

I'm not really perturbed by this, I'm actually having a great time and I feel like I'm learning a lot of valuable stuff.
But I want to apologize to anyone who remembers when I said it would be out in a few months. -_- It definitely won't. But I feel like the project will be much better served by going for a full feature set out of the gate, rather than making a weaker version of the final product for the sake of speed and then trying to fix it to be what it was always intended as.

So. More updates as things happen, but I anticipate they will slow down a bit since I have big coding chunks to chew on, and nothing in the art pipeline for the immediate future.

 

[Gravedust]

Well I've been quiet, but it's a very productive sort of quiet.

Work has been going well on the new AI. After some pretty serious preplanning and Notepad code writing, I sat down this morning and hammered out the bones of the new system.

This afternoon success was achieved when a slime shot a fireball into my face and killed me. It works!

There is a loooonnng way to go before everything will be fully working, but now at least I have something to test and fiddle around with, rather than a subfolder of .txt files filled of code that pisses off my spellchecker.

In other news, I have moved towards implementing armor and other gear into the game. Chest and Leg armors are enabled as drops and can be equipped with the accompanying visual changes to your character model. Stats are generated for them as well but not actually applied to the character when equipped yet. That's probably not far off though. I also made some changes to certain face sprites to make them show up better on more skin tones.

And that's pretty much it! Lots of work to do in the near future but most of it should be pretty fun. Very excited to finally get past the planning stages with the AI and have something to actually tinker with.

(on a sidenote: #REGIONs!!!! YES!!! And the new debugger is just wonderful. Perfect timing since I will probably be seeing a lot of it for a while. -_- )

 

[Gravedust]

Quickie update:

New helmets, in preparation to implementing them as an armor type.

< --- you can really tell these guys are feeling the magic of adventure right there.

Work continues on the AI. Right now they can choose targets pretty effectively, based on position, health% and whether or not they have LOS to them. Fairly straightforward, though I did introduce a catch wherein when changing targets, the enemy will temporarily add a lot of weight to that target, decaying to 0 over the course of a few seconds. This is to avoid situations where an AI faced with two very close target scores would constantly switch targets and therefore not engage either of them very effectively. With the system described above, once they choose a target, they will 'stick' to it pretty well for several seconds at least. So far so good.

The AI can now handle evaluating multiple skills in the same category. (Right now it only has access to Offensive, the rest will be enabled as we test) and use whatever the situation requires. (Though if everything is on cooldown it doesn't know where to move and winds up just rubbing it's face on the target. This is intimidating, but not effective. I'll have to fix that. >.> ) Similar to giving extra weight to new targets, I also apply extra weight to a newly-chosen Skill to prevent the AI from deciding it wants to do something else and canceling the current skill before it actually has time to use it.

In other news, there is now a progress bar for enemy attacks that take a while to warm up. (i.e. ones you should probably worry about.) including the skill name. So this way when you see somebody cranking up their Hellfire Annihilation Gravitic Murderbeam++, you will know you should politely step out of the way.

In additional, potentially related news: I am experimenting with allowing players to dodge certain attacks by jumping over them. (think of it like a dodge roll, just.. no rolling.) So a nimble character could conceivably try to avoid attacks rather than tanking them out, or be forced out of their positioning because they had to dodge horizontally around something. Will probably require some balancing and should probably be tied into player stats somehow, but so far it's a fun addition.

So yep. Things are gettin' done.

 

[Gravedust]

Post-weekend update!

New armor set:

And work with the AI continues, and a couple crucial secondary systems have been set up at last.

The first of which is the Autoscript system. AutoScripts are 'self-managing' scripts in that when they are added to an object, they initialize any variables they need to in their own private datamap, do what they are designed to do (which can be complex and persistent, since they have access to their own variables), and then when finished delete themselves and their datamap. So there's obviously a lot that can be done with that, though the use of ds_maps means we probably shouldn't get too crazy with them.

And that being done finally gives us the ability to have skills apply scripted effects. (so we can now have weapons that set you on fire when they hit you, or bounce you 40 feet onto the air, or honestly almost anything we can think of without needing to have dedicated variables on an object to do them. One ongoing project for the future will be to fill out a 'library' of script effects to put on weapons or attach to other skills.)

I have also implemented a change to stat variables, in that instead of a single value they are now all arrays with 5 cells.

so hpMax = 20;
is now hpMax = [20,0,0,0,20]; (taking advantage of the (new?) way gm lets us fill arrays)

Long story short, this lets us figure out buffs and debuffs from several different sources easier; the first value is the 'saved' or base stat, and the next 3 are set by Gear and two kinds of events and the last is the total of all the other cells added up, and the value we pay attention to in game. It's an additive system that makes it easy to track and recalculate buffs or debuffs to any particular stat.

As far as actual AI stuff, The Defensive and Healing trees have been enabled and now are prioritized decently well. So now the AI knows how to buff and heal itself when it needs to. Even though it's just the one test mob that has AI enabled so far, sparring against the thing is actually getting to be kind of fun. I'm pretty confident I can get a decent range of enemy behaviors out of it.

But anyway, progress continues. A lot has been done but there's still a lot left to do. Pretty happy with what's there so far, though.

 

[Gravedust]

Friday update!

More AI stuff (surprise!). I have converted player weapons over to the new skill system, so now friendly NPCs using weapons can now fight alongside the player, finally.

This took some visual tweaking to get looking nice but generally it's working pretty well. I'll see if I can get a video of it in action sometime this weekend.

So we're now entering a probably very lengthy session of tweaking the combat AI to get nice looking and effective results out if it. (ex: two AI going after the same target will tend to bump into or stack up with one another as they do so, with the result being that one can't attack, but will keep running into it's partner's back while trying to. Stuff like this needs to be cased and worked around. Fortunately I really like messing around with stuff like that.) So there are miles and miles to go, but it was gratifying to see player NPCs smacking slimes around for the first time.

In other news, I have been banging my face against some custom A* pathfinding code. Not much to say about this other than it's not done yet. Pretty confident I can bring it home, I mostly just need to find an implementation that doesn't get too messy.

In news[2]: I have been making preparations to expand the enemy animation system. Unlike the player characters who are animated by twiggling sprite offsets and rotations, enemies will be animated by traditional spritesmanship.

The animation system should accommodate front and back versions of animations, (and swapping between them mid-animation) as well as multiple versions of the same animation 'category' so we can have 4 attack animations, 4 hit animations, etc, and choose them randomly, programmatically, or by specific reference. (so for instance, when an enemy is hit we automatically show the hit animation that corresponds with the percentage of total health that was just knocked off)
Anyway; some enemy animations I did in preparation for putting in the enemy animation system:

Close AOE attack

Hit by heavy attack (damage > 75% total health)

...Still new to sprite animation, but I'm about to get a LOT of practice. >.>

One of the nice ways my combat system plays into the animation system (that I didn't think about when I was putting it in, but I'm glad it's there. ) is that every attack has a 'warmup' time, (usually just a couple of frames, but can be longer for 2H weapons or really massive skill attacks) between releasing and when it actually triggers. So that allows me to add a few frames of 'wind up' in an animation, and have the attack come out at a time that makes sense visually. (Ex. the 'attack' part of the top animation occurs 3 frames after the animation start)

I'm presently looking into some options for palette swapping; so far strongly considering Pixelated Pope's program, mostly because it comes with an editor. And because the Pixel Pontiff is rad.

Anyway. All kinds of stuff going on currently. So much in fact that I feel like I'm going in a few directions too many. This weekend I will concentrate on picking one thing and focusing on it.

 

[Gravedust]

Whew! Been quite a while since the last update, mostly on account of a lot of non-dev concerns, but things have still been progressing!

In short, here's what's been done:

Made a few improvements to the AI, mostly making them more likely to use faster attacks when closer to enemies, and more likely to wind up big charge attacks when further away. They also try to start charging at a point where they will be in attack range right as they get to the charge level they want to use. Additionally, I added a simple dodge routine for when they are in attack range. It's not extremely effective, but it does look nice. To do in the future will be to add awareness of when a target is being double-teamed, and encourage switching to an unengaged enemy in that case.

I've rewritten the weapon generating system (again!!) to mesh it better with the skill system (Since weapons are essentially containers for saved skills ) and in general make skills easier to handle, and edit. I'd explain exactly what I did, but it's boring and confusing. It's a nice under the hood change though that will save time and heartache as dev continues.

The sprite animation system is in and working, though I will probably do an improvement pass sometime soon. But it works!

Pop!

...I just need a million years to do all the sprites I want. -_- One of the pleasant things about the current system though is it uses placeholder slots, so you can fill in animations as they're completed.

Aaand we now have palette support. I wound up using Pixelated Pope's system, which proved simple and easy to implement. The basics are in now, and I'm looking into some of the more advanced features. One hurdle I did need to deal with is that I have interpolation enabled (so I can rotate player sprites without having them look terrible), which is something that palette swappers really really do not like. However I was able to fix this in pretty much the most caveman way possible by flooring camera coords and the draw positions of all palette-enabled sprites. That way everything lines up and no interpolation is required. I was honestly expecting it to not work but apparently it totally does. : /

So, pretty decent progress despite a lot of distractions. One of these days I'll actually get around to doing that gameplay video too. >.> I just always feel weird posting things I'm not totally happy with visually, so I've been balking. Hopefully soon tho!

 

[Gowford]

Wow ! everything looks so fresh and good , how do you manage to make such good artstyle and call it "bad" or "underdeveloped" ??

 

[Gravedust]

Thanks very much.

I think it's all a matter of perspective... I've been a graphic artist for over a decade, so presentation and polish are just really important to me, personally. (Probably too important, honestly.) So if I don't love how something I did looks, I tend to get twitchy and talk it down a bit.

This is the about level of polish I'm happy with, for my own work:
(Spoilered 'cause big images)

Spoiler

and for game art (though I realize SDS will never look this, since so much of it will not have antialiasing):

…man I got a lot of mileage out of that tileset…

And SDS isn't there yet.

Anyway, none of this is to say that I think games -should- care so much about how they look, ESPECIALLY while in development. This is just my personal standard for my own work not being met yet. With time I think it'll get there, and then I'll stop whining.

 

[Gravedust]

On a side note: Gerblins!

Now that I have a semi-formal animation system, I need something more complex to test it with, (specifically, how it handles front-back sprite transitions.) as well as a more interesting subject for palette swapping. The existing slimes only really have one side, and are pretty much all one color or another. ;P ) So today I hammered out a Gerblin sprite as a testbed. It's layered quite a bit, with the hopeful intent being that I can do a couple of variations (different chest pieces, different helmets, etc) with a relative minimum of conversion. I'll see how it pans out though...

I have a few more details to add to the front, and then I'll start in on the back version.
Once both are completed I'll try to figure out how to animate this mess. Should be fun.

 

[GDMIC]

Great artwork, I seriously love the approach you are taking, can't wait to play it.

 

[MysteryPoo]

My goodness. This looks so impressive to me. I love the fact you're doing like a dev diary thing. I want to give you money lol, this thing looks fun.

Are you planning on multiplayer?

 

[Gravedust]

Great artwork, I seriously love the approach you are taking, can't wait to play it.

Thanks very much. Yeah.. it's going to take a while before anything is really ready, but I'm looking forward to being able to put out a playable version.


Quickie update: Back version of sprite:

Probably will fiddle with it some more before I call it done.

Also did a really quick and dirty idle animation using just layer offsets:

Probably won't keep this or at least will adjust it a lot. But you can see where the layers are at.

 

[Gravedust]

My goodness. This looks so impressive to me. I love the fact you're doing like a dev diary thing. I want to give you money lol, this thing looks fun.

Are you planning on multiplayer?

Whoops, you snuck one in on me.

No plans for multiplayer, alas. I did actually think about it, but I was already sailing so far into unfamiliar waters I didn't want to take on the extra weight. It would be a lot of fun Multi tho. : / It's possible it could manifest in the future, but not super likely.

 

[Felipe Rybakovas]

I really liked everything about I´ve seen so far! =) Congrats.

Just curious about this animation system that you´re coding... Can you tell more about how it works ? =)

 

[Gravedust]

I really liked everything about I´ve seen so far! =) Congrats.

Just curious about this animation system that you´re coding... Can you tell more about how it works ? =)

Sure, but it's probably less cool than I made it sound.
Technically there are 2 (pretty different) animation systems; the one for the Player, which is all about messing around with sprite offsets and rotation, mostly based on movement and mouse position.

Gonna spoiler the rest because it's big-ish.

Spoiler

As for the code that animates the player sprites, It's mostly a lot of stuff like this:

// (adding some extra comments so you know what does what)
// facingH = 'horizontal facing' ( 1 or -1) (this sets our image_xscale when we draw)
// facingFB = 'facing Front/BACK' (0 or 1) (indexes an array that holds front/back versions of the playr sprite.)
// z  =  Fake z axis variable. Basically it just gets added to the y axis in most case to simulate going 'up' when the player jumps. Mostly used for drawing. But it also gets used to check against the 'height' of blocker objects, which the player can get up on.

   if isPlayerControlled // if you're possessed by the player, orient body towards mouse.
       {
       if mouse_x < x {facingH=-1} else{facingH=1;}
       if mouse_y < y-70+z{facingFB=1} else{facingFB=0;}
       }
   else // Facing for AI -----------------------------------------------
       {
       if instance_exists(targetID) //if there is a target, face target.
           {
           if targetID.x < x {facingH=-1} else{facingH=1;}
           if targetID.y < y+z{facingFB=1} else{facingFB=0;}
           }
       else //if not, face where you are moving to.
           {
           if point_distance(x,y,moveTargetX,moveTargetY) > 5 // only update if you are moving.
               {
               if moveTargetX < x {facingH=-1} else{facingH=1;}
               if moveTargetY < y-70+z{facingFB=1} else{facingFB=0;}
               mouseDir = point_direction(x,y-70+z,moveTargetX,moveTargetY-70)
               }
           }

All hand animations are run by this thing below, which basically tweens the hand positions to points that are stored in a bunch of Ds_queues, and goes to the next queue when its got to where it's supposed to be. The Queues are filled by animation script that are called by swinging a weapon or some other trigger.
====================================================================================================

// ARM ANIMATION QUEUE ---------------------------------------------------------------------------------------
var i = 0;
repeat(2) // do for both hands.
{
if handActionDone[i] //  ((huh.. okay I just noticed this.. it's wierd and I don't know why it's here..but I'm afraid to remove it now... ))
   if !ds_queue_empty(dsqHandRotationTarget[i])
       {
       handRotationTarget[i] = ds_queue_dequeue(dsqHandRotationTarget[i])
       handRotationTween[i] =  ds_queue_dequeue(dsqHandRotationTween[i])
       handXoffsetTarget[i] =  ds_queue_dequeue(dsqHandXoffsetTarget[i])
       handYoffsetTarget[i] =  ds_queue_dequeue(dsqHandYoffsetTarget[i])
       handTween[i]         =  ds_queue_dequeue(dsqHandTween[i])
       handAnimTimer[i]     =  ds_queue_dequeue(dsqHandAnimTimer[i])
       handActionDone[i]=false;
       }
else
   {
   // figure out what your idle position should be, and go back to it.
   // I snipped this because it makes no sense without knowing what the variables involved are.
   }

// Next is a section that tweens the variables you see above.  ---------------------------------------------------

// and finally down here is another section that checks if the hand position and rotation are close enough to their destination to call it good. If they are, handActionDone[i] = true; and hands will tween to their idle positions.

====================================================================================================


Enemies use something a lot simpler, essentially I just have a ton of 2D arrays filled in with sprite info. ex:

var _sprF = spr_slime_idle_0; // 'sprite Front'  sprite to use to initialize ALL front sprite entries.
var _sprB = spr_slime_idle_0; // 'sprite Back'  sprite to use to initialize ALL back sprite entries.

// IDLE ANIMATIONS --------------------------------------------------------------------------------------------------------------------
animIdle[0,0] = _sprF;   /**/   animIdle[0,1] = _sprF;   /**/   animIdle[0,2] = _sprF;   /**/   animIdle[0,3] = _sprF; /**/
animIdle[1,0] = _sprB;   /**/   animIdle[1,1] = _sprB;   /**/   animIdle[1,2] = _sprB;   /**/   animIdle[1,3] = _sprB; /**/

// MOVE ANIMATIONS ---------------------------------------------------------------------------------------------------------------------
animMove[0,0] = _sprF;   /**/   animMove[0,1] = _sprF;   /**/   animMove[0,2] = _sprF;   /**/   animMove[0,3] = _sprF; /**/
animMove[1,0] = _sprB;   /**/   animMove[1,1] = _sprB;   /**/   animMove[1,2] = _sprB;   /**/   animMove[1,3] = _sprB; /**/

//and many others...

==========================================================================================================================================
I'm just initializing default variables above... In a real case at least some of these array locations would have different sprites in them. But it's important that all they arrays be filled by -something-. I initialize everything to the idle anim, so if an animation that doesn't really exist gets called, it just plays the idle and isn't tooo noticeable.

Anyway. in this case, slimes don't really have a 'front' or 'back', so everything gets the same sprite for both categories. The First index of the 2D array corresponds to Front or Back (Enemies also have the facingH and facingFB variables) and the second number is the index for the actual animation. So right now I can have 4 sprites per category, but practically it can be any number. I'm considering using a format besides an array (grid?) that might be more versatile. But arrays are simple so for now that's what we got.

It's also important to note that both the front and back animations should the have the same number of frames, or everything might explode catastrophically.

Anyway, to trigger an animation, I have this script:

//scr_sprite_anim_set ======================================================================
var _anim = argument[0]; // animation category (i.e animIdle or animMove, from above)
var _index = argument[1]; // the animation Number (0 - 3, or -1 to choose randomly) ((the 2nd array index from above))
var _time = argument[2];  // How many frames to play animation for. (or if -1, set length to number of frames.)
var _prio = argument[3];  // animation priority (higher values interrupt and override lower ones.)
// SUGGESTED ANIM PRIORITIES [Idle = 0] [fiddle = 1] [Move = 2] [Attack Charging = 3] [Hit = 4] [Knockdown = 5 ] [All attacks = 6] [Dead = 7]


if _prio >= animCurrentPriority // if the anim priority we are setting is higher than the current one.
   {
   if _index == -1 { _index = irandom(array_length_2d(_anim,1)) } //choose a random animation from the category.
   animCurrent[0] = _anim[0,_index]; //set the front animation from the category, with the index we chose.
   animCurrent[1] = _anim[1,_index]; // set the rear version of the animation.

   if _time = -1 {_time = sprite_get_number(animCurrent[0]) * 4 } // *4 as sprite speed is 15 and room speed is 60.
   animTimer = _time;
   image_index=0; // start from the first frame.
   image_speed=1; // just in case...
   animCurrentPriority = _prio;
   }

The priority check happens so keep animations making 'sense'. for instance, if the enemy is moving, it'll probably be scripted to play a moving animation. But if it's also attacking, it'll also want to be playing an attacking animation. Obviously we want to show the attack more than just the enemy walking, so we give the attack a higher animation a higher priority than the move.


And in the step event, we basically just count down the animation timer. When it hits zero, we go back to idle:

//scr_sprite_animaton ======= (yes, it's actually misspelled. -_- I never noticed until just now. That's autofill for you.) ====================================================================

// processes animations.
// time out animation, and Reset to idle pose if other animations have timed out.

if image_index = sprite_get_number(animCurrent[0]) {image_speed=0}else{image_speed=1} // hold on the last frame if timer > animation length.. Not sure if this works, actucally, I haven't tested it.

if animTimer <= 0
   {
   animCurrent[0] = animIdle[0,0];
   animCurrent[1] = animIdle[1,0];
   animTimer = 60;
   animCurrentPriority = 0;
   image_speed = 1;
   }
else
   {
   animTimer--;  //count down animtimer.
   }

...and elsewhere the sprite_index is set to animCurrent[facingFB] before drawing.

IMPORTANT TO NOTE!!! The current system does NOT have mechanism for switching correctly between front and back sprites. (currently it'll jump back to frame 0 with every switch) That's another of the things I have to fix later, I just wanted to get the basics working before my time was up. -_- I think I may need to either find a way to preserve the image_index through sprite changes, or just make my own frame index variable. Haven't thought about it that much yet. : /

So that's it, pretty much.. hope it makes some sort of sense. I'm a self-taught programmer so I have no idea what best practice in most cases. Apologies if this made anyone cry. :/
But if you have any questions feel free to hit me in PM's.

edit: Just now remembered where I remember your name from. Your project is totally amazing. Best of luck!