Skip to main content

Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(2 edits)

Thank you for the praise and consideration ☺️

I hadn’t really thought fully through the combination… but yes, this is feasible, if not quite as flexible as each plugin separately. (You could combine these approaches, of course, also on the same sprite(s).)

I assume you use Pictures for example as Actor talk sprites in cutscenes, and may also have Actors that appear as Events while not in the party?
The latter isn’t supported all that well by Dynamic Characters directly, but a controller that combines them can use the broader Actor condition implementation from Dynamic Pictures and apply them to both…
I should be able to give you a choice on whether to apply a rule to all Characters or only the specified Actors in the party, so that you can still use combined Actor character spritesheets if your Actors don’t appear as Events.

I won’t have to do much testing or new UX design (for the plugin parameters) for this, so I can give you a rough ETA of two weeks. I can’t fully guarantee this estimate due to some life stuff I have going on, but at least from a technical point of view, I don’t expect any obstacles.

(+1)

Hey! Wow, thanks for the thorough response. There's no rush! I'm just waiting for payday to roll around. My game likely wont be finished this year or next, so take your time :D life comes first.

I am no coder yet (I can do a bit of JS when I need to, but large scripts still make my head spin, very much a novice tutorial-follower). The reason the combination sounded appealing to me is this: I have decided to try to drive myself insane by making a single-player life-simulator game. Only 1 main actor, the rest of the cast will be NPC Events that (with a handful of possible exceptions) don't need to change an awful lot through the game. I can do most of that within the vanilla engine. 

But for the main player, nearly every choice you make will change your character in some way, for good or bad.  Much will be subtle, but some consequences will be major and need visually representing. Mood/status, clothing, scars, tattoos, fat/thin, etc. So I was looking for a way to represent as many of these changes as possible both in the player map sprite and character portrait (which would be visible when talking and when you open the skills and stats menus). And that is how I stumbled upon your plugins =)

The idea is the game plays out over a set timespan of 10-20 in game years, but it can be replayed many times for many different outcomes. I want the gameplay to be as non-linear as possible. But obviously, keeping up with the sheer number of sprites needed for that amount of player choice without plugins is a path to madness. lol

I have no idea if I can achieve everything I want with your plugins, nor of course would I expect that, but it seemed the combination of the two would be the best "starting block" currently available for me to study and (try to) build off. 

(1 edit)

I think what you describe is fully supported. I’m still making it a little more versatile than that so it’s useful for many kinds of games, though. (It’s really not much effort at all.)

Rules can influence later rules through the tag system, so it’s pretty easy to set up variations of a rule. You likely will have to use one rule per variation, though, unless you extend the plugins, and if something is at once in front of and behind something else that will need two rules too.
It’s possible to hide the base layer and replace it with a different one, so weight changes and different poses shouldn’t be a problem.

The default character portrait drawn onto the message box and menu unfortunately isn’t affected by my plugins. (It’s not really a Sprite normally, which makes it difficult to work with.)
If you add a (modified) Sprite_Picture sourced from a Game_Picture to the Scene_Status, or to the window directly, that will be affected though! Here’s the one I use in Live Menu and Pause (for the pause screen Picture):

class Sprite_Pause extends Sprite_Picture {
	/** @override */
	initialize() {
		super.initialize(0);
	}

	/** @override */
	picture() {
		return pausePicture;
	}

	/** @override */
	updatePosition() {
		super.updatePosition();
		// Because I don't use the standard Picture container.
		// (See `Spriteset_Base.prototype.createPictures`.)
		this.x += Math.floor((Graphics.width - Graphics.boxWidth) / 2);
		this.y += Math.floor((Graphics.height - Graphics.boxHeight) / 2);
	}
}

pausePicture is just a standard new Game_Picture() that I called .show(…) on to set it up. In theory you can make that a constant in a plugin if there are no changing parameters. The load order doesn’t matter vs. mine, since I hook into the Sprite_Picture and Game_Picture prototypes without changing the instances.

(2 edits)

-whoops, self replied-

The combined-rules plugin is now available: Dynamic Actors

I admittedly gave you a safe estimate on when I’d get this done, but it also just turned out to be much less work than expected. I guess I can thank past-me for good API design 😅

Enjoy, and let me know if there are any problems or features you’d like to see added.

(+1)

Hey man! Thank you so much :). I picked everything up just now. Looking forward to having a play with it this week. 

Thank you for your purchase! Please let me know how it works for you, especially if there’s anything you think could be improved.