CaseyHardman

Members
  • Content count

    356
  • Joined

  • Last visited

Community Reputation

2765 Excellent

About CaseyHardman

  • Rank
    Crossbones+

Personal Information

  • Interests
    Art
    Audio
    Design
    Education
    Programming
  1. WoA V - The Competition Thread

    Sorry to say it, but I'm going to have to pull out on this one. Final update explains it well enough, so I'll just link that here. Good luck to those who are still trucking away!
  2. WoA V - Update 3

    While I have made a lot of progress, I ultimately had to decide not to enter the project. As I'd feared, time got a little out of control. There's too much stuff left to wrap up before the deadline (and I'm already losing sleep). I don't want to enter something that doesn't feel like a proper game experience. The poor judges have to play it, after all! If I'd started on time, I might've had something vaguely passable by now, but I only realized the Week of Awesome had started after the first 2 days passed... I'm still rather surprised by how quickly I managed to implement what I made so far, and how quickly it started to feel fun when the knights started swinging and the particle systems came into play. I did promise screenshots, so here are some knights on a backdrop of rather crude "castle-themed" art (and Unity's default skybox...): Not sure if I'll end up using them for anything, but we'll see. They're not technically animated; they just bob up and down 1 voxel at a time, and their arms are separate game objects that pivot at the shoulder to chop down with their weapon. I'd wanted to try a project similar to this one for a while (3D, over-the-shoulder shooter with no up/down aiming, just straight shooting, and an arcade-y style), and the fire under my ass caused by a tight deadline really got me iterating on it quickly. While I am a bit disappointed that I couldn't put out something to be judged and played, I did learn and stretch my game dev muscles a lot. There's always next year, after all! I look forward to seeing what everyone created, and good luck to all the participants!
  3. WoA V - The Competition Thread

    Quick update. Hopefully I'll get some screenshots and a third update by tonight.
  4. WoA V — Update 2

    I've got my first day off since I started working on the project. Started early this morning, got bullied a bit by my laptop arbitrarily and suddenly restarting, cursed a little, got over it, and spent some time on art. I've got about nine and a half hours clocked into the project so far. Since yesterday, enemies are swinging swords and running after you, falling (knights are subject to gravity, too, after all), and knocking you away and hurting you with their swings. You can shoot them to kill them (which still causes them to awkwardly disappear for now). I'm working on getting the art into the game and ready to go. Too much fooling around with enemies when the art isn't in the game yet is just going to end up wasting time when I have to go through and switch values around because nothing is sized appropriately. I still need archers. Lancemen might get the axe...quite literally, because I'm planning on implementing healthier, stronger, slower, axe-wielding soldiers in their stead, which knock you harder and have a larger weapon/hitbox. I'm not much of an artist, but I'm doing my best with my voxels... Although it's all looking a little crude, I don't really have the time to putt around with it. I'm happy with the scale and style I have, for now. I've got the player model in and I'm working on getting the soldier model in. Simple, flat colors with a blocky style. Might not be the prettiest or most impressive, but hopefully it'll get the job done. Trying to make sure the entities (player and foes) have a brighter palette, and I plan on giving the castle parts a darker palette so the entities contrast well with it and read easily. When things are a little further on, I'll post some screenshots where it's all together, in-game. I'll be working on getting most of the art in today, with proper player death and respawn. I've decided to make levels in separate scenes, give the player 3-5 lives per level, and reload/reset the scene if they lose all their lives. After that, I'll try to get a nice tutorial in with some explanations of the mechanics. Lots of core stuff to do, not a whole lot of time to do it. We'll see how it goes. If anything, we'll throw audio under the bridge and end up with another soundless game. I hope it doesn't come down to that, but I'd rather lose a possible 1-10 points on audio than lack mechanics, art, polish, and a nice tutorial.
  5. WoA V - The Competition Thread

    My first update, with progress and a rundown of the vision for the game.
  6. WoA V - Update 1

    I decided to see what I could make up for the Week of Awesome V here on GameDev.net. My time is rather limited by work, and I came to the party a few days late, but we'll see what I can rustle up. So far, I've put a little under 5 hours into the project. I'm off Saturday and have a shorter shift on Sunday, so I'll be trucking away to try to wrap everything up on those days. It's just me participating. I'm using Unity3D with C#, MagicaVoxel for art (if you can call it art), and probably BFXR for sound effects (if I can get to it). THE VISION I've chosen the themes "Castles" and "Alien Invaders". The game is a 3D, voxel-based over-the-shoulder shooter, with simple WASD/arrow-key movement and mouse-based third-person aiming. You fly a little alien hovercraft to invade a castle, slaying the little knights and their contraptions, left-clicking to shoot. It's a small invasion; why send more than one alien when you're so technologically advanced? While your camera will let you look up and down, your shots always come out of the front of the hovercraft, instead of angling up or down with the camera. This gives it a simple, arcade-y feel. I plan on implementing three different kinds of enemies: Swordsmen move towards you and swing their blades at you, dying in 1 hit. Lancers keep further distance, throwing arcing spears at you and dying in 2 hits. Archers keep as much distance as they please, firing true-flying arrows at you from afar. If I can get to it, I want to implement...: Trebuchets or ballistae. Medieval siege weaponry that swivels on the ground, rotating but never moving, aiming towards the player and periodically firing fat, slow projectiles that throw the player and even the nearby enemies away and deal damage. Destructible castle mechanics. I'd like to design levels such that the player must blow holes in walls and go through them to reach new areas, and may carve their own path to the interior of the castle. PROGRESS SO FAR Scrambling to implement stuff I've probably implemented a hundred times in Unity before, I've got: - Third-person camera that slides along walls and has some light smoothing applied. All that good stuff. - Hovering. The player model (currently a large cube) is suspended above ground and smoothly maintains the same height above ground while going up or down slopes. I want to make the player overshoot the hover height if they land with high velocity, then bob up, and possibly tilt a little during it, because it all looks very stiff right now - but that's one of those polish features I'm not going to focus on until I know I can get the core mechanics down in time. - Basic shooting for the player (hold left-click to keep firing; projectiles travel straight forward until they hit something or expire). - Basic enemy following AI, health, and death. They alert to the player if they're close enough, and try to keep the player within the desired range (lancers want about 10-15 feet, swordsmen want melee range, and archers will probably be standing still at all times). Tomorrow, I'll try to make good use of 2-4 hours to get some art going, take some screenshots, and get the enemies dealing some good old fashioned Medieval hurt to the player. If core mechanics can be wrapped up nicely tomorrow, I'll have Saturday and Sunday to focus on content, polish, a tutorial, and audio. Time is pretty short, so we'll see how it goes. I participated in the Week of Awesome III and ended up with a game that had no audio and wasn't quite as well-explained as I wanted it to be. I'm hoping this time around I can temper the scope and crack the whip (at myself) enough to get something finished.
  7. Week of Awesome V - Administration Thread

    Found out yesterday that this was going on. I enjoyed participating in WoA 3, so I think I'll see what I can come up with this time around. Time is a bit limited by work, but I'll try to design around it. Hopefully this time I can get around to including audio... Quick question. I see the Submit form on the site has a box for a description. Do the judges read this for info on controls and such, or is that expected to be detailed in-game? For example, if there is no in-game tutorial or explanation of mechanics, but everything is described sufficiently in the description box, would that still result in a poor FTUE score?
  8. I've always had this question and can't seem to find it directly addressed.   For a 3D first-person game, I'm making simple, old-fashioned crosshairs made of 4 small lines, like in Counter Strike and whatnot.   I was going to make every line draw at the center of the screen, offset away by an amount determined by the weapon accuracy.  Your usual crosshair stuff. I just never knew how to turn the accuracy into an offset value: should I use a percentage of the screen size, or a flat number of pixels?  Or something based upon in-game units?   What I'm concerned about is, will players with higher resolution or a higher field of view have more or less bullet spread compared to other players if I base the measurements on pixels or percentages of the screen? For example, if two players fire with the same accuracy, straight at a wall the same distance from them, but one player has a massive screen resolution and 90 field of view, while the other has a small resolution and 60 field of view, will there be a significant difference in where their bullets land on that wall?
  9. Need resources about movement, velocity, vectors...

    The Unity manual has some basic teaching on vectors here, most of which could probably be applied to SFML as well.
  10. Week of Awesome III - Servant's reviews of all games

    Hi Servant, thanks for the review (of Soulwielder).     Just curious, what control scheme were you using?  WASD for movement/aiming and J for jumping, or arrow keys for movement and aiming and Z for jumping?   This is sort of off-topic, but I designed it with these two control schemes because I figured left-handed people might be more inclined to do the movement with their left hand, and the jumping and shooting with their right, while it might be vice versa for right-handed people.  I'm not really sure if the WASD one feels as good as the arrow-keys one, though.       You can get in and out of the 'pit'.  The ground is the same level on the left and right side of the cliff (in the pit and outside the pit, that is).   You're supposed to jump-dash up to get onto the big cliff, then fall down and kill those monsters in the pit, then go back up the cliff and jump the platforms to kill the other monsters at the right edge of the level, winning the level.  The ones at the right side were supposed to be a sort of distraction to trick you into letting more demons spawn in the pit...(not a great idea, I'll admit).   So it's not necessary to restart the level, but I can definitely see why you'd think that. That cliff is about the tallest you can jump onto, and it ended up being a lot trickier for others than I thought it would be. The key is to jump and hold the jump key, then dash up very shortly after jumping.  If you aren't holding the jump key until you start falling instead of going up, then you won't get enough height.  You can hold Z or J down while midair to get extra height so long as you're not falling yet, which I'm now realizing is kind of stupid (as well as unexplained).  Maybe I should limit that to a certain amount of time you can do it after initiating a jump?   After seeing how badly the jumps went over, I realize I need to re-design the highest jumps and make performing them a bit less meticulous and obscure.         The goal was sort of to make it so that you had to clear villages quickly, and possibly have to die a few times while you learned where the demons are and figured out the best way to go about killing them without letting too many spawn in a specific place.   I didn't want it to be a decision of "should I grind at killing this horde of demons for 15 minutes, or should I just restart the damn level and try again?", because you were supposed to actually be capable of dying to demons...but since they're so easy to avoid, it's not really the case, so it's not a matter of fighting to the death, it's just giving up and restarting the level.   If you're experienced and quickly kill the demons off, you can win all the levels in about a minute and thirty seconds.   However, if you're new or aren't operating very fast, the demons amass somewhere off-screen while you're killing other ones, and then you have a 3-minute ordeal just to kill one clump of demons. Or, in your case, the demons in the pit amass while you struggle to get over the cliff...   You're absolutely right about the game needing more variance and player decisions.  I think if I'd gotten those extra enemy types in (there were supposed to be more than just the 'goblins'), it would have ended up making fights more varied and less of a boring grind.     Yeah, the background is a very tall, subtle gradient from one bluish color to another... Background art wasn't in the time budget, unfortunately.  The last level I made was the second level, which I got in at the last hour of the competition.   Just a tragic tale of lack of time, unfortunately.     I was going for the souls being the main way the mechanic is implemented: they are generated from the death of humans, and they are useful to the player because the player heals from them and can use soul blasts, and they are useful to the demons because they turn into more demons.   I suppose it's not very 'thickly' implemented, though.     Anyway, thanks again for the review and sorry the game turned out such a mess, hah!
  11. Week Of Awesome III - The Afterparty/judging thread!

    Part 2 of my postmortem is up, this time about the development of the game: finding the art style and dealing with the technical problems that cropped up. Calling it short would be a lie bigger than part 2 of my postmortem.
  12. This is part 2 of the postmortem for the Week of Awesome game I made called Soulwielder. This is about the development of the game; the first part was about the design of the game. There were several things that daunted the creation of Soulwielder, notably the difficulty I had with making art, the level-creating tool I made, and the physics/collisions system I made. Art I started out trying to make the player with a higher resolution than I ended up with, and about 3-4 heads tall. He didn't look awful in the still version, but oh boy, when I started trying to animate him... I technically had never even dealt with animation, especially not 2D animation. I don't know why I was so confident I could make 5 sprites with animations considering this. The walk animation looked about twice as bad as you'd expect someone's first walk animation to look. After about five different attempts at making his walk look good, I went to bed; before I fell asleep, I thought I ought to take look at the art of Cave Story for help on the animation. This is where I got most of my inspiration for how the art of the sprites ended up. I popped the game open and looked closely at the player and his walk animation. The player was far from 4 heads tall in Cave Story, and his legs were actually so hard to see moving that I had to beat the first cave to get to an area where there was less rock and dirt poking up getting in the way of his feet. The most noticeable part of the animation was his bobbing up and down, not the legs at all. It was simple, but readable, and it worked very well for that style of art. When I adamantly played through Cave Story twice in a row a while ago, I didn't question how my character walked on legs that seemingly start 90% of the way down from his head, or look intently for his feet to see if the motions they were making looked like those you would actually take to walk. I just saw him bob up and down and thought he was walking. I also noticed that a similar method I planned on using for Soulwielder was being used in CaveStory (I think, don't quote me on that): sprites were made in a small size, then scaled up in a pixel-perfect way to make them bigger and more readable, but maintain their sharp, pixelated, blocky style. If you double the size of the sprites (I think this is what is done in Cave Story), then every pixel is made of a square of 4 pixels of the same color, but you don't get to use those extra pixels; you stick to the constraints of the pixels you have at the lowest size, never changing the scaled-up version of the file. For me, the size was 16x16, scaled up 2x to 32x32. I liked the player best this way. Ultimately, he ended up less than 2 heads tall (10 pixels of head and helmet, 6 pixels of body and legs). His walk animation was a single frame, where he lowers down a bit and his one-pixel-tall, two-pixels-wide feet go out at his sides and become two pixels tall and one wide. "This looks stupid," I believe I remember thinking before seeing it play. "He doesn't look like he's walking at all, it just looks like he's spreading his legs out and shrinking". But I put it in Unity and gave it animation, and it read well and it looked nice and stylized. I liked it a lot after seeing it play. Here he is, sized up to 8x for easier viewing: Now, I'm not saying the art of Soulwielder is objectively great...I suppose I'm just saying it is relatively great compared to my first walk animations... Once I got the player's running, looking-up, looking-down-while-midair, etc. animations in-game and working properly with the movement and aiming controls, I felt pretty glad with how he turned out. Ultimately, I ended up making the humans and the 'goblin' in a similar way, with similar walk animations. Everything else is also made in some format similar to 16x16 and then sized up twice, from the flowers to the grass-and-dirt tileset and the bricks used to make the humans' houses. The buildings don't look great; I would've liked to have made a roof tile tile to add at the top of them, but time didn't really permit it and I knew I'd probably need a good bit of time to get it right. So I just made the buildings out of one seamless square tile found from SpiderDave on OpenGameArt, somewhere within the depths of the many tiles he posted here. Unfortunately, background art didn't make it in, either; I just threw a vertical gradient into the background because time was running out and at least the gradient looked a little better than using a single, flat background color with the camera setting. Here's a little screenshot where almost all of the environmental assets can be seen, as well as some of the goblins and the player: The Environment Editing Tool Now we enter the programming-related issues I faced. I thought I'd be making a platformer with low-res graphics for the Week of Awesome, because I found nice-looking resources for the environment on OpenGameArt.org, and I wanted to make a game like that. So I figured I could prepare for it well by creating a little Unity script that could place down sprites to make the game's levels. It was one day before the competition that I started on this. I wanted it to let you select a sprite in the Project view and place it in the Scene view by clicking. I didn't want it to just throw down a bunch of sprites and organize them as children of the GameObject with the script, though. I wanted it to be able to 'bake' the sprites into 1024x1024 textures and arrange them on a grid covering the whole map. This would be more efficient, I figured; when I inevitably got carried away with the placing of flowers later, I wouldn't have 90 different sprites in one area, each with their own GameObject, when I could have one with all of those sprites built into it. I'd dealt with this sort of code in a game I was making before the compo, called Realm Crawler, where I had dungeon generation that made the dungeons by drawing tiling textures onto a grid of textures, so that each e.g. 8x8 or 16x16 tile of the dungeon didn't have to be a separate sprite, which would be a massive number of GameObjects and sprites. It involved turning a world position of a pixel into its local position in a texture, based on where that texture was. The creation of this tool took longer than I'd anticipated, of course; I didn't manage to whip it up in one day, although I got a lot of planning and thought through the most difficult parts of the code in that day. So I was making this tool during the competition, which was unfortunate and all. It took a few days to get it right, I think (it's a bit of a fuzz of confusion and mild panic), but I didn't devote that time entirely to it; I also planned and designed during it. The tool was a bit hackneyed and annoying to use, but I'd expected as much. Rather than trying to make it as an editor script, I decided to make it a normal script, which means it only operates in-game. You put down a GameObject, give it the environment-editing tool script, and then go into Play mode. You put down your sprites by selecting them in the Project view and clicking to place them. For now, they're just instantiated GameObjects parented to the GameObject that has the script. Before you exit play mode, you copy that GameObject. You then delete the old GameObject and paste the one you copied, to retain the changes you made in Play mode. If you don't remember to copy before you quit play mode, you can kiss goodbye the environment you just made. I did it this way because it's easier to make a script work in play mode than it is in editor mode; that's just something I've always noticed about extending Unity's editor. It has a lot of gotchas that I've witnessed before, but that I wasn't confident I could avoid. It would just be too much trouble to make a proper editor script in a few days. To 'bake' the environment, you just pressed a button in the inspector after exiting play mode and pasting the environment. This button was added by a simple inspector script for the environment-editing tool script. A new GameObject is created in the scene with the textures as children of it, all of which you can set the sorting layers for. If you wanted to put the baked environment in another scene, you'd have to copy-paste the non-baked version over, then bake it there; because the textures I made for the grid were sort of anomalous little mystery textures generated by code, they only survived in the scene they were made in. The miscellaneous issues regarding the baking of maps with this tool lasted a few days into the competition, if I remember correctly, then I got it working pretty solidly. Physics and Collisions The most panic-inducing difficulty I faced is here: physics and collisions. There isn't really a way to use Unity's collision system right out of the box to make objects hit things or bounce off of them, but still retain reliable, highly-specific control over how your entities move. You either use physics with rigidbodies so collisions actually stop objects, which entails apply forces to the object, or you use colliders with kinematic rigidbodies and define your own system for how things stop when they hit objects, or bounce off of other objects or whatever you want. Kinematic rigidbody colliders don't collide with static colliders; they only collide with rigidbody colliders. This means you can't just make an object that isn't subjected to Unity's gravity and physics, but have it actually hit static colliders and bounce back off them, or get affected by them at all. My solution was to have scripts that handled the movement of objects and their collisions by using Unity's various, very-useful Physics2D methods. Everything that wanted to move the object would give this script its movement every frame, and then this script, in its LateUpdate function (to be sure all other scripts had given the movement they desired), it would apply that movement and clear the movement vector. I was planning on making a special one for bats, but what with the startling lack of bats in the game, you can probably see that script didn't end up being made. The only one I made was a GroundedMovement script, for movement of entities subject to gravity. It would determine if you were midair or grounded by box-casting down from the entity, and setting you to grounded if there was ground there, or midair if there was no ground there. When you became newly grounded or newly midair, it would call a delegate that other scripts could add functions to, to detect when grounded happened. The player used the landing one to reduce the sideways velocity by half so you wouldn't slide so much after you landed. It used the Physics2D.BoxCast method to check for walls and ground. I separated the walls and ground into two different colliders and had the midair BoxCast only detect walls. That was not a very good idea. The reason I thought this was a good idea was because the box cast was given a direction of movementThisFrame.normalized and a distance of movementThisFrame.magnitude, so I couldn't figure out how better to distinguish between ground and walls. I thought of making it detect if what you hit was ground (and thus you should be grounded) by checking if your movementThisFrame.y was negative (meaning you're falling down), but that wouldn't work if your side hit a wall while falling; you'd become grounded instead of bouncing off. I thought the only way around this was to just commit to using a completely mad setup for colliders where you use one collider for the ground, or anything you could stand on, and a separate one for the walls, or the things you can't stand on and bounce off of instead. The midair movement would box cast along your movementThisFrame.direction with movementThisFrame.magnitude, as usual, and only detect wall-type colliders. When you hit a wall collider, you had your X velocity altered to bounce you back based on your 'bounciness' multiplier. A separate box cast would check beneath you for ground, and make you become grounded if there was ground down there. If I was smart, I probably would've made this only happen if you had negative Y velocity, so you didn't just suddenly become grounded while shooting upwards if you happened to be above a ground collider during that, but I probably didn't do that... The problem with this was not only that I had to set up the scenes with plenty more colliders, but also how carefully you had to set them up. If the player falls on a wall-type collider, they get stuck on it, as they aren't losing their negative Y velocity, so they keep falling down onto it. There was a way to wiggle out of this with midair movement and dashing, but of course, we didn't want that very disruptive glitch in our game. If I put the wall collider too high up, the player would land on it instead of the ground (and we already discussed how fun that was). If it was too low, so that the top of it was under the top of the ground collider, bad things could happen. You would get caught on the top of the wall if you approached it from the side, and then you'd usually just end up getting slowly scooted over until you were inside the platform, eventually taking you off the wall collider until you were falling forever down with no ground to catch you, essentially ending up in the Twilight Zone. I could've avoided this by using a single wall collider the whole width of the cliff/platform, but for some reason I thought using one on each wall was better - and that would have just been making things less bad, not making things function properly. Another very significant problem was how it reacted when you didn't bounce hard off of walls, but rather, moved into them with low sideways velocity. For example, if I stood at the foot of a wall, jumped, then started moving sideways midair, then I'd get stuck on the wall; the X direction added to the box cast would point the box towards the wall, causing it to hit, and then you'd be placed at the centroid instead of going the full Y distance you had, so you'd get stuck or manage to gradually go more and more up, letting you scale walls just by pressing yourself against them. The enemies would do this; they'd vault past you if you jump over them, then they'd fall off the platform, then just scoot back on up and come after you again. It was August 15th, very early in the morning (I go to bed at about 7:00 AM and get up after noon the same day, so this was late into my day cycle) when this issue was finally resolved, near the time I went to bed. I thought I was utterly done for, and that my game would have to be a single-platform game where you fought the demons on a flat village with no jumps. I finally found the solution near 5:00 AM or so. Rather than box casting along 'movementThisFrame.direction' by 'movementThisFrame.magnitude' distance, I just had to box cast once for the X, and once for the Y. The X box cast would go straight left or right, the Y box cast would go straight up or down, and their distance would be movementThisFrame.x or y. I'd cast them both against a single, holy layer, called "Environment" or "Solid", the only layer I used for the environmental colliders. The sideways box cast would cause the X velocity to be 'bounced' if it hit something, otherwise it would move your X by movementThisFrame.x normally. The vertical box cast would cause you to be grounded if it hit something and the movementThisFrame.y was negative. There was on risk of hitting the side of a collider while falling like this, because the box cast would go directly down, not along the movementThisFrame.direction. It would cause you to bump your head if your movementThisFrame.y was positive. This was the same as hitting your side against something, but your Y velocity got bounced by it. This worked wonderfully. It felt quite good to be able to put a collider down and have it act as a ceiling, ground, and walls all at once, without meticulously adjusting two different collider's edges only so things could work sometimes. This fix was probably the only reason the project ended up coming through; if I hadn't found a solution to this, I probably would've ended up making flat levels so the walls wouldn't be a problem, or if I didn't make such a compromise, I probably would have not submitted the game in time. I could also set the bounciness to 0 so the player only loses their velocity upon hitting a wall, rather than having it redirected backwards. I believe Cave Story does something like this; you can jump into a wall, rub up against it as your jump carries you higher, get over the top, and then keep going to stand on the top of it. This is a bit more comfortable, but I'm not sure if I like it for Soulwielder yet. The bouncing ended up in the final build, although I may change it later after more playtesting. Anyway, that's about all I could say about the woes I faced during the development of Soulwielder. Seeing the length of this post, maybe I shouldn't have written "about all I could say"... It was definitely not a calm, sunny ride, the physics being the major cause of panic and self-directed mutterings of "I'm screwed", but the game ended up OK, I think: the art looks arguably decent and there aren't any major glitches to the general gameplay. I personally like the gameplay, although it's far too easy (as discussed in the first part of the postmortem), and I'm proud of how much work I dumped into this project in only a single week. I will likely be working on the game more in the future, including updating the environment tool to be less of a hassle to use so I can more easily make levels. I want it to be a little longer and have more enemies and levels. If you're interested in how that goes, you can follow this journal.
  13. Week Of Awesome III - The Afterparty/judging thread!

    I would assume it's probably too late to do this, but just in case...could I write up a readme file for the game after it's been submitted, to clarify on the mechanics I forgot to explain during the tutorial?   It's not changing the game itself, but it is altering the submission after the deadline, so I'm not sure.
  14. Postmortem for Soulwielder

      Thanks for giving it a shot, and sorry you had difficulty there.   That wall should be surmountable by jumping, holding the jump key the whole time to get maximum height, then dashing up or up-right near the top of your jump.   Ideally, to get the very most height possible, you jump, immediately dash directly up (hold W or up arrow key and press space; don't hold any other movement keys!) and keep holding the jump key the whole time.   That's not necessary for the jump at the beginning, though; you should be able to get over that wall even if you dash near the apex of your jump.   Did you know you could hold down the jump key to get more height, and did you know you could dash upwards?
  15. Week Of Awesome III - The Afterparty/judging thread!

    DKoding, if you (or any others) are going to play Soulwielder (my entry), you might want to first check out a short summary of the mechanics in my journal post here, under the bold text "Summary of Gameplay". Because honestly, the in-game tutorial kind of left some stuff out...such as the major mechanic of how souls turn to demons over time...so...oops...   You don't have to read the whole post, of course; in fact, I'd discourage reading all but the summary of gameplay before playing the game.     Thanks in advance for the review!