Hey, fixed the targeting on my towers so they don't hog targets that they can't hit yet(stupid charge laser tower) and added splash damage to missiles and got a new stream follower while developing and even still got in a good 20 minutes on the exercise bike!
And most importantly, I've still got plenty of time to leave to make it to class on time.
Today is a good day so far.
Though it did become increasingly obvious to me that while having the base Enemy class handle damage when hit by a projectile or when hitting the shields or base(or now also splash damage) made sense at first, it's starting to be a very strange way of doing things. Especially since the laser towers also work in a dumb way where they deal damage and also check to see if the enemy is at =<0 health, and if they do they call the Enemy's function to explode and die. Bullets and missiles could probably do the same thing if I wanted, and would make it so I don't have some weird massive switch statement in the Enemy class.
Khavall on
+1
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Pretty basic Unreal question for you guys:
I have a character BP I'm putting together based loosely on the SideScrollerCharacter from the SIdeScroller template. I'm using a character from the asset store that came setup with a ThirdPersonBP, but I don't want full third person movement, I want simple two plane movement. I have this working, it's fine...but my character will not face the direction of movement...while the SideScrollerCharacter does...but I can't find the difference between my character BP and the SideScrollerCharacter. Clearly something in that BP, or it's animation BP, is not set to force facing direction of movement...but I'm completely missing it. So my guy is animating correctly, jump and running, he's just always facing one direction regardless of movement (and yes, I'm using physics based movement).
Hey, fixed the targeting on my towers so they don't hog targets that they can't hit yet(stupid charge laser tower) and added splash damage to missiles and got a new stream follower while developing and even still got in a good 20 minutes on the exercise bike!
And most importantly, I've still got plenty of time to leave to make it to class on time.
Today is a good day so far.
Though it did become increasingly obvious to me that while having the base Enemy class handle damage when hit by a projectile or when hitting the shields or base(or now also splash damage) made sense at first, it's starting to be a very strange way of doing things. Especially since the laser towers also work in a dumb way where they deal damage and also check to see if the enemy is at =<0 health, and if they do they call the Enemy's function to explode and die. Bullets and missiles could probably do the same thing if I wanted, and would make it so I don't have some weird massive switch statement in the Enemy class.
Wait, why is handling damage in the enemy class a strange way of doing things? If you're using a component based engine you're probably better off handling health in a separate health/stats component, but either way having a single, universal TakeDamage() method that deducts the health and checks to see if the enemy should die is way simpler than having to separately implement the logic for killing an enemy for every single source of damage.
I have a character BP I'm putting together based loosely on the SideScrollerCharacter from the SIdeScroller template. I'm using a character from the asset store that came setup with a ThirdPersonBP, but I don't want full third person movement, I want simple two plane movement. I have this working, it's fine...but my character will not face the direction of movement...while the SideScrollerCharacter does...but I can't find the difference between my character BP and the SideScrollerCharacter. Clearly something in that BP, or it's animation BP, is not set to force facing direction of movement...but I'm completely missing it. So my guy is animating correctly, jump and running, he's just always facing one direction regardless of movement (and yes, I'm using physics based movement).
Anyone know what I might be missing?
Not sure what you mean by physics based movement, but does your character's MovementComponent have "Orient Rotation to Movement" set true?
Hey, fixed the targeting on my towers so they don't hog targets that they can't hit yet(stupid charge laser tower) and added splash damage to missiles and got a new stream follower while developing and even still got in a good 20 minutes on the exercise bike!
And most importantly, I've still got plenty of time to leave to make it to class on time.
Today is a good day so far.
Though it did become increasingly obvious to me that while having the base Enemy class handle damage when hit by a projectile or when hitting the shields or base(or now also splash damage) made sense at first, it's starting to be a very strange way of doing things. Especially since the laser towers also work in a dumb way where they deal damage and also check to see if the enemy is at =<0 health, and if they do they call the Enemy's function to explode and die. Bullets and missiles could probably do the same thing if I wanted, and would make it so I don't have some weird massive switch statement in the Enemy class.
Wait, why is handling damage in the enemy class a strange way of doing things? If you're using a component based engine you're probably better off handling health in a separate health/stats component, but either way having a single, universal TakeDamage() method that deducts the health and checks to see if the enemy should die is way simpler than having to separately implement the logic for killing an enemy for every single source of damage.
The reason it's weird is that it only handles when it hits something or when something hits it.
Except that the laser weapons, which are, like, half the weapons in the game, just use a line-renderer and deal damage directly
So the problem is less that the enemy handles itself taking damage, and more that the enemy handles itself taking damage except sometimes it doesn't?
And I feel like it should probably be more consistent.
Also the enemy grabs the damage from the thing hitting it, so it was built with a switch statement to figure out what was hitting it.
What I will probably end up re-doing is making the enemy have a single TakeDamage(float damage) function on the parent Enemy class, and the towers and projectiles will call that function when they hit it with their damage. That way the enemy is still handling it's own health from sources, but each source will deal with the enemy in the same way.
Edit: Well, now what I did was exactly that. It makes everything much clearer now.
Khavall on
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I have a character BP I'm putting together based loosely on the SideScrollerCharacter from the SIdeScroller template. I'm using a character from the asset store that came setup with a ThirdPersonBP, but I don't want full third person movement, I want simple two plane movement. I have this working, it's fine...but my character will not face the direction of movement...while the SideScrollerCharacter does...but I can't find the difference between my character BP and the SideScrollerCharacter. Clearly something in that BP, or it's animation BP, is not set to force facing direction of movement...but I'm completely missing it. So my guy is animating correctly, jump and running, he's just always facing one direction regardless of movement (and yes, I'm using physics based movement).
Anyone know what I might be missing?
Not sure what you mean by physics based movement, but does your character's MovementComponent have "Orient Rotation to Movement" set true?
This is almost certainly what it is. I'll check when I get home.
What I will probably end up re-doing is making the enemy have a single TakeDamage(float damage) function on the parent Enemy class, and the towers and projectiles will call that function when they hit it with their damage. That way the enemy is still handling it's own health from sources, but each source will deal with the enemy in the same way.
This is what I was advocating for. It's kind of hard to parse, but are you saying that instead of having damage sources tell the enemy how much hp to deduct, you were hard coding all the values into the enemy class itself? Because if so, yeah, that would quickly become unsustainable.
So after months of prototyping and finding out all ideas are crap in practice I think I finally have a prototype I want to develop and take to market. My goal is going to be lock down the gameplay / levels and then recode the thing and add graphics and sound. Final version is most likely going to be in Unity (like the prototype) and I am going to target iOS first and Android later / possible never.
Anyone have any general advice in this area? How long has this taken people with their own project?
What I will probably end up re-doing is making the enemy have a single TakeDamage(float damage) function on the parent Enemy class, and the towers and projectiles will call that function when they hit it with their damage. That way the enemy is still handling it's own health from sources, but each source will deal with the enemy in the same way.
This is what I was advocating for. It's kind of hard to parse, but are you saying that instead of having damage sources tell the enemy how much hp to deduct, you were hard coding all the values into the enemy class itself? Because if so, yeah, that would quickly become unsustainable.
It was.... really unwieldy.
Long story spoiler
It started out making sense because I had only the platforms and no towers, so I had the Enemies damage the platforms that they hit and then kill themselves.
Then I had only made one type of tower, and it fired bullets. I knew I wanted it to be upgradable, so the bullets had a damage stat that was passed to them by the tower. When the enemy had an OnCollisionEnter(), they would access the bullets damage from the bullets script, deal that damage to themselves, and then check to see if they died. That way they could use the fact that the enemies were doing the collision detection stuff to keep things simple.
But then I ended up adding a missile, which used the same idea, but had a different movement script, and they weren't part of a 'projectile' parent script or anything, because really the only thing they shared was "Does damage on hit", and the missile doesn't even respond the same when it hits a thing(it explodes, and later I added a splash damage thing to its explosion). So then it started to make sense to deal with a switch statement for the tag of the thing that hit it, but then running the same code to take the damage and check to see if it was time to die. It was a little sketchy of a way to accomplish the end, but it worked and I had already set up most of the behaviour.
So basically the Enemy would OnCollisionEnter check the tag of the collision, and based on what it was, it would access the script of the object, check the damage variable, deduct that from its health, destroy the other object, and if health was <=0, destroy itself.
And then I went on a 2-week vacation...
And then I made the laser tower and the charge-laser tower, and the laser tower deals continuous damage each frame and doesn't fire a projectile. And the charge laser was just destroying them on firing, but with a low fire-rate. So those two had to access the enemy health and change it, and then check to see if it was 0 and destroy it if it was. And then I made a shield that didn't get destroyed on contact, but instead have a health pool and can be deactivated and reactivated by another tower. So that was another switch case.
So I ended up with like 4 different interactions with the Enemies and one of them involved a big ol' unnecessary switch statement. And a bunch of variables were needlessly global and passed around. It all just sort of sprouted from quick ways to accomplish what I needed at the time, and I was really just interested in getting something working before my schedule started to get crazy, but it quickly became really dumb. It worked, and now I've created the 5 main tower types so I could've just left it as it is, but it was really dumb and confusing to look at.
Now everything just interacts with the Enemy's parent class with the TakeDamage(d) function when it damages any Enemy object. I could still clean it up a bit I guess by maybe making a projectile damage script and putting that on the bullets and missiles instead of having the same 4 lines in both movement/targeting scripts, but that's so very minor compared to the mess that had accumulated before. Also I don't even know if it would work/be worth it because the missile does another function when it hits something.
I'm writing a Twitch chat bot in Unity (because I'm crazy) and want to be able to control it without the controls showing up on stream. (also PLUG I'm streaming the bot dev usually saturday mornings US East time)
The problem is that it appears that Unity doesn't seem to have the ability for an application to create multiple independent windows.
I have an idea for a solution that is a bit cumbersome.
Create a separate application (either in Unity or with another language/ide) and have it communicate with the bot via text files.
So my application would write a command to a text file and wait. The bot would read it, do its thing, and send the output to another file. The "controller" application that wouldn't be seen in the stream would read the output file and display the results.
A more "streamlined" solution would be to create a Unity application and have it communicate with the bot via Unity networking but that would be more work since I've never done it before.
Does anyone have any other ideas?
So ideally you want the controller and the visualization to be on the same machine or it being networked one of the requirements? Why do the controls require visibility at all?
Maybe Unity isn't the best tool for the job? I know LibGDX just added multi window support.
Rampant speculation on my part without knowing more details.
I'm almost positive Unity isn't the best tool for the job. But its the dev environment I know the best and have been working with for the last ~4 years. So it is the square peg I'm going to use regardless of the properties of the hole.
Right now I'm looking to run the controller and the visualization on the same machine because the overlay is being added to OBS as a window view. In an ideal world I could set it up so that I had one system dedicated to rendering the game, one system for streaming, and maybe a tablet UI for controlling the bot. But that is pretty far away.
The whole project is fairly crazy but I'm having fun still.
I haven't used gamemaker in forever but I recall using a really ghetto method to make more complicated data types. I instantiated gameobjects with the scripts and properties I wanted, then referenced them as needed. Shouldn't affect performance unless you have gillions of them
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I have a character BP I'm putting together based loosely on the SideScrollerCharacter from the SIdeScroller template. I'm using a character from the asset store that came setup with a ThirdPersonBP, but I don't want full third person movement, I want simple two plane movement. I have this working, it's fine...but my character will not face the direction of movement...while the SideScrollerCharacter does...but I can't find the difference between my character BP and the SideScrollerCharacter. Clearly something in that BP, or it's animation BP, is not set to force facing direction of movement...but I'm completely missing it. So my guy is animating correctly, jump and running, he's just always facing one direction regardless of movement (and yes, I'm using physics based movement).
Anyone know what I might be missing?
Not sure what you mean by physics based movement, but does your character's MovementComponent have "Orient Rotation to Movement" set true?
This is almost certainly what it is. I'll check when I get home.
@LaCabra So it was this, and a couple of other things...but I now actually understand the SideScrollerCharacter, rather than just using it, which was the entire point
Now it's not just 4 towers sitting there shooting stuff.
Now it's up to 8 towers sitting there shooting stuff! And the user controls where they are and which ones(up to a maximum of 2 of each type for reasons the will totally make sense once the actual audio stuff goes in)
Next step is probably currency, and then I should probably start in on the whole music engine thing.
EDIT: Ooh upgrades! I still can code upgrades before I have to actually get to the real work
Just watched this video with some pro level designers. They're playing through some Doom levels while talking about level design, making Doom, and other cool industry stuff.
It got me thinking about what you've been saying @LaCabra about how current level design tools are awful and time consuming. From the video, after LeBreton talks about how with Bioshock the levels look great but take an incredible amount of time to make, he says:
Whereas with Doom, a level designer really can lay out an entire level in a day. You know, you can rough this thing out and spend another few days making the lighting and scripting work well.
When you have one person's creative intent represented so dramatically in a given level, something special happens. Something that I've been trying to get back to for a very long time in my career.
screen shake should not just shake the ui but the player in real life
Always make any shake or headbob toggleable. I hate headbob in most game and want it off off off off kill it with fire. My girlfriend never finished portal 2 because the shaking at the end made her motion sick.
Morninglord on
(PSN: Morninglord) (Steam: Morninglord) (WiiU: Morninglord22) I like to record and toss up a lot of random gaming videos here.
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I'm not even sure what point that guy is trying to make. That when games were not even real 3D, and could be laid out using simple one level BSP's with single textures, the tools were easier? Well no kidding. Not really a revelation.
Go watch Epic's presentation about how they actually build levels for things. It's eye opening and shows you how they do some of the very things people were doing in Doom, while leaving themselves the space to come back and fill in the play space with all the pretty. For instance, the way they tend to take the initial prototype level geometry and turn it in to the bounding volumes for the level, that all the fancy geometry lives inside of.
Hmm. Someone light the @LaCabra signal. My understanding has been that when it comes to level creation tools, we're a ways backwards from where we've been. Doom is NOT the pinnacle of level design tools. But current solutions, like what you find with Unreal Engine 4 and Unity, pale in comparison to the productivity you could get out of Source.
LaCabra has been campaigning about this for a wile:
I'm not even sure what point that guy is trying to make. That when games were not even real 3D, and could be laid out using simple one level BSP's with single textures, the tools were easier? Well no kidding. Not really a revelation.
Go watch Epic's presentation about how they actually build levels for things. It's eye opening and shows you how they do some of the very things people were doing in Doom, while leaving themselves the space to come back and fill in the play space with all the pretty. For instance, the way they tend to take the initial prototype level geometry and turn it in to the bounding volumes for the level, that all the fancy geometry lives inside of.
his point was the speed and ease of it meant the level designers unique taste could be expressed more coherently and more directly
its an artistic point, not a technical one
Morninglord on
(PSN: Morninglord) (Steam: Morninglord) (WiiU: Morninglord22) I like to record and toss up a lot of random gaming videos here.
+2
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited January 2016
It still seems like a very strange comparison to me. Comparing this very simple thing that you could do very simple things in and going "it was simple to use", to a very complex thing and going "this is so complex to use".
That said, I'm not an artist, I'm a programmer...so take my raised eye brows at the entire subject with a grain of salt.
I actually just did a consulting job with unity on how they can improve their level design tools (well, add some) and help get back to the point where level designers can actually do level design again
It still seems like a very strange comparison to me. Comparing this very simple thing that you could do very simple things in and going "it was simple to use", to a very complex thing and going "this is so complex to use".
Yeah you've got the wrong end of the stick. It's not comparing a simple thing to a complex thing, it's saying "a simple task exists. it used to be very simple to do, and now doing the exact same thing is complex and slow". Like, as an example making Doom's E1M1 in Unity or Unreal, to the exact same standard of complexity and fidelity, will take you a lot longer than in Source. It's a matter of having good level design tools versus not having good level design tools - the brief never changed, people just stopped following it
In what format do sprite-based games usually save animation sequences? I'm currently doing the following:
A struct holds the name of the sprite sheet to read from, the dimensions of a given sprite, an array of integers where each element encodes frame information (see below), and a pointer to the animation struct the program should read after it finishes with this one if it hasn't been assigned another struct to execute next.
An animated entity consists of a set of coordinates, a pointer to an animation struct and an integer animation index. When an animated entity is loaded it is assigned an animation struct and its index is set to 0. Each element of the array in the animation struct is read in the following fashion: an integer equal to or less than 1000 is read as "render the Nth sprite on the sheet then increase the index by 1". An integer above 1000 is read as "render the sprite located at i-1 for N-1000 milliseconds before advancing the index". Each loop the program goes over each entity and renders the frame its index corresponds to in its animation struct. Changing a sequence mid-animation is as simple as assigning the entity's pointer another struct and changing the index to the desired value.
Grey Paladin on
"All men dream, but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity; but the dreamers of the day are dangerous men, for they may act their dream with open eyes to make it possible." - T.E. Lawrence
Has anyone ever come across a resource or examples of how to design a good combat system for an RPG?
I'm talking about all the interplay between attack, defense, accuracy, speed etc. How to make the math work well, not be too unbalanced, and also how to make it interesting.
I could look at some breakdowns of how other games do it, in fact I know I've seen some formulas in the past on various wikis, like various Final Fantasy combat systems, or Pokemon's. I'm just curious if there's a good book or article out there that goes through the design process, how to tackle it in different ways. One with few stats, one with lots of derived stats, that sort of thing.
It just seems like the more obvious starting points could lead to problems down the line. Like, total damage is attacker's attack minus defender's defense, if less than 1 then damage = 1. That kind of thing seems awful, you probably want to scale things better, but I don't know the best way to do so.
It's not really a manual so much, but you could always start by looking at something like D&D for that stuff, which has several different iterations of a system where the math is super publicly available.
For instance, in D&D the basic way to calculate the attack is:
given toHit, damageBonus, weaponDamage, and enemyDefense as ints:
It's a pretty simple way to calculate that sort of thing, but it gives you scalability(lower-level enemies can have lower defense, and higher level characters will have higher toHit, so the chance approaches 100%), and has a bit of randomness to add in the joy of making and missing clutch moments.
There might be other manuals or discussions, but D&Ds great because it's so transparent about how it works, and you can see iterations through the years while they try to clean up the algorithms.(for instance, there was that time where the algorithm was, like)
int toHit, armourClass, weaponDamage, damageBonus;
if(Random.Range(0-20)>=toHit-armourClass){damageDone = (Random.Range(1,weaponDamage) + damageBonus)}
Which works exactly the same eventually, but involves this weird other thing where your toHit and armourClass are the opposite of what you'd expect, and you actually want a low toHit and AC. And the armourClass could then go into the negatives which was super good but super confusing.
Yeah, I've got a lot of experience with that system. I've also seen some pretty good math breakdowns on it, like what does a +1 sword really do for you over that basic sword, how the 0-20 system puts everything in 5% steps and such.
I'd just like to see...I dunno, more examination of different ways to do it, upsides and downsides. I don't want to just steal someone else's system, and I want to make something extensible with plenty of ways to modify what's going on.
Has anyone ever come across a resource or examples of how to design a good combat system for an RPG?
I'm talking about all the interplay between attack, defense, accuracy, speed etc. How to make the math work well, not be too unbalanced, and also how to make it interesting.
I could look at some breakdowns of how other games do it, in fact I know I've seen some formulas in the past on various wikis, like various Final Fantasy combat systems, or Pokemon's. I'm just curious if there's a good book or article out there that goes through the design process, how to tackle it in different ways. One with few stats, one with lots of derived stats, that sort of thing.
It just seems like the more obvious starting points could lead to problems down the line. Like, total damage is attacker's attack minus defender's defense, if less than 1 then damage = 1. That kind of thing seems awful, you probably want to scale things better, but I don't know the best way to do so.
I feel that you are asking the wrong question. When designing a game you set a goal and then try to achieve that goal. The various parameters are there to help you reach a certain end result.
Find out what is it that your game is trying to do and the numbers will fall into place.
Grey Paladin on
"All men dream, but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity; but the dreamers of the day are dangerous men, for they may act their dream with open eyes to make it possible." - T.E. Lawrence
I scoured the internet for a while last night and found this blog which is more or less what I was looking for, or at least a starting point. It's tangential to the actual systems that get put in place but it's good info to know when it comes to designing those systems.
For example, part 2 goes into the combat system of Dragon Warrior and examining the numeric relationships between all the various parts, how everything ties back into HP as a primary resource.
I am not quite sure how to articulate this but here goes: a system should have a specific aim in mind. The individual components of a system exist to serve a specific goal. Here's an example: early wargames had no concept of hit points. If one unit made a successful attack against another it would kill a certain amount of troops in that unit. Hit points were invented to represent warships in an attempt to simulate how ships can be shot and damaged several times before sinking. Gygax took that idea and ported it to OD&D (and technically Chainmail) because the system was envisioned as a wargame where each player controlled an individual and dieing to one hit is a bummer. In both cases Hit Points were used to solve a very specific problem.
Mechanics are just means to an end. You shouldn't ask yourself which tools to use before you have a good idea of where you are going.
Grey Paladin on
"All men dream, but not equally. Those who dream by night in the dusty recesses of their minds wake in the day to find that it was vanity; but the dreamers of the day are dangerous men, for they may act their dream with open eyes to make it possible." - T.E. Lawrence
I think plenty can be said about different ways to design systems. At the very least, they can be compared and assessed in terms of the type of player who will enjoy them, and how accessible they are for those who don't care to learn the entire system. There are different ways to build your game if you want to demand absolute mastery vs. letting players squeak by with normal attacks and overleveling.
Mario RPGs are eminently understandable and operate on very low numerical scales - in at least one game you cap out at 50 hit points. Meanwhile Final Fantasy 7 starts you out at 300 HP. I'd guess that a game using higher numbers like FF7 is more likely to have players glaze over at the difference between weapons (yay, the numbers went up), while in the Mario RPG series every damage increase is immediately noticeable and more often means the difference between killing enemies in one hit or two.
Complexity doesn't always lead to more meaningful, engaging combat. Here's an article about Crusader Kings 2 and all its complexity that leads to most players ignoring the whole thing and treating it as a function of army size and nothing more...which speaks to how you might design your own system.
Just a few of the things I was hoping to look into.
Has anyone ever come across a resource or examples of how to design a good combat system for an RPG?
I'm talking about all the interplay between attack, defense, accuracy, speed etc. How to make the math work well, not be too unbalanced, and also how to make it interesting.
I could look at some breakdowns of how other games do it, in fact I know I've seen some formulas in the past on various wikis, like various Final Fantasy combat systems, or Pokemon's. I'm just curious if there's a good book or article out there that goes through the design process, how to tackle it in different ways. One with few stats, one with lots of derived stats, that sort of thing.
It just seems like the more obvious starting points could lead to problems down the line. Like, total damage is attacker's attack minus defender's defense, if less than 1 then damage = 1. That kind of thing seems awful, you probably want to scale things better, but I don't know the best way to do so.
When you're doing this stuff use multiplication and division more than addition and subtraction.
My personal favorite implementation of defense is basically "Every X defense points you reduce damage by an additional half."
0 defense multiplies incoming damage by 2. X defense means you take normal damage. 2X defense means you take half, 3X means you take a fourth, 4X means you take one eighth, etc.
1 / (2^x) gives you the following values:
0: 1
1: 1/2
2: 1/4
3: 1/8
4: 1/16
So you can use:
1 / (2^[STAT / THRESHOLD])
in order to accomplish geometrically decreasing stuff.
Generally speaking your numbers will scale better if your formulas return a multiplier which is applied to your base damage.
You could always go nuts and use physics as a basis and convert attacks in energy (joules) based on weapon mass and character strength and calculate armor base on how well it can handle and dissipate that energy, anything left over damages the player.
Everytime I've approached an RPG battle system I've started with the basic values of attack and defense and HP and you tune the system as you go. From the simplest system then you can decide that attack is calculated by multiplying player strength by weapon attack power and keep building the system up.
You need to reduce it to equations with a basic unit to transfer damage, lets call it wangs. An attacking enemy has to combine up all their modifiers into producing X wangs towards the player and then the player takes X wangs and applies all their defense modifier to then get the final effect to their HP. Along the way to can also convert wangs to damage to equipment and so on. Later you can also flavor your wangs and add elemental damage and other properties to wangs transfers between npc and player.
Start small and build up. Keep producing damage and receiving damage as separate parts also like a service architecture to simplify the addition of complexity.
Decided to implement the "special ability" buttons. Made the button, realized I had no art for them yet. Start making art. Need to double check the old art for the buttons so that the style can stay matched up.
Notice that the clean-looking pseudo-vector-graphics stylized wireframe look I'm going for is...
I realize you're asking more about damage calculation than accuracy, but since I've been kicking around an idea for a traditional JRPG battle engine lately, I figure I might pass along a method of calculating attack accuracy that occurred to me that I'm starting to like. I'm calling it "dilution defense".
If accuracy is improved by DEX and weakened by AGI, then the chance to hit is:
DEX / (DEX + AGI)
That is, the accuracy of an attack is the ratio of the attacking stat to the sum of the attacking and defending stat. This results in a 50% chance when both scores are equal. If that's too swingy, you can multiply the attacking stat by some constant factor; for instance, if you multiply DEX by 3 before passing it in, the base accuracy of the attack is 75%. What I like about this method is that it naturally converges to the range of 0% to 100%, without ever reaching it except in the intuitive case of either DEX or AGI being 0. A common problem with accuracy systems is that after you accrue a certain amount of the accuracy stat, you have a 100% hit rate and any further improvement of your accuracy is wasted effort.
The downside of this system is that it relies on DEX and AGI having broad ranges; if you want to see a broad range of accuracy possibilities, then you need to have situations where a character's DEX would vastly outnumber the target's AGI, and vice-versa. That requires either the ability to significantly swing the values in combat, or for characters to have some kind of percentage-based levelling up where a low-AGI character will have an objectively low value for most of the game.
Also, implementors must be cautious of the possibility for a divide-by-zero error in the pathological case where both characters' stats are 0.
Kupi on
My favorite musical instrument is the air-raid siren.
One thing to be wary of with that is the distribution is rather nonlinear. You need 4x the attacking stat to get to a reliable hit % (80%) and 9x to reach 90% but only 1/2 of the attacking stat to get to 33% to-hit and 1/4 gives you 20%. You'll need to design everything around not having reliable hits and most normalizing quickly to 50% and then very slowly up from that. It's also very difficult to get an actually reliably hit unless you have a 10x or more swing
Eg, if someone builds a unit that has 150 attack 50 defense and it's up against a 50 attack 150 defense it's an even match. But against a 100 attack 100 defense unit it will hit 60% of the time and get hit 66% of the time. It can confuse players about the value of their stats at the very least and just encourages either meaningless huge numbers or to-hit chances all in the 40-60 range IMO
Is it a really bad idea to have an override not call the base function? I'm thinking that in order to synchronize some stuff, I need to re-do some stuff, and there's just enough overlap between most of the children classes that it's probably a good idea for me to just re-code more of the stuff to the parent so it's easier to manage, but there's one child type that doesn't behave at all like the other towers. So if I were to put the behaviour into a virtual, then have the one that behaves differently just not call the base function, would that be dumb?
Posts
And most importantly, I've still got plenty of time to leave to make it to class on time.
Today is a good day so far.
Though it did become increasingly obvious to me that while having the base Enemy class handle damage when hit by a projectile or when hitting the shields or base(or now also splash damage) made sense at first, it's starting to be a very strange way of doing things. Especially since the laser towers also work in a dumb way where they deal damage and also check to see if the enemy is at =<0 health, and if they do they call the Enemy's function to explode and die. Bullets and missiles could probably do the same thing if I wanted, and would make it so I don't have some weird massive switch statement in the Enemy class.
I have a character BP I'm putting together based loosely on the SideScrollerCharacter from the SIdeScroller template. I'm using a character from the asset store that came setup with a ThirdPersonBP, but I don't want full third person movement, I want simple two plane movement. I have this working, it's fine...but my character will not face the direction of movement...while the SideScrollerCharacter does...but I can't find the difference between my character BP and the SideScrollerCharacter. Clearly something in that BP, or it's animation BP, is not set to force facing direction of movement...but I'm completely missing it. So my guy is animating correctly, jump and running, he's just always facing one direction regardless of movement (and yes, I'm using physics based movement).
Anyone know what I might be missing?
or even let you define one
Not sure what you mean by physics based movement, but does your character's MovementComponent have "Orient Rotation to Movement" set true?
The reason it's weird is that it only handles when it hits something or when something hits it.
Except that the laser weapons, which are, like, half the weapons in the game, just use a line-renderer and deal damage directly
So the problem is less that the enemy handles itself taking damage, and more that the enemy handles itself taking damage except sometimes it doesn't?
And I feel like it should probably be more consistent.
Also the enemy grabs the damage from the thing hitting it, so it was built with a switch statement to figure out what was hitting it.
What I will probably end up re-doing is making the enemy have a single TakeDamage(float damage) function on the parent Enemy class, and the towers and projectiles will call that function when they hit it with their damage. That way the enemy is still handling it's own health from sources, but each source will deal with the enemy in the same way.
Edit: Well, now what I did was exactly that. It makes everything much clearer now.
This is almost certainly what it is. I'll check when I get home.
Anyone have any general advice in this area? How long has this taken people with their own project?
It was.... really unwieldy.
Long story spoiler
Then I had only made one type of tower, and it fired bullets. I knew I wanted it to be upgradable, so the bullets had a damage stat that was passed to them by the tower. When the enemy had an OnCollisionEnter(), they would access the bullets damage from the bullets script, deal that damage to themselves, and then check to see if they died. That way they could use the fact that the enemies were doing the collision detection stuff to keep things simple.
But then I ended up adding a missile, which used the same idea, but had a different movement script, and they weren't part of a 'projectile' parent script or anything, because really the only thing they shared was "Does damage on hit", and the missile doesn't even respond the same when it hits a thing(it explodes, and later I added a splash damage thing to its explosion). So then it started to make sense to deal with a switch statement for the tag of the thing that hit it, but then running the same code to take the damage and check to see if it was time to die. It was a little sketchy of a way to accomplish the end, but it worked and I had already set up most of the behaviour.
So basically the Enemy would OnCollisionEnter check the tag of the collision, and based on what it was, it would access the script of the object, check the damage variable, deduct that from its health, destroy the other object, and if health was <=0, destroy itself.
And then I went on a 2-week vacation...
And then I made the laser tower and the charge-laser tower, and the laser tower deals continuous damage each frame and doesn't fire a projectile. And the charge laser was just destroying them on firing, but with a low fire-rate. So those two had to access the enemy health and change it, and then check to see if it was 0 and destroy it if it was. And then I made a shield that didn't get destroyed on contact, but instead have a health pool and can be deactivated and reactivated by another tower. So that was another switch case.
So I ended up with like 4 different interactions with the Enemies and one of them involved a big ol' unnecessary switch statement. And a bunch of variables were needlessly global and passed around. It all just sort of sprouted from quick ways to accomplish what I needed at the time, and I was really just interested in getting something working before my schedule started to get crazy, but it quickly became really dumb. It worked, and now I've created the 5 main tower types so I could've just left it as it is, but it was really dumb and confusing to look at.
Now everything just interacts with the Enemy's parent class with the TakeDamage(d) function when it damages any Enemy object. I could still clean it up a bit I guess by maybe making a projectile damage script and putting that on the bullets and missiles instead of having the same 4 lines in both movement/targeting scripts, but that's so very minor compared to the mess that had accumulated before. Also I don't even know if it would work/be worth it because the missile does another function when it hits something.
Anyone have any suggestions, besides uh... fixing that one touch target? ;-)
Unreal Engine 4 Developers Community.
I'm working on a cute little video game! Here's a link for you.
I'm almost positive Unity isn't the best tool for the job. But its the dev environment I know the best and have been working with for the last ~4 years. So it is the square peg I'm going to use regardless of the properties of the hole.
Right now I'm looking to run the controller and the visualization on the same machine because the overlay is being added to OBS as a window view. In an ideal world I could set it up so that I had one system dedicated to rendering the game, one system for streaming, and maybe a tablet UI for controlling the bot. But that is pretty far away.
The whole project is fairly crazy but I'm having fun still.
I haven't used gamemaker in forever but I recall using a really ghetto method to make more complicated data types. I instantiated gameobjects with the scripts and properties I wanted, then referenced them as needed. Shouldn't affect performance unless you have gillions of them
@LaCabra So it was this, and a couple of other things...but I now actually understand the SideScrollerCharacter, rather than just using it, which was the entire point
Now it's not just 4 towers sitting there shooting stuff.
Now it's up to 8 towers sitting there shooting stuff! And the user controls where they are and which ones(up to a maximum of 2 of each type for reasons the will totally make sense once the actual audio stuff goes in)
Next step is probably currency, and then I should probably start in on the whole music engine thing.
EDIT: Ooh upgrades! I still can code upgrades before I have to actually get to the real work
Just watched this video with some pro level designers. They're playing through some Doom levels while talking about level design, making Doom, and other cool industry stuff.
It got me thinking about what you've been saying @LaCabra about how current level design tools are awful and time consuming. From the video, after LeBreton talks about how with Bioshock the levels look great but take an incredible amount of time to make, he says:
Accompanying article: http://www.gamasutra.com/view/news/234838/Video_John_Romero_joins_JP_LeBreton_to_play_and_discuss_Doom.php
Always make any shake or headbob toggleable. I hate headbob in most game and want it off off off off kill it with fire. My girlfriend never finished portal 2 because the shaking at the end made her motion sick.
Go watch Epic's presentation about how they actually build levels for things. It's eye opening and shows you how they do some of the very things people were doing in Doom, while leaving themselves the space to come back and fill in the play space with all the pretty. For instance, the way they tend to take the initial prototype level geometry and turn it in to the bounding volumes for the level, that all the fancy geometry lives inside of.
LaCabra has been campaigning about this for a wile:
his point was the speed and ease of it meant the level designers unique taste could be expressed more coherently and more directly
its an artistic point, not a technical one
That said, I'm not an artist, I'm a programmer...so take my raised eye brows at the entire subject with a grain of salt.
I actually just did a consulting job with unity on how they can improve their level design tools (well, add some) and help get back to the point where level designers can actually do level design again
Yeah you've got the wrong end of the stick. It's not comparing a simple thing to a complex thing, it's saying "a simple task exists. it used to be very simple to do, and now doing the exact same thing is complex and slow". Like, as an example making Doom's E1M1 in Unity or Unreal, to the exact same standard of complexity and fidelity, will take you a lot longer than in Source. It's a matter of having good level design tools versus not having good level design tools - the brief never changed, people just stopped following it
A struct holds the name of the sprite sheet to read from, the dimensions of a given sprite, an array of integers where each element encodes frame information (see below), and a pointer to the animation struct the program should read after it finishes with this one if it hasn't been assigned another struct to execute next.
An animated entity consists of a set of coordinates, a pointer to an animation struct and an integer animation index. When an animated entity is loaded it is assigned an animation struct and its index is set to 0. Each element of the array in the animation struct is read in the following fashion: an integer equal to or less than 1000 is read as "render the Nth sprite on the sheet then increase the index by 1". An integer above 1000 is read as "render the sprite located at i-1 for N-1000 milliseconds before advancing the index". Each loop the program goes over each entity and renders the frame its index corresponds to in its animation struct. Changing a sequence mid-animation is as simple as assigning the entity's pointer another struct and changing the index to the desired value.
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
Legends of Runeterra: MNCdover #moc
Switch ID: MNC Dover SW-1154-3107-1051
Steam ID
Twitch Page
I'm talking about all the interplay between attack, defense, accuracy, speed etc. How to make the math work well, not be too unbalanced, and also how to make it interesting.
I could look at some breakdowns of how other games do it, in fact I know I've seen some formulas in the past on various wikis, like various Final Fantasy combat systems, or Pokemon's. I'm just curious if there's a good book or article out there that goes through the design process, how to tackle it in different ways. One with few stats, one with lots of derived stats, that sort of thing.
It just seems like the more obvious starting points could lead to problems down the line. Like, total damage is attacker's attack minus defender's defense, if less than 1 then damage = 1. That kind of thing seems awful, you probably want to scale things better, but I don't know the best way to do so.
For instance, in D&D the basic way to calculate the attack is:
given toHit, damageBonus, weaponDamage, and enemyDefense as ints:
if((Random.Range(0-20)+toHit) >= enemyDefense){damageDone = (Random.Range(1,weaponDamage) + damageBonus)}It's a pretty simple way to calculate that sort of thing, but it gives you scalability(lower-level enemies can have lower defense, and higher level characters will have higher toHit, so the chance approaches 100%), and has a bit of randomness to add in the joy of making and missing clutch moments.
There might be other manuals or discussions, but D&Ds great because it's so transparent about how it works, and you can see iterations through the years while they try to clean up the algorithms.(for instance, there was that time where the algorithm was, like)
int toHit, armourClass, weaponDamage, damageBonus; if(Random.Range(0-20)>=toHit-armourClass){damageDone = (Random.Range(1,weaponDamage) + damageBonus)}Which works exactly the same eventually, but involves this weird other thing where your toHit and armourClass are the opposite of what you'd expect, and you actually want a low toHit and AC. And the armourClass could then go into the negatives which was super good but super confusing.
I'd just like to see...I dunno, more examination of different ways to do it, upsides and downsides. I don't want to just steal someone else's system, and I want to make something extensible with plenty of ways to modify what's going on.
Find out what is it that your game is trying to do and the numbers will fall into place.
For example, part 2 goes into the combat system of Dragon Warrior and examining the numeric relationships between all the various parts, how everything ties back into HP as a primary resource.
Mechanics are just means to an end. You shouldn't ask yourself which tools to use before you have a good idea of where you are going.
Mario RPGs are eminently understandable and operate on very low numerical scales - in at least one game you cap out at 50 hit points. Meanwhile Final Fantasy 7 starts you out at 300 HP. I'd guess that a game using higher numbers like FF7 is more likely to have players glaze over at the difference between weapons (yay, the numbers went up), while in the Mario RPG series every damage increase is immediately noticeable and more often means the difference between killing enemies in one hit or two.
Complexity doesn't always lead to more meaningful, engaging combat. Here's an article about Crusader Kings 2 and all its complexity that leads to most players ignoring the whole thing and treating it as a function of army size and nothing more...which speaks to how you might design your own system.
Just a few of the things I was hoping to look into.
When you're doing this stuff use multiplication and division more than addition and subtraction.
My personal favorite implementation of defense is basically "Every X defense points you reduce damage by an additional half."
0 defense multiplies incoming damage by 2. X defense means you take normal damage. 2X defense means you take half, 3X means you take a fourth, 4X means you take one eighth, etc.
1 / (2^x) gives you the following values:
0: 1
1: 1/2
2: 1/4
3: 1/8
4: 1/16
So you can use:
1 / (2^[STAT / THRESHOLD])
in order to accomplish geometrically decreasing stuff.
Generally speaking your numbers will scale better if your formulas return a multiplier which is applied to your base damage. ...or what have you.
Everytime I've approached an RPG battle system I've started with the basic values of attack and defense and HP and you tune the system as you go. From the simplest system then you can decide that attack is calculated by multiplying player strength by weapon attack power and keep building the system up.
You need to reduce it to equations with a basic unit to transfer damage, lets call it wangs. An attacking enemy has to combine up all their modifiers into producing X wangs towards the player and then the player takes X wangs and applies all their defense modifier to then get the final effect to their HP. Along the way to can also convert wangs to damage to equipment and so on. Later you can also flavor your wangs and add elemental damage and other properties to wangs transfers between npc and player.
Start small and build up. Keep producing damage and receiving damage as separate parts also like a service architecture to simplify the addition of complexity.
Decided to implement the "special ability" buttons. Made the button, realized I had no art for them yet. Start making art. Need to double check the old art for the buttons so that the style can stay matched up.
Notice that the clean-looking pseudo-vector-graphics stylized wireframe look I'm going for is...
..slightly ruined.
If accuracy is improved by DEX and weakened by AGI, then the chance to hit is:
That is, the accuracy of an attack is the ratio of the attacking stat to the sum of the attacking and defending stat. This results in a 50% chance when both scores are equal. If that's too swingy, you can multiply the attacking stat by some constant factor; for instance, if you multiply DEX by 3 before passing it in, the base accuracy of the attack is 75%. What I like about this method is that it naturally converges to the range of 0% to 100%, without ever reaching it except in the intuitive case of either DEX or AGI being 0. A common problem with accuracy systems is that after you accrue a certain amount of the accuracy stat, you have a 100% hit rate and any further improvement of your accuracy is wasted effort.
The downside of this system is that it relies on DEX and AGI having broad ranges; if you want to see a broad range of accuracy possibilities, then you need to have situations where a character's DEX would vastly outnumber the target's AGI, and vice-versa. That requires either the ability to significantly swing the values in combat, or for characters to have some kind of percentage-based levelling up where a low-AGI character will have an objectively low value for most of the game.
Also, implementors must be cautious of the possibility for a divide-by-zero error in the pathological case where both characters' stats are 0.
Eg, if someone builds a unit that has 150 attack 50 defense and it's up against a 50 attack 150 defense it's an even match. But against a 100 attack 100 defense unit it will hit 60% of the time and get hit 66% of the time. It can confuse players about the value of their stats at the very least and just encourages either meaningless huge numbers or to-hit chances all in the 40-60 range IMO
So I have a question.
Is it a really bad idea to have an override not call the base function? I'm thinking that in order to synchronize some stuff, I need to re-do some stuff, and there's just enough overlap between most of the children classes that it's probably a good idea for me to just re-code more of the stuff to the parent so it's easier to manage, but there's one child type that doesn't behave at all like the other towers. So if I were to put the behaviour into a virtual, then have the one that behaves differently just not call the base function, would that be dumb?