I'm not sure how to apply that to the problem I have. I have two objects with line-of-sight behavior (LOS1 and LOS2), and two objects with the solid attribute (S1 and S2). I want LOS1 to treat both S1 and S2 as obstacles, but I want LOS2 to treat only S2 as an obstacle.

I want to avoid using custom obstacles, leaving both line-of-sight behaviors on 'solid'. I want to put S1 and S2 on different layers and tell LOS2 to ignore S1 (perhaps to ignore the entire layer it's on).

The way I currently have it set up, S1 is not directly targeted at all. LOS1 and LOS2 are both targeting an object behind S1, so I'm not sure how to get LOS2 to ignore S1 or the layer it's on.

Is it possible to instruct an object to ignore all objects on a specific layer? Specifically, I want a line-of-sight behavior to ignore all solids on a layer different than its own.

Or, you could always do your own "cone of sight" routine.

Have a look at the image.

o = object with cone of sight

a = angle, to which o faces

c = the cone of sight

r = the radius of the cone

p = sample points within the cone

d = distance between points on r

g = distance between points on cone

All there is to do is creating a virtual cone, and sample only a small subsets of the possible points within the cone (for speed reasons).

c exists angular, centered around a. The radius is needed and should probably be the border of the visible screen of your game.

What you need:

- The height (r) of the cone in pixel => cH

- The width of the cone in degrees => cA

- The sample density along r => pH

- The sample density along the circumference of the cone => pV

The position of a sample on the virtual grid is

x = cos( (a - cA / 2) + loop_through_pV * (cA / pV) ) * loop_through_pH * (cH / pH)

y = sin( (a - cA / 2) + loop_through_pV * (cA / pV) ) * loop_through_pH * (cH / pH)

Then do whatever suits your needs at that sample point. In my example I did a collision-at-offset check.

Download coneofview.cap

Wow, this works really well, actually. I've been trying to replicate it from scratch, however, and can't. I'm just not math-savvy enough to do it intuitively. As such, I don't feel right including it in my programming, since this is meant for me to be able to alter at will. I'll definitely hold on to the example and do my best to familiarize myself with it, though. I appreciate you taking the time to put it together.

Try using "for each" above the LOS condition. That will allow it to work with multiple objects.

+ System: For each badguy

+ hero: Has LOS to badguy

Thanks! All this time, I've been giving objects private variables to replicate this. Functionally, is this any different from using private variables? For example, is

IF

Bullet on collision with Gunman

THEN

set Gunman.Value('Health') to 0

IF

Gunman.Value('Health') equal to 0

THEN

destroy Gunman

different from

IF

For each Gunman

Bullet on collision with Gunman

THEN

destroy Gunman

?

I'm trying to make line-of-sight work with multiple enemies. This is proving to be a tremendous pain in the ass. Where to begin?

This is my goal: I need the player character to see enemies within a cone of vision at indefinite range, blocked by solid obstacles. I need the enemies to see the player character likewise.

Okay, so, originally, I set LOS to the player sprite, and quickly realized it could only handle one target at a time. I then scrapped the LOS behavior and programmed a sprite, 'Beam', to set its position and angle to the player sprite and increase its length constantly, until it collided with a solid or enemy, at which point it would set its length to the distance between the player and the object.

In this manner, the Beam object acted as an impromptu LOS that could target multiple enemies. However, it was not a cone, so I could only see enemies immediately in front of my character. Even if I made the Beam object wider, it would still limit its size to the first object it collided with, essentially decreasing its accuracy (increasing the smallest gap it could see through). I tried to procedurally generate a conic spread of these objects, which worked...but killed the framerate.

I scrapped the Beam object and tried something different. I removed the player's LOS behavior and gave the enemies LOS behavior instead. I created a 'Compass' object, a long, thin sprite that was created when an enemy established LOS with the player. Compass set its position to the player but set its angle toward the enemy. The idea was to make the enemy visible to the player when the player sprite's angle matched the Compass' angle, give or take X degrees (X being the player's cone of vision, in degrees). This caused some thoroughly crazy issues, as the Compass objects refused to sync up with their proper enemies, even when identical private variables were assigned to help them identify each other. It was a mess, and ended up butchering the framerate as badly as the previous attempt. Back to the drawing board.

I scrapped the Compass system and went back to the LOS behavior. I created a C-shaped 'Cloak' sprite and made it solid. I set its position and angle to the player sprite, with the 'open' end of the C facing forward. Now the LOS for all enemies was blocked by the Cloak except when the player was facing the enemy, so that it could be seen through the open end. This effectively established the player's cone of vision. Now I just had to find a way to allow the enemies to target the player, regardless of which way the player was facing. I created a second object for each enemy, a 'Radar' sprite, which I also gave LOS behavior. I changed the LOS setting from 'solid' to 'custom' and told it to acknowledge only walls (but not the Cloak) as obstacles. This worked...but, again, killed the framerate after running for a few minutes. I'm not sure why custom LOS settings would do this, but they did.

But I was not about to give up so easily. I decided to create a ring-shaped sprite, 'Bubble', which would likewise follow the player sprite, but sit outside of the Cloak. This should allow the Radar objects to detect it without custom settings, right? Right? WRONG. The presence of the Cloak messes with their ability to detect the Bubble, even though it's sitting outside of the Cloak. I thought it might be an issue of LOS accuracy, so I increased the accuracy to 1 pixel. This only helped marginally; whereas before, the enemies would ignore the Bubble until the player sprite turned to face them, they now track the Bubble in very abrupt, choppy movements, unless the player sprite is facing them (in which case, they track smoothly).

In desperation, I scrapped the Cloak and Bubble objects and made a gigantic triangular sprite, 'Vision', large enough to cover the entire screen (the game does not scroll, so it only had to be large enough to cover 640x480). I set Vision's position and angle to the player sprite, allowing enemies to target the player with their regular LOS behavior and allowing the player to see them when they had LOS and Vision was overlapping them. This likewise worked...and, of course, kicked the sh*t out of the framerate.

These are the three final products of this God-forsaken endeavor. I can only hope there is something fundamental I'm overlooking that will solve this problem. I tried putting the Cloak on a different layer than the Radar sprites, but this didn't seem to work. I've never worked with multiple layers extensively, so there may be something I'm missing there. That's really the only direction I can see this going successfully, but I don't know enough to say.

Your thoughts?

Custom

mediafire.com

Bubble

mediafire.com

Vision

mediafire.com

I've been toying around with a one-on-one tactical RPG in Construct; I just finished the bare-bones character creation/combat engine. This is the most basic state in which it can be considered a game in its own right; with collaborators, I hope to use it as a basis for more fleshed-out projects. The mediafire link is for 3 MB .exe; all the instructions and details are included below. All feedback is appreciated.

http://www.mediafire.com/?npbqbqfh89b6gt0

Since the process is a bit overwhelming at first glance, here's a visual tutorial:

http://www.facebook.com/media/set/?set= ... c029174cbe

FLUFF

In most RPGs, intelligence barely factors into melee combat. I never thought much of this until I joined a few friends for Dagorhir skirmishes (kind of like what they did at the end of Role Models, except less elves shooting fireballs and more linebackers hitting you in the chest with a breakfast table covered in a light layer of gymnastics padding, passing for a shield). I learned a lot of things, but above all else: you simply can't be stupid on a battlefield, or you're going to die really fast.

To be fair, a lot of people died really fast in battles. That's the idea of large-scale warfare. However, nobody wants to be that guy with a handaxe sticking out of him. You want to be the one pulling it out of him and moving on to your next victim. You want to be the hero of the story. That, as it so happens, requires intelligence.

By intelligence, I don't mean the ability to calculate the arc of an opponent's swing or the chemical formula for bronze; I'm talking about intuition. You can practice all you want, but if you don't pay attention to the details and make subtle adjustments, it's difficult to truly progress. By honing your intuition through keen observation of yourself and your enemy, as well as the ability to see patterns in the unfamiliar and anticipate rather than rely solely on past experience, you gain a priceless edge over the opponent who has merely swung his mace a thousand times the same way, without thinking twice about it.

This RPG engine strives to capture that. Battles are won with single, calculated killing blows as readily as they are won with overwhelmingly powerful barrages; they are just as much about manuevering and anticipation as they are about damage per second and overall survivability. Death comes fast, and it comes unexpectedly; the more you think things through, the less chaotic it will be, and the greater your chances will be of walking away.

If there's any single inspiration for this system, it's the D&D 3.5 assassin; the idea of observing a character, then striking with overwhelming precision, was the perfect alternative to the you-hit-me-I-hit-you mentality that most players brought to the table. This entire engine is designed to showcase the tactical skills that make a 3.5 assassin a god among men.

SYSTEM

Players take turns attacking each other; in order to attack, your weapon's range must overlap your opponent's body.

When a character is attacked, it attempts to defend itself. This consumes stamina. Certain weapons deal more damage; this implies that they require significantly more effort to defend against.

When a character's stamina is reduced to or below zero, that character collapses from exhaustion and is, for all intents and purposes, dead.

Each weapon has a lethality rating; this is the weapon's chance of instantly killing an enemy. Lethality is expressed as a percentage. The 'kill' roll generates a number between 1 and 100; if this number is equal to or lower than your lethality, you score a kill...

...unless your opponent's armor blocks it. If you roll a killing blow, the 'null' roll generates another number between 1 and 100; if this number is equal to or less than your opponent's armor, it nullifies your kill and instead deals regular damage. Armor is measured as a percentage, just like lethality.

It is important to remember that armor does NOT protect against stamina damage, only lethality. In addition, armor lowers your movement range per turn by 1 step per 5 armor. Weapons likewise have a weight rating; each 'stone' of weight lowers speed by 1 step.

As an alternative to armor, characters may defend instead of attacking; this unconditionally nullifies lethality and reduces damage based on defense rating (the defense rating is subtracted directly from damage, so a 4-damage weapon attacking a defending opponent with a 3-defense weapon would only deal 1 damage). While this seems far superior to armor, keep in mind that a defending character can not attack on that turn.

It is possible to increase lethality, damage, speed, and defense in battle. First, we will look at damage and speed, and their governing stat, strength. A character can deal more damage than its weapon allows by exerting extra power; each extra point of damage costs 1 point of stamina. The character may gain a bonus to damage up to its strength stat, as long as it has the required stamina. In the same manner, a character can move further than its armor would normally allow, up to its strength stat, by paying 1 stamina per extra step.

Lethality and defense, tied to the intellect stat, function somewhat differently. Each turn, the character gains a cumulative 5% bonus to lethality, up to its intellect stat. For example, a character with 15 intellect would gain 5 lethality per turn for 3 turns, topping out at an additional 15% lethality. Every time an opponent attacks, the character gains its entire intellect stat as a bonus to lethality, potentially exceeding the cap. For example, the character with 15 intellect, which has stopped gaining 5 lethality per turn because it has already reached its 15% lethality bonus, would gain another 15% every time it was attacked. This quickly builds up; after sustaining just two attacks, the character is capable of formidable 45%-lethal attacks. Defense works much the same way, except that it does not increase passively, only when attacked.

Initiative is determined by rolling dice equal to the characters' speeds. The character that rolls the highest goes first. The intellect stat is automatically added as a bonus to the dice roll, and an additional bonus can be added based on strength by expending 1 stamina per point added, in the same manner as damage and movement.

INSTRUCTIONS

Click on the P1 or P2 icons, in the top left and right of the screen. You will see an arrow appear next to the icon you have selected. You have two sections to focus on; on the left hand, you can increase your character's stats and skills, and on the right, equip the character with gear.

You can select weapons to view their stats; damage, lethality, and defense appear below your character's stats, while the weapon's classification, reach, and weight appear below the equipment section. When selected, the weapon's weight will subtract from your speed, its reach will alter your character's battlefield icon (P1 is in the bottom left, P2 in the top right), and the skill text below the stat/skill buttons will go from lower-case to upper-case depending on the weapon's classifications. Armor, unlike weapons, can be selected multiple times; each click adds 5% to your armor, and lowers your speed accordingly.

It is important to make your final equipment selection before clicking the other icon; otherwise, the system counts the last weapon you selected as your final selection and thinks you're choosing another weapon to carry when you click back, adding to weight and reducing your speed further. Yes, it's a technical issue that could have been addressed. Alas, I am but a man. I'll get around to it. Also, you can not dual-wield gear at this point; regardless of whether it is a one-handed or two-handed weapon, all characters can wield only 1 weapon (this includes the shield). Inevitably, I'm going to get complaints about the shield not being a legitimate weapon, to which I say, "you've obviously never been hit in the chest by a linebacker wielding a breakfast table covered in a light layer of gymnastics padding...or stabbed in the face with a spiked targe...or punched with the edge of a bronze disc". The list goes on and on. Trust me, shields do some damage.

You have 20 experience points to spend on stats and skills; stats cost 1 point each, while skills cost 5 points each. A skill, once selected, will permanently grant you a bonus to weapons within its category, increasing their damage, lethality, and defense by 1 rank each (1 damage, 5% lethality, 1 defense). Skills you possess will have their buttons faded out. You can click the Level Up button indefinitely to gain 5 points of experience at a time, if you're in the mood to build more powerful characters.

Please be sure to make your selections in this order: weapon, armor, stats. If you select the weapon after the armor or stats, the game sometimes goes crazy and adds far too much weight; I'm not sure why. Obviously, I did something wrong, but now you're paying for it by having to build your character in that particular order. Worse fates can befall a man.

Once you've got both characters built, take note of their speed and intellect stats; these will combine to determine initiative. If you feel that yours is lacking, you can click the + button below the Initiative text on your character's side (at the top of the screen, near your character icon) to add a bonus at the expense of stamina, as discussed in the System section. Don't worry about your skills being applied to your weapon's stats; once you click the combat icon, the changes will automatically be applied. You'll notice that when you select combat, one of the characters is selected randomly. Both initiatives are rolled, and the character with the higher initiative (or a random character, if both initiatives are equal) is chosen. Click on that character's icon to begin combat.

You'll notice once you click on a character that its lethality goes up; as described in the System section, it will do so at the start of every turn, up to the character's intellect stat. When selected, your relevant stats will be transferred to the combat stats section in the top middle of the screen, below the Attack and Defend buttons. You will notice that your damage and speed can be boosted; the number between them is your total available bonus, based on your strength and available stamina. However, you can not attack yet; you must first make contact with the opponent. To do so, right-click anywhere on the battlefield and your character will move to that spot; if you come up a bit short, feel free to boost movement (at the expense of stamina, of course) as necessary. Once you make contact, you may attack. Note that it is not necessary to be in range when you actually click the attack button; you can simply overlap the opponent to activate attack, then finish your movement and perform the attack. Alternately, you may defend at any time during your turn, regardless of whether or not you have made contact with the opponent. You are not obligated to attack your opponent; you may end the turn at any time by clicking on your opponent's icon.

It is possible to overlap the enemy, attack, then retreat and advance to re-enable the attack button. This allows for some rather unforgiving one-turn kills, so it is not recommended until you are skilled/bored with the regular one-attack-per-turn method. While it certainly does a better job of representing speed by allowing it to govern both movement range and rate of attack, it makes berserkers and assassins (more on this below, in Builds) terrifyingly effective. If you're a big fan of ninjas and Gothic barbarians over samurai and legionnaires, feel free to try it out.

There are 4 text boxes to the right of the combat stats: KO, Kill, Null, and Hit. These light up depending on the result of your attack, so you don't have to wade through the sea of numbers to make sense of what happened. KO implies that your HP was reduced to or below zero by sheer damage. Kill implies that your HP was reduced to zero by a lethal blow. Null implies that you rolled a lethal blow, but your opponent's armor blocked it, thus dealing normal damage (but not enough damage to KO the opponent). Finally, Hit means you dealt damage, but did not roll a lethal blow.

BUILDS

Two fighting styles predominantly arise: the duelist and the berserker. The duelist utilizes high stamina and intellect to defend and learn its enemy, building up lethality and defense per attack and retaliating with, ideally, one incredibly lethal finishing blow. By defending, the duelist is protected against lethality, but will require some stamina to take the initial blows necessary to build up the power of its own attack. The berserker is the opposite; instead of relying on lethality, it focuses on overwhelming power to utterly crush its opponent in a few swift attacks. The berserker focuses almost solely on speed and strength, using its ample reserves of stamina to gain large boosts to both damage and movement range. Its goal is to close the gap and incapacitate the opponent in as few attacks as possible.

Two alternate fighting styles, more challenging than the duelist and berserker, also share the battlefield: the assassin and linefighter. The assassin is similar to the berserker; highly mobile, and focused on offense. However, the assassin focuses on lethality instead of damage, using a high intellect to passively gain lethality and a high speed to evade the enemy until it has built up enough to rush in for the killing blow. The linefighter functions more like the duelist, but strives to finish its enemies with knockouts. Instead of expending a great deal of stamina to deliver higher damage, the linefighter constantly defends and uses high-defense weapons coupled with superb stamina to effortlessly mitigate enemy damage. Its goal is to goad the enemy into exhausting itself with powered-up attacks, then finishing the winded opponent with a series of damaging blows.

YOU READ ALL THAT?!

So that's pretty much it. Keep going until someone dies. There's no reset button, so if you screw something up during character creation, or when you're ready to restart, you will have to restart the application. Sorry; I'll get around to it.

Anyway, let me know what you think; I'm looking for help turning this into a skirmish (roughly 5-on-5 or thereabouts), which requires programming I am not readily capable of. I'm also looking for artists to help overlay an isometric 3/4 top-down interface. For now, this is just a fun sandbox; eventually, it will become an RPG with a storyline, kick off a 10-sequel series with a dozen spin-offs, and I'll be swimming through pools of gold coins like Scrooge McDuck. Until then, thanks for your time; enjoy.

edit: changed the file to an updated version that addresses a minor issue with multiple attacks per turn.

Use the function object for repetetive events/actions.

For example, instead of your globals you could setup a function

+ On function "AttackConditions"
++ Player.Value('Reserve') greater than 0
   global('Distance') less than 2
-> Set return value to "True"
++ Else
-> Set return value to "False"
[/code:2voamfet]
Call that function on key press:

[code:2voamfet]+ key A pressed
++ Function.AttackConditions equal to "True"
-> set player animation to "Attack"
-> substract 1 from Player.Value('Reserve')[/code:2voamfet]

The advantage is that you only check the function in your main events. You can group your functions or place them in their own event sheet, and, more important, you can easily change a function or add other code to it etc., without touching the main events.

This makes it easily maintainable. (and btw saves you a lot of globals  )

THANK YOU! This is exactly what I was hoping for. I will now proceed to gut the entire stack-controlled system and reorganize it. If I can reduce the lines of code by half, I'm treating myself to one of those fancy $4 frozen dinners tonight.

This isn't specifically Construct-related, but since I'm using Construct to learn programming and only truly understand it through Construct's interface, I felt that this is an appropriate enough place to ask. Please bear with me if I use some odd or unconventional terms; I have no formal programming education, so I'm improvising a lot of this as I go. Hopefully, it's intuitive enough that you'll understand the gist of it. If not, please ask and I will gladly clarify.

I'm programming a somewhat complex RPG engine that relies on a lot of conditions, sometimes 3 or 4 layers deep. For the initial version of the engine, which can be found here http://www.scirra.com/forum/viewtopic.php?f=4&t=8405&p=64076#p64076, I used what I call a 'disable-controlled' coding method. Instead of programming it so that certain actions were restricted under certain conditions, I left the actions alone and simply disabled the buttons that controlled those actions. So a typical chunk of code looked like this:

On Player.Value('Reserve') equal to 0: disable button 'Attack'

On global('Distance') greater than 1: disable button 'Attack'

On button 'Attack' clicked..set Player animation to "Attack"

.................................subtract 1 from Player.Value('Reserve')

This worked fine until I switched from buttons to keys for faster, more intuitive command inputs. Since I couldn't disable individual keys, I had to restrict individual attacks. I had to reorganize the code into what I termed a 'stack-controlled' coding method. Here, the input methods were not disabled; instead, the commands themselves would only work under certain conditions. The same chunk of code above looked like this:

On Player.Value('Reserve') greater than 0

On global('Distance') less than 2

On key A pressed..set Player animation to "Attack"

..........................subtract 1 from Player.Value('Reserve')

At face value, this felt cleaner and more organized, but the sheer number of conditions made it unmanageable. All in all, the conditions were: Player.Value('Reserve') greater than 0, global('Distance') less than 2, global('Turn') equal to "Player 1", and Player.Value('Action') equal to _(1-4). This does not include special attacks, with effects such as staggering the opponent, which had to trigger a dice roll to determine success. It was an inefficient mess. Each extra condition exponentially increased the size of the stack, since it had to be added to every existing condition, rather than having its own section, as with the 'disable-controlled' coding method. The sheer scale quickly exceeded my practical capabilities. I am currently trying to minimize the amount of 'stacking' necessary by implementing a hybrid disable/stack coding method I have dubbed 'variable-controlled'. I'm doing so by allocating as many conditions as possible to variables that function like on/off switches, so that less conditions have to be programmed into the stack. The above code looks like this:

On Player.Value('Reserve') equal to 0: set global('Attack Monitor') to "NEGATIVE"

On global('Distance') greater than 1: set global('Attack Monitor') to "NEGATIVE"

On global('Attack Monitor') equal to "POSITIVE"

On key A pressed..set Player animation to "Attack"

.........................subtract 1 from Player.Value('Reserve')

I'm just starting to pick apart the massive redundant stacks and convert as many of the conditions into on/off variables as possible. I'm not sure how much I can salvage; I might be better off rebuilding the system from scratch. My goal is to build a system that allows for fast, uncluttered customization. For that reason, the stack has to be minimized, or adding even single conditions will take cripplingly long. My question is this: how could I further streamline my system toward this purpose?

[quote:3cg83rrr]In case of a Double/Double combo, it is possible to see both occur, if one stagger connects and the other does not. This is a minor interface issue that does not affect the functionality of the engine, and will be remedied soon.

Better known as:

"Critical Attack"

I suppose you could call it a critical attack...though I'd think a Triple or Quadruple would be more along the lines of a critical, whereas a Double would be a cancel or interrupt. I tried to avoid using such terminology because so few of the attacks actually deal damage, as they would in a normal combat engine.

General Tactics

Ninja always strike first, but samurai always strike last. In other words, ninja have initiative, but samurai are allowed one final attack, even if their stamina has been depleted. This makes it very difficult for a ninja to defeat a samurai and make a clean escape. The only safe way to prevent the samurai from landing a final blow is to attack and then step out of range (the extra point required to step out of range means you must finish the samurai with a weak attack, and even then, the samurai can attempt to pursue you). In short, being a ninja is difficult; they must escape in order to succeed, whereas samurai must simply defeat their opponent, regardless of what happens to them.

Paying for an action point is a risky choice; by doing so, you've given your opponent two actions on his upcoming turn. If he chooses to likewise pay, he'll end up with three actions and be able to attack you with a Triple attack, potentially knocking you out. There are several ways to deal with this:

1) Just don't pay; it's tempting, but it could cost you. Instead, prepay and be patient.

2) Pay and use a Double attack; you have a 50% chance of taking back the point you granted your opponent. You essentially dealt an extra point of stamina damage for free.

3) Pay and retreat; your opponent will have to waste an action point closing the gap. This usually leaves them with too few points for a Triple attack.

4) Pay and Triple attack; if your opponent paid and gave you a free action point, make him/her regret it! This is risky, as failing to knock them out means they can try the same.

Prepaying is a great way to deter an enemy. If you already have two points for your upcoming turn, they will hesitate to pay, as this will allow you to start your upcoming turn with a whopping three action points. This is enough to attempt a Triple attack without paying, or any other potent three-point combination. If you're feeling particularly bold or aggressive, you can choose to pay, granting you the fearsome four-point turn.

The Quadruple attack is a force to be reckoned with, as are the other actions you can take with four action points at your disposal. The only way it happens is if you prepay, your opponent pays, and then you pay (each of these grants one action point, a total of three additional points). A four-point turn for either player usually ends the match, as the options available are simply overpowering. Luckily, it can only happen if the opponent allows it.

So why would the opponent allow it? Usually for one of two reasons:

1) He/she is stupid; remedy this immediately with a righteous four-point beatdown.

2) He/she has good reason to believe that the match can end on the current turn, usually by paying and attempting a Triple attack (or a combo that can knock you out from sheer stamina damage). He/she may also be aiming to deplete your upcoming action points with an attempted Double attack.

Use movement to pressure and frustrate your opponent. Samurai can close the gap to zero steps, making ninja apprehensive, whereas ninja can open the gap far wider than two steps, causing impatient samurai to charge in while the ninja prepays and waits. It is always easier to avoid attacks than to land them; avoiding attacks is a simple matter of retreating, whereas landing them involves advancing and attacking. For the same number of points, a character can avoid attacks indefinitely.

This is the Duel Engine, a simple RPG combat engine. This basic version of the engine pits a ninja against a samurai, and is functionally complete as a DM tool. The instructions are in-game, and the rules are presented below; don't worry, it's nowhere near as complicated as it seems. Please let me know what y'all think. Thanks in advance!

http://www.mediafire.com/?7hoz1e2r2e5t9gz

Rules: Players take turns attacking, and defend against attacks automatically. Each player has twenty points of stamina. When attacked, players consume stamina by defending themselves; the amount of stamina consumed depends on the attack. When a player's stamina is depleted, the player collapses from exhaustion and loses the match. Each turn grants the player one action point; it is possible to accrue additional action points and use them on a single turn. The methods for doing so, as well as the actions they can be spent on, are in-game.

For those wondering about the logic behind attack damage, the formula is:

Sum Of Attack Damage * Sum Of Attacks

So a 1/2 combo would deal 1+2 damage * 2 attacks for a total of 6, whereas a 1/1/1 combo would deal 1+1+1 damage * 3 attacks for a total of 9, and so on. Generally, the more attacks you use, the more stamina damage you'll deal against your opponent. The more costly attacks have effects to make up for the lower stamina damage per action point.

Please note that there are two minor issues with failing to stagger an opponent (more on that below). If, upon performing a Double attack, the opponent's action points do not reduce by one, and instead, something briefly flashes above the opponent's portrait, this signifies that your attack failed to stagger the opponent. In case of a Double/Double combo, it is possible to see both occur, if one stagger connects and the other does not. This is a minor interface issue that does not affect the functionality of the engine, and will be remedied soon.

Edit: updated the engine to include most of the instructions/explanations in-game. This should make it a lot more accessible. Please let me know if it helps.

Great idea! I love the concept, especially if you start working with some different mechanics along the levels (like clicking in things, objects that can be passed trough, etc) Though I agree the welcome screen is too difficult, and i feel the ball is to fast too.

Great job!

Thanks! I've amended the welcome screen from size 36 font to size 60, and I feel it's a lot more manageable now. The ball's acceleration has been toned down a bit (10 pixels/sec initial speed, 850 pixels/sec/sec acceleration to a top speed of 850 pixels/sec), which makes it easier to work with, but I feel the real issue is keeping the ball from getting stuck. I figure I'll tell it to ignore the cursor and apply normal ball physics if the ball tries to go in the same direction (whatever that means; I'll have to tool around with it) twice in a row (such as if your cursor is on one side of a solid and the ball is on the other, causing it to snag).

The environments will be full of interactive elements, and even a few hazards. Many of them will be maps, on which you can click to access new areas you discover (for example, you can click on a house after bumping into it, allowing you to enter the house). Others will be elaborate artwork (murals, collages, and the like), and a select few will even be animated (such as a model of the solar system or a pair of combatants engaged in a duel, infinitely looping). Once I find a reasonable solution to the snagging issue, I'll assemble all the different level types with placeholder graphics and put 'em up.

Thanks again!