A large part of my work this quarter was devoted to attempting to implement netcode into the Grind, which unfortunately ended up falling out of scope within the time allotted.
Beyond that, I implemented a rumble feature by changing how unity received controller input, built the main menu and character select screens and functionality, and refined the AI behavior.
The level scripts were also refined, as well as allowing the level designers better affordances of which scripted objects were affecting which objects in the editor. Also I introduced a scripted "breakable wall" which unfortunately didn't get put into the final build.
Level script log:
10:32 AM 4/3/2014
v1.10
Anything that triggers something now only draws line to what it affects when selected; visually it became a mess of lines going everywhere and it was getting somewhat laggy.
Revised; everything that sends an activate impulse now has a toggle to just display when selected or constantly display what they affect.
Added "DodgeNode" tag and DodgeNode object. It's just a null with the tag, and is used to give the Hopper places it can dodge to. This gives level designers a way to make sure he won't doge off a ledge.
4:18 PM 4/10/2014
v 1.11
Timer turn off fixed.
10:19 PM 4/14/2014
New destructable wall in progress that contains individual bricks that have physics properties when the wall is "destroyed".
3:06 PM 4/19/2014
Began main menu script. This is not actually a tool.
Began interface tool for pop-up GUI windows.
3:05 PM 4/23/2014
Increased destructable knockback.
Timers can now deactivate.
Music boxes now can be activated and deactivated.
1:50 PM 5/10/2014
Chests now don't wiggle their collision when they move. Players shouldn't get trapped inside them now.
5:24 PM 5/6/2014
Movers can now loop from specific points.
"KillPlayer" script now can deal specific damage.
Other scripting:
4:18 PM 3/27/2014
Updated character controller input (CHR_CTRL) to use a new controller input method. This fixes the trigger problems and fixes unity's issue with consistently determining which player is which
5:42 PM 4/1/2014
Added system in CHR_CTRL to allow force feedback. Actually getting this to work required some weird directions, because the controller isn't on the player object.
CHR_DMG modified to send force feedback info so it vibrates when hit.
2:14 PM 4/2/2014
CHR_CTRL now also ignores any rumble input sent to it if it's less than the current rumble.
WPN_ATN modified so charging rumbles.
5:45 PM 4/8/2014
Controller input screwed up out of nowhere, and was controlling each other's characters. Fixed by swtiching everything over to using XInput fully. DIDN'T DO THIS FOR START BUTTON.
3:02 PM 4/23/2014
Main menu script
6:47 PM 4/25/2014
Main menu and script along with char select screen. Waiting on having another player character animated before progress can continue.
3:14 PM 5/15/2014
Added pause menu object. Needs to be in a level to show up. It is added to the SceneMGR object because that's always at a point where people can pause.
3:40 PM 5/21/2014
Level transition functionality started. Hooks into the level change event, displays that a level is complete along with which player is in which place
Game ctrl manager modified. Added GiveXPValues.
Level transition completed, waiting for testing.
AI:
3:06 PM 4/1/2014
Snatcher now rotates properly and dies and despawns properly. Rotation bug kinda adds more life into it too.
3:22 PM 4/3/2014
v1.9
Juggernaut's stats fixed again. Damage 1.5, knock 5, stun 1. Stun should prolly never be over 1, knock should be between 3-7.
Sandra now passes target info correctly, and doesn't shoot 3-pointers from crotch. Attack damage is 0.5 (because they throw two boomerangs at a time). Base attack time is 1.5
Found out why in rare occurrances enemies will run off of cliffs: they're within the 0.5 threshold y distance of their target, and their target is grounded, they enable bForwardOverride, which moves them forward regardless of void in front of them. Messing with this number on my end will make monsters never be able to attack players on slopes; the level platforms must be set to be within the range or this will happen.
1:32 PM 4/5/2014
The changes that had wandering in them dissapeared. VERSION CONTROL SUCKS.
Cleaned up AI_MAIN a little bit. Re-implimented wandering.
Added means of taking all players' positions in for getting a move direction. Intended for use in the Hopper, which tries to avoid everyone until they attack.
Hoppers have larger sight radius than most monsters to keep them away from players.
Hopper's prefab changed: Min and max Charge Time reduced to 0.2 to ensure I can unleash it whenever.
New hopper mostly implimented; waiting on Eugene's damage types implimentation so he can avoid projectiles. Weird bug where the first time he attacks he does the normal attack rather than the charge.
New hopper works like this: He goes out of his way to avoid all players, then closes in on one of them, and hops at them to attack. Pauses afterwords, this is the moment in which they can be attacked; they loop afterwords. If approached outside of this window, they back up, and if players get too close or if they're about to walk off a ledge, they jump into the air to a point away from the players.
Level design is now required to impliment hoppers. Their jumping avoidance method requires placing "nodes" in the level - these are just nulls with the "DodgeNode" tag. After it flies upwards, it picks the node furthest from all players, so long as that node isn't over 50 meters away from itself (this distance check is so you can have hoppers in multiple areas inside a level; otherwise you'd have hoppers at the end of a level bouncing to nodes at the begining.)
The reason why these dodge nodes exist is because they're the simplest method of making sure they don't dodge an attack, only to jump off a ledge. :B
Added "DodgeNode" tag.
Hoppers: Sheild stuff too out of scope possibly; consider better avoidance by taking multiple nearby players into account when determining move direction. If they're backed into a corner, could also have them jump up like juggernauts do, but land at a more secure place.
Attack has longer pause after? Jump back, if he still doesn't?
Consider having Hoppers be immune to projectiles (for now, they ignore them and deal no damage - "Miss!" pops up when they collide) or possibly even reflect them. Deflect would work too.
Sandra shouldn't move towards targets. Instead, she should get a start vector based on where she spawns, and wander around on her own from that (idle wander, but more pronounced [longer wandering duration] than default monster wandering and more frequent). If she's outside a certain distance from her start, she wanders back closer to it.
V1.10
12:06 PM 4/30/2014
Sandra now moves in a random direction after attacking.
v1.11
Snatchers now have the correct model, and have rudementary animation.
Wisps now have their particles and can be attacked to detonate.
v1.12
Hoppers avoid time cut from 4 seconds to 2.
Wednesday, May 28, 2014
Tuesday, March 11, 2014
The following is the changelog for the AI scripts that I've spent the quarter working on.
3:35 PM 1/15/2014
I have absolutely no idea why it never occurred to me to update and record revisions like this until now.
v1.0
Added:
AI searches for targets. Upon hitting a wall, it will adjust direction left or right depending on which is
closer to target.
-Attack rate. Small timer that allows adjustment to how fast the enemy can attack.
- Enemies now stop if they're about to walk off a cliff. If they're making sharp turns around a corner, they
might still blunder over a ledge, though; not much I can do about that at the moment with this particular method.
v1.1
Added:
Enemies now update targets again; they'll (presumably) stop if target lost (or killed), and will change targets if attacked.
Hopper code begun.
Hopper stops when inside attack range, and turns to face target. Hopper pauses outside of range, then lunges at target.
Enemies now correctly shoot projectiles. (Eugine)
Enemies now correctly use ramps. Going up ramps is slow due to current physics, but enemies will go down them if their target
is on the ground and below them.
v1.2
????
v1.3
- Hopper attacks now wait for attack animations to quit playing before moving to next state/etc.
- Hopper now has the intended behavior for which it was designed: It approaches players, leaps in, attacks, and leaps outward.
- Juggernaut functionality in. Currently broken because turning off personal gravity makes every OnGround check return true. When Eugene fixes that, this will work fine.
- Wisp functionally implimented, waiting on ability to detonate when hit.
- Code structuring partially implimented
v1.4
- Bot objects updated for rigid bodies (by Eugene)
- Juggernaut now correctly falls [Eugene fixed personal gravity bug.]
- Juggernaut's stomp/slam ability implimented and functional, but currently does not wait for animation to finish.
- Enemies now have differing sizes and textures. These textures are literally me just throwing existing textures on top of them because I don't know how to make new ones from scratch yet. But it's enough for visual distinction between enemies, especially considering that the resizes and textures exist to show differentiation between enemies until we get the actual enemies in the game anyway.
11:34 AM 2/10/2014
v1.5:
- Bots no longer stare into the void when they find a cliff, again. Reducing the amount the moveDir is reduced by fixed this; this implies the cutoff Eugine implimented to get an enemy to stop using their movement animation when their moveDir is really small actually physically makes their movement zero, rather than simply using the idle animation.
- Bot scripts now extend from main AI script. Main AI script houses standard AI functions - movement, obstacle and pit detection, and so on - while the scripts for individual enemies now exclusively handle their individual behaviors.
- The basic low-level enemy is now BasicEnemy. TestEnemy still exists and has not been removed to avoid it breaking some levels, but be advised that it won't use updated movement/AI code.
3:03 PM 2/11/2014
v1.6:
- bots now use materials again for visual distinction.
- Found bug where bots will walk off cliffs sometimes because their Y coord is juuuust slightly different from their target's. This is because receiving knockback pops them up in the air, and when they land their y coord is slightly different. Fixed this by adding a threshold - Enemies will now only ignore collision in front of them and the absence of ground below them if their target is half a meter above or below their position.
- Bots now face their targets independantly of the direction in which they're moving, (the aiming code is in CHR_PHY, and the actual line is AimAt(GameObject);) This is a large first step for more advanced movements. Next step is looking into switching around between local and global positions and movement. Actually getting them to /stop/ facing something is unknown; maybe just send it a null?
- Because of the new facing code, EndMove can be called to nuke moveDir without locking its rotation, meaning we don't have to divide moveDir by a rediculous number to get it to stay in place, which in turn means the visual issue of enemies moving in place no longer exists.
- Bug found where enemies would seemingly randomly stop moving, permanently. Bug was in bFaceTarget incorrectly turning itself off; bug fixed.
- Juggernaut now makes sure target is on ground before jumping at they ass.
- Snatcher functional. Movement is slightly wonky and needs refinement; jumps towards, and if it misses, it hops straight up, then loops. When it collides with a player, it'll start syphoning EXP from whoever it's attached to. This exp goes into a pool, and whoever kills the snatcher gets its base exp plus all the exp it syphoned.
- Basic ranged enemy fixed, and now attacks at range like it's supposed to.
- Sandra will shoot her boomerang, but the boomerang goes flying over the target and does not return. Also too fast.
- Wisp uses damage radius, and no longer does stupidly absurd amounts of knockback.(Seriously, how'd it get put to 70? O_o)
- Juggernaut's knockback now knocks slightly less upward.
5:08 PM 3/4/2014
v1.7
- Enemies now have a tentative wandering thing. If idle, and without a target, they'll move in a random direction for a random duration every so often. Bug found in that discovering a pit will have them stuck and staring at it. Rotating the enemy them to the direction in question fixed this. Will sometimes wander off cliffs; not entirely sure why as of yet.
- various AI tweaks regarding attack speed, damage, knockback, etc.
- Kinematic to false for ragdolling. Animations need to not play to work. Ragdoll wizard sets up colliders; remove them. No gravity.
3:35 PM 1/15/2014
I have absolutely no idea why it never occurred to me to update and record revisions like this until now.
v1.0
Added:
AI searches for targets. Upon hitting a wall, it will adjust direction left or right depending on which is
closer to target.
-Attack rate. Small timer that allows adjustment to how fast the enemy can attack.
- Enemies now stop if they're about to walk off a cliff. If they're making sharp turns around a corner, they
might still blunder over a ledge, though; not much I can do about that at the moment with this particular method.
v1.1
Added:
Enemies now update targets again; they'll (presumably) stop if target lost (or killed), and will change targets if attacked.
Hopper code begun.
Hopper stops when inside attack range, and turns to face target. Hopper pauses outside of range, then lunges at target.
Enemies now correctly shoot projectiles. (Eugine)
Enemies now correctly use ramps. Going up ramps is slow due to current physics, but enemies will go down them if their target
is on the ground and below them.
v1.2
????
v1.3
- Hopper attacks now wait for attack animations to quit playing before moving to next state/etc.
- Hopper now has the intended behavior for which it was designed: It approaches players, leaps in, attacks, and leaps outward.
- Juggernaut functionality in. Currently broken because turning off personal gravity makes every OnGround check return true. When Eugene fixes that, this will work fine.
- Wisp functionally implimented, waiting on ability to detonate when hit.
- Code structuring partially implimented
v1.4
- Bot objects updated for rigid bodies (by Eugene)
- Juggernaut now correctly falls [Eugene fixed personal gravity bug.]
- Juggernaut's stomp/slam ability implimented and functional, but currently does not wait for animation to finish.
- Enemies now have differing sizes and textures. These textures are literally me just throwing existing textures on top of them because I don't know how to make new ones from scratch yet. But it's enough for visual distinction between enemies, especially considering that the resizes and textures exist to show differentiation between enemies until we get the actual enemies in the game anyway.
11:34 AM 2/10/2014
v1.5:
- Bots no longer stare into the void when they find a cliff, again. Reducing the amount the moveDir is reduced by fixed this; this implies the cutoff Eugine implimented to get an enemy to stop using their movement animation when their moveDir is really small actually physically makes their movement zero, rather than simply using the idle animation.
- Bot scripts now extend from main AI script. Main AI script houses standard AI functions - movement, obstacle and pit detection, and so on - while the scripts for individual enemies now exclusively handle their individual behaviors.
- The basic low-level enemy is now BasicEnemy. TestEnemy still exists and has not been removed to avoid it breaking some levels, but be advised that it won't use updated movement/AI code.
3:03 PM 2/11/2014
v1.6:
- bots now use materials again for visual distinction.
- Found bug where bots will walk off cliffs sometimes because their Y coord is juuuust slightly different from their target's. This is because receiving knockback pops them up in the air, and when they land their y coord is slightly different. Fixed this by adding a threshold - Enemies will now only ignore collision in front of them and the absence of ground below them if their target is half a meter above or below their position.
- Bots now face their targets independantly of the direction in which they're moving, (the aiming code is in CHR_PHY, and the actual line is AimAt(GameObject);) This is a large first step for more advanced movements. Next step is looking into switching around between local and global positions and movement. Actually getting them to /stop/ facing something is unknown; maybe just send it a null?
- Because of the new facing code, EndMove can be called to nuke moveDir without locking its rotation, meaning we don't have to divide moveDir by a rediculous number to get it to stay in place, which in turn means the visual issue of enemies moving in place no longer exists.
- Bug found where enemies would seemingly randomly stop moving, permanently. Bug was in bFaceTarget incorrectly turning itself off; bug fixed.
- Juggernaut now makes sure target is on ground before jumping at they ass.
- Snatcher functional. Movement is slightly wonky and needs refinement; jumps towards, and if it misses, it hops straight up, then loops. When it collides with a player, it'll start syphoning EXP from whoever it's attached to. This exp goes into a pool, and whoever kills the snatcher gets its base exp plus all the exp it syphoned.
- Basic ranged enemy fixed, and now attacks at range like it's supposed to.
- Sandra will shoot her boomerang, but the boomerang goes flying over the target and does not return. Also too fast.
- Wisp uses damage radius, and no longer does stupidly absurd amounts of knockback.(Seriously, how'd it get put to 70? O_o)
- Juggernaut's knockback now knocks slightly less upward.
5:08 PM 3/4/2014
v1.7
- Enemies now have a tentative wandering thing. If idle, and without a target, they'll move in a random direction for a random duration every so often. Bug found in that discovering a pit will have them stuck and staring at it. Rotating the enemy them to the direction in question fixed this. Will sometimes wander off cliffs; not entirely sure why as of yet.
- various AI tweaks regarding attack speed, damage, knockback, etc.
- Kinematic to false for ragdolling. Animations need to not play to work. Ragdoll wizard sets up colliders; remove them. No gravity.
The following is the changelog for the scripts and objects I built for level construction. I made them with the intention of exposing as much needed behavior and abilities for the level designers without them ever having to touch a line of code.
5:40 PM 1/21/2014
James Ensley
Added:
- Retooled pressure plates so you could throw an object at them in unity, rather than have to monitor
their progress in the level script. You can now do either. This is intended to ease level design, and make
things a lot more plug-n'-play. Currently the only thing this modifies is movers.
- Added movers. Movers require a target, and this target can be anything. When the timer runs up, it'll start
moving towards the target at the speed you set. "stuttering" is for a visual affordance to players that the object
is about to move.
I'm calling them "movers" rather than just "wall movers" as originally intended, because they can be used in any direction.
Note that if it's too fast, or moves too far (hence stutterMaxDist) it /will/ clip right through players and enemies,
and there's not much I can do about that.
To use pressure plates, just make a primative (or, later, do this with a mesh), throw the Pressure Plate script
at it, then make sure "Is Trigger" is checked in the Box Collider component. Movers
Anything with bActive == false does not activate or do anything until it bActive == true. Pressure plates are
currently the only way to activate an object with bActive set to false, though you could also do so in level
scripts.
5:48 PM 1/23/2014
- Renamed "pressure plates" to "triggers", to reflect that their functionality is for internal level development. You can still use them
as pressure plates, of course.
- Triggers now can trip only once, if needed.
- Made "Spawn switcher"s. Throw your player spawns into it in the order you want them to be used, and have triggers target it. Each time a
trigger activates it, it sends the next player spawn in the list to the scene manager. Need to have the triggers only hit once!
6:04 PM 1/25/2014
- Added tool for throwing text on screen. Use triggers to change from one line to the next. Extremely basic, just for quick playtesting.
- If triggers have a sound attached to them, they play when triggered.
7:19 PM 1/28/2014 v 1.2
- TextToScreen tool now has nearly every variable inside it exposed, so you can put it wherever the hell you want.
- Triggers now /should/ have weight limits (untested). If weightLimit is set to anything above zero, the combined charMass of everything touching it needs to be equal to or above weightLimit to trigger it.
4:08 PM 1/29/2014 v1.3
- Movers now truncate position and stop on the aimtarget they're aiming towards, and then deactivate.
- Movers can have one impulse to trigger or many; once activated, they ignore further impulses until they reach their next waypoint, at which point they snap to it and deactivate. Another impulse at that point will turn them back on, and they'll move to their next waypoint. For this reason I'd highly recommend any trigger that triggers them be one use ONLY if you are absolutely certain it'll be at a complete stop when triggered - otherwise the level might be broken and they'd have no way to get the mover moving again.
- Movers now support multiple targets, and effectively have a wapoint system. But it's a little wonky - you have to tell it how many targets you're using twice: one or the actual array, and one for the script because I have no way of getting the actual number in the array.
- Movers can now cycle between different waypoints. Does not return to start position though
- Portals now implimented. Anything touching it is sent to whatever target gameobject you give it. If you want a two-way portal system, rather than a one-way teleport, set the target to another Portal instance and check bEndPortal. bEndPortal needs to be checked because it will send information regarding what is being moved to it so it doesn't immediately teleport the object back to the first portal.
- "Pain volumes" implimented. Pain volumes are configurable objects that can deal pulsing damage based on a timer to anything colliding with them. For lava or otherwise insta-gib, decrease the timer to zero and increase the damage to something absurd.
Pain volumes have a damage duration timer, meaning you can have a timer until it damages, and a second timer that controls how long the window is open for something to be damaged. Whenever something is damaged by a pain volume, it's added to a list, and anything inside this list will not further be damaged by the pain volume. The end of the duration timer resets this list.
A third timer is the offset timer. This is a delay before the main damage loop starts, and is intended so that you can have many instances of this volume - as a gyser, for example - and have them all going off at different times, but at the same loop speed.
4:04 PM 2/9/2014
v1.4:
- Changed "activateMe" to "Activate", because it'd be easier to change the tools on my end than figure out what would break on Eugene's.
- Triggers now can be player-activated only. Because it's annoying to have bots offscreen change your spawn points.
- Triggers now support having multiple targets.
5:28 PM 2/11/2014
v1.5
- Movers can now deactivate at each stop, or cycle through them. (bConstantMove = true)
- Movers can now go through a complete cycle before stopping. (bDeactivateAtEnd = false)
- Rather than going through the trouble of setting up movers to use as resetable falling platforms, I just made a simple falling platform script. You just throw in the distance you want it to fall, and when triggered, it stutters, then falls. It comes back on its own, though you can configure it not to (bNoReturn).
11:02 AM 2/16/2014
v1.6
- Movers no longer move when game is paused.
- Movers can push characters away. (Eugene)
- Movers optimized slightly in that you don't have to set the number of targets twice. Most things no use this method, and can have multiple targets.
- Timer implimented. This is mostly intended to be used to help in offsetting things - such as having enemy spawners be able to spawn at different times - but can also be used to delay anything from being activated.
- Counter implimented. This records every Activate impulse sent to it, and once that reaches a customizable number, it activates another target. This is generally how you'd handle levels where you're required to kill x number of enemies; the spawners would send an Activate impulse to this once their spawns were all killed, and once those were handled, this would Activate an EndRoom object. MAKE SURE ANYTHING THAT SENDS TO THIS ONLY TRIGGERS ONCE.
- EndRoom implimented. Level devs now have a way to directly move from one room to the next by simply sending an Activate impulse to it. I named it EndRoom rather than EndLevel because "level" is a word that has multiple meanings in this game (it's referred to both as the play area and the thing you need to accuire to win the game) and I wanna reduce confusion.
- Destructable objects in. This is very much a hacked-together thing, and unlike everything else, isn't just a script you can throw on an object to make it work. Destructable objects are literally handled as an enemy, and have to be set up as such, then with this script on top of it.
I took the liberty of making them shake when hit, as a visual affordance that attacking it does something.
9:48 AM 2/17/2014
v1.7
- "Splitter". Nodule that when an enemy passes through it, it differentiates what player hit it last, and sends an Activate impulse to the target in that slot. In other words, it activates different things based on which player hit the enemies that pass through it.
- Counter script now has the option to have a visual component. Throw textures at it, and it'll start with the first texture. (Will overwrite normal textures on it.) Every texture past that will be changed to each time the counter is triggered.
- Stutter effect now repeatable for movers. Once they hit the end of the line, if they loop, they'll turn stutter back on again.
- Chest script done. Needs two box colliders - one set to be a trigger, and one without. One will block the player, the triggering one will record when and by who it gets hit. When a player smacks it three times, it'll pop up a little "+XP" thing, give the player who hit it XP, and despawn. Uses ItemXP instead of GiveXP, specifically because GiveXP gives 25% of that exp to everyone else.
The chest you want to use is GrindChest. The other chest object is being retarded and I'm stuck in a situation where I can't do anything to it, so I made a prefab of it, but the new prefab uses the meshes in the old one, so not sure what to do here.
- Destructable wall fixed to not need other scripts to work; Eugene's iteration not needed.
- Death trigger. When it takes damage, it sends an activate pulse to everything in its list. Useful for levels with obstacles and lava; when the lava rises, it could take out this object, which could move to another spawn, so players won't use the previous one that would drop them in the now-higher lava.
- Falling platforms. Are a simplified mover, and just fall straight down by a configurable amount when triggered.
- Music box. Drop a song in it and it'll play that song when the level loads. Basic for now.
- temporary "popup" scripts. Literally just for showing when something is receiving bonus exp or losing it in a non-conventional manner (read: Snatcher syphoning it.)
11:56 AM 3/7/2014
v1.8
Triggers and most objects capable of sending an activate impulse now have visual representations in-editor; they draw green lines to the things they're connected to.
5:40 PM 1/21/2014
James Ensley
Added:
- Retooled pressure plates so you could throw an object at them in unity, rather than have to monitor
their progress in the level script. You can now do either. This is intended to ease level design, and make
things a lot more plug-n'-play. Currently the only thing this modifies is movers.
- Added movers. Movers require a target, and this target can be anything. When the timer runs up, it'll start
moving towards the target at the speed you set. "stuttering" is for a visual affordance to players that the object
is about to move.
I'm calling them "movers" rather than just "wall movers" as originally intended, because they can be used in any direction.
Note that if it's too fast, or moves too far (hence stutterMaxDist) it /will/ clip right through players and enemies,
and there's not much I can do about that.
To use pressure plates, just make a primative (or, later, do this with a mesh), throw the Pressure Plate script
at it, then make sure "Is Trigger" is checked in the Box Collider component. Movers
Anything with bActive == false does not activate or do anything until it bActive == true. Pressure plates are
currently the only way to activate an object with bActive set to false, though you could also do so in level
scripts.
5:48 PM 1/23/2014
- Renamed "pressure plates" to "triggers", to reflect that their functionality is for internal level development. You can still use them
as pressure plates, of course.
- Triggers now can trip only once, if needed.
- Made "Spawn switcher"s. Throw your player spawns into it in the order you want them to be used, and have triggers target it. Each time a
trigger activates it, it sends the next player spawn in the list to the scene manager. Need to have the triggers only hit once!
6:04 PM 1/25/2014
- Added tool for throwing text on screen. Use triggers to change from one line to the next. Extremely basic, just for quick playtesting.
- If triggers have a sound attached to them, they play when triggered.
7:19 PM 1/28/2014 v 1.2
- TextToScreen tool now has nearly every variable inside it exposed, so you can put it wherever the hell you want.
- Triggers now /should/ have weight limits (untested). If weightLimit is set to anything above zero, the combined charMass of everything touching it needs to be equal to or above weightLimit to trigger it.
4:08 PM 1/29/2014 v1.3
- Movers now truncate position and stop on the aimtarget they're aiming towards, and then deactivate.
- Movers can have one impulse to trigger or many; once activated, they ignore further impulses until they reach their next waypoint, at which point they snap to it and deactivate. Another impulse at that point will turn them back on, and they'll move to their next waypoint. For this reason I'd highly recommend any trigger that triggers them be one use ONLY if you are absolutely certain it'll be at a complete stop when triggered - otherwise the level might be broken and they'd have no way to get the mover moving again.
- Movers now support multiple targets, and effectively have a wapoint system. But it's a little wonky - you have to tell it how many targets you're using twice: one or the actual array, and one for the script because I have no way of getting the actual number in the array.
- Movers can now cycle between different waypoints. Does not return to start position though
- Portals now implimented. Anything touching it is sent to whatever target gameobject you give it. If you want a two-way portal system, rather than a one-way teleport, set the target to another Portal instance and check bEndPortal. bEndPortal needs to be checked because it will send information regarding what is being moved to it so it doesn't immediately teleport the object back to the first portal.
- "Pain volumes" implimented. Pain volumes are configurable objects that can deal pulsing damage based on a timer to anything colliding with them. For lava or otherwise insta-gib, decrease the timer to zero and increase the damage to something absurd.
Pain volumes have a damage duration timer, meaning you can have a timer until it damages, and a second timer that controls how long the window is open for something to be damaged. Whenever something is damaged by a pain volume, it's added to a list, and anything inside this list will not further be damaged by the pain volume. The end of the duration timer resets this list.
A third timer is the offset timer. This is a delay before the main damage loop starts, and is intended so that you can have many instances of this volume - as a gyser, for example - and have them all going off at different times, but at the same loop speed.
4:04 PM 2/9/2014
v1.4:
- Changed "activateMe" to "Activate", because it'd be easier to change the tools on my end than figure out what would break on Eugene's.
- Triggers now can be player-activated only. Because it's annoying to have bots offscreen change your spawn points.
- Triggers now support having multiple targets.
5:28 PM 2/11/2014
v1.5
- Movers can now deactivate at each stop, or cycle through them. (bConstantMove = true)
- Movers can now go through a complete cycle before stopping. (bDeactivateAtEnd = false)
- Rather than going through the trouble of setting up movers to use as resetable falling platforms, I just made a simple falling platform script. You just throw in the distance you want it to fall, and when triggered, it stutters, then falls. It comes back on its own, though you can configure it not to (bNoReturn).
11:02 AM 2/16/2014
v1.6
- Movers no longer move when game is paused.
- Movers can push characters away. (Eugene)
- Movers optimized slightly in that you don't have to set the number of targets twice. Most things no use this method, and can have multiple targets.
- Timer implimented. This is mostly intended to be used to help in offsetting things - such as having enemy spawners be able to spawn at different times - but can also be used to delay anything from being activated.
- Counter implimented. This records every Activate impulse sent to it, and once that reaches a customizable number, it activates another target. This is generally how you'd handle levels where you're required to kill x number of enemies; the spawners would send an Activate impulse to this once their spawns were all killed, and once those were handled, this would Activate an EndRoom object. MAKE SURE ANYTHING THAT SENDS TO THIS ONLY TRIGGERS ONCE.
- EndRoom implimented. Level devs now have a way to directly move from one room to the next by simply sending an Activate impulse to it. I named it EndRoom rather than EndLevel because "level" is a word that has multiple meanings in this game (it's referred to both as the play area and the thing you need to accuire to win the game) and I wanna reduce confusion.
- Destructable objects in. This is very much a hacked-together thing, and unlike everything else, isn't just a script you can throw on an object to make it work. Destructable objects are literally handled as an enemy, and have to be set up as such, then with this script on top of it.
I took the liberty of making them shake when hit, as a visual affordance that attacking it does something.
9:48 AM 2/17/2014
v1.7
- "Splitter". Nodule that when an enemy passes through it, it differentiates what player hit it last, and sends an Activate impulse to the target in that slot. In other words, it activates different things based on which player hit the enemies that pass through it.
- Counter script now has the option to have a visual component. Throw textures at it, and it'll start with the first texture. (Will overwrite normal textures on it.) Every texture past that will be changed to each time the counter is triggered.
- Stutter effect now repeatable for movers. Once they hit the end of the line, if they loop, they'll turn stutter back on again.
- Chest script done. Needs two box colliders - one set to be a trigger, and one without. One will block the player, the triggering one will record when and by who it gets hit. When a player smacks it three times, it'll pop up a little "+XP" thing, give the player who hit it XP, and despawn. Uses ItemXP instead of GiveXP, specifically because GiveXP gives 25% of that exp to everyone else.
The chest you want to use is GrindChest. The other chest object is being retarded and I'm stuck in a situation where I can't do anything to it, so I made a prefab of it, but the new prefab uses the meshes in the old one, so not sure what to do here.
- Destructable wall fixed to not need other scripts to work; Eugene's iteration not needed.
- Death trigger. When it takes damage, it sends an activate pulse to everything in its list. Useful for levels with obstacles and lava; when the lava rises, it could take out this object, which could move to another spawn, so players won't use the previous one that would drop them in the now-higher lava.
- Falling platforms. Are a simplified mover, and just fall straight down by a configurable amount when triggered.
- Music box. Drop a song in it and it'll play that song when the level loads. Basic for now.
- temporary "popup" scripts. Literally just for showing when something is receiving bonus exp or losing it in a non-conventional manner (read: Snatcher syphoning it.)
11:56 AM 3/7/2014
v1.8
Triggers and most objects capable of sending an activate impulse now have visual representations in-editor; they draw green lines to the things they're connected to.
Wednesday, February 5, 2014
Recap and update
Over the break I designed the functionality and designed the enemies. I based them on behaviors that would compliment gameplay, and provide interesting gameplay.
Also over the break, and during the first week of the quarter, I tested and attempted to implement an A* method of pathfinding that would simplify things and enable every enemy to be able to navigate any level that was designed without having to re-tool the enemies later. Unfortunately this particular method proved massively taxing on the engine, and the significant loss of framerate was not worth the trouble, and the method was scrapped.
During the first and second week, I began constructing enemy behavior by hand instead, using raycasting methods to determine collision and obstructions in front of and beneath the enemies. The first basic enemy was the end result.
During the second week, I began adding functionality and began implimenting the Hopper's behavior. Around this time my computer's screen gave out, and for the next three weeks I had to code strictly at SCAD, for lack of better alternatives.
During the second and third week, I began constructing little scripted tools for the level designers. My intention was to give the functionality that was needed for gameplay elements without them having to actually need to code anything themselves. I built a mover system, a basic "text to screen" tool, a method of updating player spawns (to allow spawn checkpoints), and an expansive trigger object that could allow a lot of situational solutions to whatever was required.
After the level tool kit was completed, I have since spent this week and the prior one refining the AI, and finishing the Hopper enemy's behavior. As of today, the Hopper's functionality is fully coded and awaits testing. And because the enemy architecture now fully exists, the other enemies are quickly following suit; the Juggernaut (and, by extension, the Snatcher) are almost fully coded, and I expect the rest of the enemies to be playtest-ready by the end of the week.
Also over the break, and during the first week of the quarter, I tested and attempted to implement an A* method of pathfinding that would simplify things and enable every enemy to be able to navigate any level that was designed without having to re-tool the enemies later. Unfortunately this particular method proved massively taxing on the engine, and the significant loss of framerate was not worth the trouble, and the method was scrapped.
During the first and second week, I began constructing enemy behavior by hand instead, using raycasting methods to determine collision and obstructions in front of and beneath the enemies. The first basic enemy was the end result.
During the second week, I began adding functionality and began implimenting the Hopper's behavior. Around this time my computer's screen gave out, and for the next three weeks I had to code strictly at SCAD, for lack of better alternatives.
During the second and third week, I began constructing little scripted tools for the level designers. My intention was to give the functionality that was needed for gameplay elements without them having to actually need to code anything themselves. I built a mover system, a basic "text to screen" tool, a method of updating player spawns (to allow spawn checkpoints), and an expansive trigger object that could allow a lot of situational solutions to whatever was required.
After the level tool kit was completed, I have since spent this week and the prior one refining the AI, and finishing the Hopper enemy's behavior. As of today, the Hopper's functionality is fully coded and awaits testing. And because the enemy architecture now fully exists, the other enemies are quickly following suit; the Juggernaut (and, by extension, the Snatcher) are almost fully coded, and I expect the rest of the enemies to be playtest-ready by the end of the week.
Saturday, November 16, 2013
Tuesday, November 5, 2013
Sunday, October 27, 2013
Second Week of Development
This week I have begun expanding the AI I have created by investigating an A* path finding package for unity.
Afterwords I worked together with Eugine to merge his scripts and mine into a cohesive whole. Whereas he focused primarily on the movement and physics, I focused on the controllers, and set up the basic AI to work with his work. Now that the AI is working and multiplayer functions, we have a prototype.
Afterwords I worked together with Eugine to merge his scripts and mine into a cohesive whole. Whereas he focused primarily on the movement and physics, I focused on the controllers, and set up the basic AI to work with his work. Now that the AI is working and multiplayer functions, we have a prototype.
Subscribe to:
Posts (Atom)