Show Posts
|
|
Pages: 1 2 3 [4] 5 6 7
|
|
61
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: September 10, 2015, 02:01:08 PM
|
For once, I only have a quick post this time! I just wanted to do a quick before and after with the work I've done today! Before:  After:  Man, I have way too much fun doing particle effects. As always, there's still lots of small improvements that I can make, but for now, I'm loving the difference it makes! I might change up the Way's hit stun animation for a third time actually, as I'm starting to realize that Riff is punching his head more than his gut, so it might be better if the animation for it matched as well!
|
|
|
|
|
62
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: September 09, 2015, 03:38:44 PM
|
I've got the first game development of GODHOOD up!  Besides, that, I've been making more progress on the animations. Before I post any gifs though, I just want to make a bold statement that has totally never been said before and is a completely original concept: Animation is hard.I'll start by saying that I am fully aware that a lot of the animations in the game so far look pretty goofy. Considering I only have a week and a half of animation experience under my belt, I'm actually pretty proud of what I've produced so far! But, obviously, there's still a ton of work left to do. Anyway, all that preamble was to prep you for the very first Way animation added to the game: YikesThe only thing funnier than that animation is the fact that this was my SECOND attempt at it! Looks like this Way is getting good exercise doing a little jig on the spot! In all truth, this is another instance where I recorded myself doing the same action, but I'm guessing the action I was doing doesn't translate to a three frame animation very well. Another funny little note. I thought that since I was finally moving onto animating the Ways, I would have a much easier time since I'm far more comfortable drawing monsters than I am drawing humans. Looks like the trade off is that human proportions don't work for monsters so I can't just record myself an expect things to translate cleanly. Thankfully this animation has been long ditched for the third version that I've done:  Still a little bit goofy, but, the Ways are kind of goofy to begin with so this isn't actually too bad. Maybe in the future I will redo it again along with a lot of the other animations I've done so far, but for now, this will have to do while I crank out other animations. Also added to the game is a hit animation for the Ways as well as another slashing animation for Riff!  This one I'm a little happier with as you can sort of make out the slashing animation (though I might fix one of the frames in there being a little weird). This animation in particular is how it looks if you slash directly to the rhythm of a song, or in other words, slashing to the quarter notes. If I were to slash to the eighth notes, this animation would be much faster. Unfortunately it does look a little bit weird, as it definitely lacks impact. Now, as tempting as it is to just go and add more frames, before I do that, I want to try something that's much more within my realm: Particle effects! I feel like just having a slash effect, something like a ribbon that traces the path of Riff's hand as he slashes, might really make a difference in conveying movement! I have a few other ideas that I want to test as well but it won't be any fun if I just sit here and describe all of them, so I think I'll start working on these effects tomorrow to see what comes out of it Anyway, despite the extreme challenge that animation has provided me, even though I've had a few days where all of the animation I had done had to be trashed, I can't help but feel that I've already learned a lot as it is! There are definitely the finer intricacies of animation that I still need to explore, such as creating an animation that isn't just keyframes but I've refined my workflow to the point that I'm working twice as fast as when I started! While it's hard not to be defeatist over the difficulty of animation, I'm at least driven by my curiosity of how my animations are going to look a month down the road!
|
|
|
|
|
63
|
Developer / Technical / Re: Centering Animation Frames
|
on: September 04, 2015, 05:17:49 AM
|
|
Yeah, I'm starting to get the sense that I'm trying a little too hard to have my cake and eat it too. On Prinsessa's note of having everything on grid, it does indeed look like ShoeBox actually does have an extremely nice utility that takes care of that for me (which is what Polly might have been hinting to me in the first place) so I think I might just settle for that since the more I think about it, the tougher an editor might be.
Anyway, thanks a lot for the help guys!
|
|
|
|
|
64
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: September 04, 2015, 05:13:49 AM
|
Oh nice! It's good to see that you (and possibly others) appreciate the longer posts! I have to admit, from time to time, I've found myself wondering if these huge posts become to exhaustive to read and if I should just convert to the way of "Check out this cool thing: *GIF*." These posts are definitely much more style as they will probably be fun to look back on in the future and I'm practically physically incapable of making non-verbose, rambly posts anyway haha Also, on the art being, to put in bluntly, bad, I've actually been waiting for someone to say it for ages now! I'm still very new at art and I knew this was going to be a problem going in, so it doesn't come to me as a big surprise or anything. I'm actually happy that someone finally said it because it at least means I'm finally getting some honest opinions about my game now beyond showing it to people I knew off the internet and getting slightly awkward praise in the style of "oh yeah, it looks really cool man, good luck!  " Anyway, I would absolutely love to hire an artist, and after a kickstarter, that may very well be a possibility, but it's just not in the cards at the moment. I'm sure this story's been told a thousand times over so I'll spare the details, but in the end, if a kickstarter fails because the art is lackluster, than at least I'll have a lot of time afterwards to develop my skills further (or just save up for an actual artist) during the cooldown time!
|
|
|
|
|
65
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: September 03, 2015, 04:01:20 PM
|
Actually I'm not at all familiar with audio lag calibration, and from a technical standpoint I'd actually be interested in hearing how it works Whenever you play a sound from code, there's actually a minuscule delay, usually only about a tenth of a second for the sound to actually come out. Now, for most games, this doesn't make a very big difference at all, such a small difference in fact that you would barely notice it. For a rhythm game on the other hand, this makes a huge difference, because the entire point of a rhythm game is to be in perfect sync with the sound! A person tapping to the beat of a song can tap within milliseconds of a perfect beat if they concentrate hard enough, but that doesn't work if the computer when the computer thinks it's 150 milliseconds ahead of what the speakers are actually playing! A simple example of the problem: My computer has 150 milliseconds of audio lag, so if I were to tap a beat at the 500ms point in a song, the computer would think I actually tapped at 650ms, even though what I'm hearing is the 500ms point in the song. So, the solution is simple: Simply find the exact audio lag in milliseconds and subtract it from where the computer thinks it is in the song! So in that earlier example, you would take the 650ms mark the computer thinks its at and subract 150ms off to bring it down to 500ms. Then there you go, you're perfectly on beat! The important thing audio lag however is that it's different on every computer. I'm pretty sure on my laptop, it was actually about 170ms, and when the PERFECT timing window is only 60ms in size, a 20ms gap can make a big difference.
While I'm here, I'll say that I also got some more animating done today! Today I decided I would get started on some slashing animations. This one actually took me a lot of attempts and I did eventually bust out the camera to record myself doing it, but I'm getting closer to what I want. I only have one animation done today as I was deciding on which style works best. I have it narrowed down to two styles:  The only difference between the two are the first frame. For the first one, I thought it looked a little bit too rigid, like he was about to give someone an awkward high five. The second one was the one I ended up trying out in game, but I quickly realized that the animation looked extremely spastic. I think I might just redo the frame and go for something sort of in between. As I said, I also already started implementing the slash animation into the game but it definitely requires a little cleaning up. The animation plays much faster in game since it's actually going to a beat so I switched back to the first animation because the second one was so spastic. The first one already looks wacky as it is!  The cool thing about these attacks is now that I have the logic written for these attacks, since every other punch animation uses the same logic, all I need to do is do up more slash animations and then copy paste the logic for them. I have plans for how I want the combos to actually string together but I'll go over that in a later post when I have more art to back it up! By that point, things should at least look a little less flaily. Also, here, check out this first implementation of the slash animation that totally worked correctly and had no bugs at all: 
|
|
|
|
|
66
|
Developer / Technical / Re: Centering Animation Frames
|
on: September 03, 2015, 12:01:43 PM
|
I did notice that feature actually but unfortunately, all it seems to do is pad whitespace onto the original picture so that point you specify as the center becomes the actual center of the image. For example, in the idle animation, when I say the center of the frame is between the character's feet, it produces this image: I realize I can just output the image with a white background but this is much more fun hahaI'm looking for something that gives me the texture coordinates of the center point. For example, a tool where I can mouse over a specific pixel, and in the corner, it would show something like (0.31, 0.035) or something. Again, I'll probably end up making something like that myself! Perhaps I might share it too, but I feel like my case is kind of specific so I don't know how much use it would get beyond me.
|
|
|
|
|
67
|
Developer / Technical / Re: Centering Animation Frames
|
on: September 03, 2015, 09:31:42 AM
|
|
Thanks for the tip, Polly, but Shoebox is super close to what I want but not exactly so. It covers the atlasing part but it doesn't let me specify the center of each frame. I checked the other utilities Shoebox provides quick because at first I thought I completely missed something but it seems the animation utilities it provides all still leave in gigantic swaths of whitespace.
I understand that I'm basically splitting hairs at this point because the whitespace probably wouldn't be that hard to live with, but I just like being nitpicky over how quick I can get these animations out.
|
|
|
|
|
68
|
Developer / Technical / Re: Centering Animation Frames
|
on: September 03, 2015, 08:04:46 AM
|
|
Ooooooh, that actually sounds even better than the editor I had in mind! I can totally see that working, however, I can't say I have much experience with image processing (beyond loading textures) and I'm assuming the auto crop thing is easy to implement in Visual C# which I'm not as familiar with.
So, if you want to make your tools available at any point, I can't deny that I'd be interested! If you don't feel like doing that, it's cool, I'm probably just going to make my own super simple editor(in C++ haha). I thought I would just check and make sure that there wasn't some obvious method or tool that I didn't know about.
|
|
|
|
|
69
|
Developer / Technical / Centering Animation Frames
|
on: September 03, 2015, 05:35:39 AM
|
I've reached a point in my game where I'm starting to animate out the main character and I'm having a lot of trouble finding a easy way of centering different animation frames over top of each other. Right now I'm animating all my frames in SAI and there's no easy way to get pixel coordinates in that program, so it makes things a little difficult. It's also worth mentioning I'm using my own engine for this so I don't have any editors to make these animations with. To describe the problem in a little more detail, I'll use my idle animation as an example. Each frame for the idle animation is a different size because I basically cropped out all of the whitespace for each individual frame. As a result, if I just put all of the frames on top of each other, using (0.5, 0.5) as the center for each texture, the animation looks like this:  Which doesn't look right at all, his feet are going everywhere and his head isn't moving, so it's kind of backwards. After some work, I finally managed to get the true centers of each frame (right in between his feet), which makes an animation like this:  Much better! It was quite the process however and it had to be done for each individual frame because each frame had a different center ((0.31, 0.047), (0.261, 0.039), and (0.234, 0.037)). Here's my current process for getting these numbers: - Load all the frames onto one canvas in SAI and position them over top of each other such that I can find the center point of each frame.
- Draw a red dot on each frame to show where the center is.
- Copy the images back onto their original canvases so that I can save them at their original resolution with the red dot.
- Open up the images in Paint.net and hover over the pixel to get the pixel coordinates
- Convert the coordinates from DirectX to OpenGL (flip the y)
- Convert from pixel coordinates to texture coordinates
The fortunate thing about this process is that I only need to do it once because if I update the texture, I just need to save it and then overwrite the old one and I won't have to worry about any resolution shenanigans or anything. The downside is that this takes way too long to do to be worth it. So that finally brings me to my question: Is there an easy way (some tool I could use or something) to get the centers of animation frames or am I just going to need to make an editor that outputs them myself? Alternatively, am I making this way more complicated than it needs to be and am missing a certain trick that makes this much easier? I know the obvious thing to do would be to just have all the animations properly aligned on the texture instead in such a way that every single frame would just use the same center and the animation would look fine. That's actually what I'm doing for the running animation right now since I didn't have the patience to repeat this process again. This requires every texture to be the same size though and unfortunately leads to a lot of inefficient white space like so:  I could live with this and I'd have to change my workflow as I have a habit of just cropping things right down to a few pixels of padding, but it would be really nice if there was just an easy way to get the centers. Plus it would be great if I decided to atlas the textures in the future and I didn't need to deal with gigantic patches of whitespace on them!
|
|
|
|
|
70
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: September 02, 2015, 12:10:18 PM
|
After two years of development, I've finally begun to dabble into the more design oriented parts of game development and I have to say, it is absolutely one of the most bizarre feelings, purely because of how much freedom I have! Back when I was coding the graphics/game engine, I was so used to moving from one monolith of coding to another, but now I'm basically free to work on anything in whatever order I please! The feeling is both pleasant but slightly worrying as I'm constantly stuck wondering if I'm doing thins in the right order or not. ANYWAY, enough rambling, new features! One of the first things I implemented once I started the game phase was an audio lag calibration screen:  Admittedly, that does sound like a pretty boring feature but it's extremely important as it's one of the biggest things that's kept me from making a new build available to the public! Before, there was no easy way to adjust your audio lag other than just guessing what it might be, but now that I have this setting it, it makes the game much more portable to other computers which will be important soon when I can start making testable builds! Besides that and a whole bunch of convenience features that I've added in the past while, I decided I would pull up my sleeves and give an attempt at animation! It's worth mentioning that all of the following animations are only first pass and lack coloring, but fortunately, at least in my work flow, coloring is the fast part. Starting out small, I decided that I would go for the very first thing the player would likely see: The Idle Animation!  Personally, I'm somewhat proud of how it came out seeing as I have virtually no real experience doing animations! Definitely missing a lot of in between frames, but that is intentional as I think that may be how a lot of the animations in this game end up looking. My plan is to basically get all of the animations done and then add in between frames where ever I see necessary as time is of the essence. Anyway, there is very much a reason why this animation turned out not terrible: I recorded myself doing the animation first!  This was actually my plan for a lot of the animations but unfortunately, I don't really have the room to run, jump, slash and explode and I don't feel like doing this stuff in public. I think I might still do it some day though if I go out to the country with my camera and tripod! What I'm getting at though is that the rest of the animations I've implemented are unreferenced and as such, they need a little bit of work. Anyway, next up, a run animation!  I'm still pretty happy with how this one turned out. Plus it plays a lot better than Waki and Smunch did because Riff runs a whole lot faster. Lastly, I've implemented a jump animation.  This one I think might need a little bit more work. I might change the position of the legs in the rising part, and the position of the arms in the falling part, but at least it's a good start! Anyway, that's pretty much all I have in for animations now. Despite these actually taking very little time (the run animation took 2 hours for all four frames), all this drawing is really putting my drawing stamina to the test! It's an interesting feeling, but I shall persist as best I can. Anyway, with all this game design stuff finally happening, I'm starting to get a sense of how long all this will take. I'm starting to realize with my current timeline, things are probably going to be very tight, but if I only create exactly what I need prior to a kickstarter, than I should still be able to make it just in time. It's still a little early to call as, again, there's still a lot of work to go, but it shall be interesting to find out what the next few months bring!
|
|
|
|
|
71
|
Developer / Playtesting / Re: [Android + more] Fuzzy Tower Defense - we'd love some feedback
|
on: August 28, 2015, 01:15:46 PM
|
Alright, so I decided I would give your game a whirl since the art seems very well done! After about 25 minutes on it, here's what I thought: - I would say the trailer gave an adequate demonstration of the gameplay as well as the story! Unfortunately, I can't help but find it just a little strange that the trailer has absolutely no sound effects besides the music, but it definitely gave a good impression of the late-game gameplay!
- The tutorial did exactly what it was supposed to! I had a good idea by the end of it how the controls worked and I also had an okay understanding of which towers did which things. Basically, the tutorial is fine and explains everything as it should!
- After that, unfortunately, I can't really say the same for the actual levels. I'm gonna warn you that the only level I played extensively after I finished the tutorial was Raccoon Park. Just now I took a quick peak at... Bird Cliffs I believe it was called? But anyway, the rest of this review is wholly biased towards Raccoon Park
- Simply put, I can't beat it. I'm on normal mode and I've made about four or five attempts at beating it but I just can't kill Bee Bee. Before I get on that note, I'll start from the top. Before I go into detail, I'll mention that I used my stars from the tutorial to buy the raccoon tower and the owl tower since I thought diversity would be best.
- After some cute dialogue at the start of the level, the mission intel pops up with basically every optimal tower match up in the tone of "HEY, HERE'S ALL THIS, DON'T FORGET ANY OF IT, GO GO GO" at which point I'm launched into the level. Since there was a pop up for basically every new monsters right when the level started, I think I accidentally X'd out the descriptions for the owl and raccoon towers without getting to see them. My fault obviously, I probably should have just checked the library but I eventually figured out what the towers did. Still, as soon as I closed that mission intel, I basically immediately forgot the matchups and resorted to scrambling towers up as fast as I could.
- The reinforcements mechanic is slightly... odd? I know I saw it in the tutorial but when it happened in Raccoon Park, it startled me quite a bit actually because I thought they were enemies! I didn't have any towers up and suddenly these three characters just BLAST through the course out of nowhere. Seems like it might be more succinct to just give me the money and towers from the start?
- On that note, since you only get the money when the three characters arrive at the base on top of the fact that the first wave spawns as soon as they get there, that means you basically have no grace period for placing towers, it's just "wait for the fuzzies to reach your base and GOGOGO FAST FAST SLAM THOSE TOWERS DOWN". It might be nice to just have something like a 10-20 second period where you can plant towers before the enemies start rolling in.
- Anyway, finally moving onto the actual gameplay, I have to say, that first wave in Raccoon Park absolutely destroys me. The first wave is actually one of the hardest in the level! And the reason for that is because of the fact that, not only does it have flying enemies in it, but it has flying enemies at the end of the pack.
- So, at this point in the game, what towers do you have that can hit flying enemies? You've got bunnies, who can slow them and deal minor damage, and you've got raccoons that you can't upgrade. That's it, that's all you've got. And on top of that, they don't handle the beetles very well, so you can't just go all-in bunnies and raccoons. Additionally, all these towers will always aim for the first enemy that enters their sight range and because the flying enemies are the last ones to come out, all my bunny and raccoon towers just gun down the beatles (very ineffectively at that) while the bees just waltz on past.
- Eventually, I figured that I was going to restart the level until I finally successfully cleared the first wave. After I think about four attempts, I finally got a configuration that worked, two bunnies, a bear and a tiger! In all fairness, it does seem like splash towers can hit flying enemies with the splash damage, so it's unfair to say that there are only two towers that effect flying enemies. I'm not sure how the tiger was able to set the bees on fire though but whatever, it worked.
- Moving onto the rest of the level, now that I had my feet on the ground, I found it was basically most effective to just spam towers. I probably should have invested a little more time into upgrading towers but I never got a good sense of how powerful they were compared to just building new ones. This is especially the case because the process of looking up information on towers is unfortunately really tedious. It would have been really nice to have some sort of info display next to the Build Tower prompt that shows information on the tower you're about to build. It would be much better than whipping out the library and navigating a list to find the specific upgrade you're looking for. I realize that there is not much real estate on the screen to fit that but having the info there in SOME form would be way better than having to look it up.
- Anyway, after a while I finally manage to make it to the first boss of the level, Bee Bee. As I said before, I just cannot kill it. I don't know if there's a star upgrade that was way better than the raccoon and owl, but no matter what, I just can't kill it! It goes back to what I was saying above, except this time there's no fodder for the splash towers to aim for. All you've got for Bee Bee are your bunnies and un-upgradeable raccoons and so far they just cannot cut it.
- It's worth saying, I did take a peak at Bird Cliffs and it seems like the first wave in that level was a little more reasonable to beat, but that was all I played of it as I wanted to start writing this review, haha.
- As you could imagine, I quit playing after I couldn't beat the first level. Maybe it's implied that I was supposed to farm stars on the tutorial or just play one of the other levels, but I didn't.
- In terms of size, the first level seemed bigger than I was expecting but still reasonable. I was just surprised by how many towers it let you build right after the tutorial! From the peak I took at Bird Cliffs, that level seemed like a fun size too. The only thing that caught me off guard there though was the fact that the level has 41 waves! That seems like a ton of waves for just the second level!
- While I realize this doesn't fall under any of the categories you asked for, there are a few other things I wnated to mention, namely in the camera controls.
- Firstly, since selecting towers occurs on press rather than release, I had a lot of instances where I intended to move the camera but instead, I just clicked a tower by accident and had to close it first. Simply put, it might be better to have the select/build tower action on release (and also detect if the respective tower was pressed on in the first place) so that if players don't mean to select a tower, they can just drag their finger away from it.
- Secondly, I liked the fact that there was a zooming action for the game, it felt very intuitive! Only issue is that the while zoomed in, the dragging sensitivity isn't lowered meaning a tiny dragging movement causes a huge amount of camera movement. Might be nice to lower dragging sensitivity as the player zooms in!
I do realize that I've been pretty hard on the game, as in all truth, it is still rather fun! Chances are, with the way the second level started out, it might be totally fine compared to what I was dealing with on Raccoon Park and I may have just picked a bad level to start on. That or there's something I completely missed in the tutorial that would have helped me out, but still, you guys definitely have something with potential here. From the trailer, some of the late game situations looked like a lot of fun!
|
|
|
|
|
72
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash! - First Gameplay Mockup!
|
on: August 25, 2015, 12:03:34 PM
|
This looks like a really cool game! I'll definitely follow your log and check back later to catch up on the progress you've made. Are you going to open source the engine? I've never worked with dynamic sprites and it would be really cool to see how you're doing things. In all truth, I would absolutely LOVE to make my engine open source! I very much have plans to release it to the public in the future but there's a lot of work that would need to be done to reach that point. I'd need to weed out all the hard coded stuff I have for my game, write documentation, create actual editors and just generally improve the engine as a whole (FIRE2D in particular has some weird design aspects that I'd like to change entirely). All of those things though are definitely in the cards! In the mean time, for the actual game itself, I have no intentions of encrypting any of the game files, so anyone who is curious once the game comes out will be free to root through any of the files, graphics or gameplay, and tweak things as they please! Your game reminds me of One Finger Death Punch which I've been hooked on lately, and Crypt of the NecroDancer which I've wanted to play forever but I don't have a dance pad. Have you played either of them? Unfortunately I've never played One Finger Death Punch but I've most certainly seen the game in action. I can see where you would draw the comparison as both games do require getting into a zone to really make good things happen. I probably should pick the game up at some point and give it a try! Crypt of the NecroDancer, on the other hand, I have definitely played. In all truth though, I never even considered using the dance pad to play it, I just played it with keyboard instead! I do actually have my handy dandy Red Octane Igntion 3 (somewhere at my parent's place) but to me, the thought of playing CotND on pad sounds impossible, at least for me! Maybe it just has to do with the fact that I actually suck really bad at CotND and who knows, maybe dance pad is actually the proper way to play it and I've been playing it wrong the entire time. I'll have to dig that pad out and give it a try! Still a really cool game though, definitely has the most impactful deaths I've ever experienced in a video game. Because you're so focused, every death is like a fist coming out of your monitor and punching you in the face, I literally flinched every time! And it's worth mentioning, I definitely mean that as a compliment, it's fun to get THAT focused for a game. Anyway, thanks for the support, Natman!
|
|
|
|
|
73
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash! - First Gameplay Mockup!
|
on: August 25, 2015, 06:03:07 AM
|
I meant to say, thank you TankDuck for the support, and also a good thanks to you SunWuKong! It's definitely a pleasant sign to see people behind the game! On top of that, things should become very fun in the coming months as things get a little more interactive here too!
Alright, it's been a good two weeks now and after a great amount of drawing warmup and incredibly hot weather, I've finally completed the first gameplay mockup for GODHOOD:  (click for full view) The above version is the version without lighting effects. My plan is the moment the explosion goes off, for a few frames, the game will have lighting like this:  (again, click for full view) I'm pretty happy with how this looks, though I will admit I did get somewhat progressively lazier drawing the buildings from left to right! A fun fact about that, since I have little experience drawing buildings, the day after I completed the engine, I decided I would go and take photos of all of the historic buildings downtown! Many of the buildings you see back there are directly inspired from them. On the character sizing, I feel like I might actually make the characters a little smaller yet! I want there to be a lot of real estate regarding how much the player can see around them due to the high range of the explosive attacks. Also worth mentioning is the stylization of the explosions themselves. I actually have a few different ideas on how the explosions look. I actually have an alternative version of the mockup that you can view here:  I'm still not 100% decided on which version I want to use for the game, though I am leaning towards the blurry version as it would blend together better with particle effects. Still, the hard edge style might be easier to animate although I am not entirely certain! I definitely still have some playing around that I need to do. On a side note, it honestly STILL feels so strange to be in the game phase. Now that I have the mockup done, I've come to the realization that I could do literally whatever I want next. There is no clear cut order for this, I could move onto whatever I feel like at the moment, be it writing out dialogue or animating Riff or designing explosions! Honestly, it's an overwhelming feeling, but strangely wonderful at that!
|
|
|
|
|
74
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: August 20, 2015, 10:46:44 AM
|
Alright, I have the explosion episode all ready to go! You can watch it here:  So, now that I have finished one of the most defining mechanics in the entire game, you might be wondering, what more could there possibly be to add to the engine? Well, the answer to that is... Nothing! That's it! That was the last core feature that I needed to add to the engine! I now have every single mechanic I need in place to start developing the actual game! To put it bluntly, the engine is complete! At least.. for the most part! There's still a ton of small code bits that need to be added, such as more complex AI states for the enemies, or more functionality in the Action/Condition system that Character uses in order to do neat things (like play sounds or summon projectiles). The thing with those though is the fact that each of them take anywhere between five minutes to a few hours to implement each! I am officially past the point of spending weeks on a single mechanic! Anyway, now that I have all of these pivotal mechanics in place, this means that I can finally declare the engine finished which means... It's time to commence the Game Phase! After (spread out over a period of) 2 years, it's finally time to put my art and design skills to the test and start creating the actual game! With the majority of the coding behind me, I can now directly focus on game design, art, story, balance and every other aspect of creating a game that isn't code! Honestly, just getting to this part of development has been absolutely bizarre for me so far! This phase of development always looked like it was on the horizon and for years, it just seemed like something I was going to fantasize doing but never actually get to, but alas, here I am! I am extremely excited to see how things go because now we're getting to the fun stuff! Anyway, as I've been saying, I've sort of formed a backlog here and by posting that episode and making this announcement, I've officially caught up which means that I sort of have already been in the game phase for about the past week and a half now! What this means though is that as I crank out art and design, I should be able to post here more frequently with shorter posts since these longer posts really take a lot of effort to write out! Besides, I'm starting to think that people are less inclined to read these walls of text so it should work out for the better, haha. Anyway, for now, I've just been doing warmup drawing (since it had really been a while since I had done a lot of drawing) and a few concepts for the game. So far, my first priority though is to create something this thread has needed for a long time; A gameplay mockup! So far I have it mostly done and I'm already learning about a ton of stylistic decisions that I'll have to make later on. I was hoping to have it done by the end of the week except the temperatures we've been getting lately are making drawing impossible. It's been 30C (which I realize isn't so bad for some of you but when you're Canadian, it's a world of difference, plus the humidex doesn't make things any easier) for the past few days and it does not making drawing easy when you're sticking to your tablet, but I was thinking I'll just work into the weekend to make up for the time I've lost in this weather! Anyway, there's still a ton more that I need to go over and I definitely still have a lot that I need to figure out. In fact, I'll probably be coming here (or at least the relevant board) in the future for some advice, but I'll save all that rambling for another post! For now, I'll just be happy and officially declare: The Engine Phase is complete. The Game Phase begins!
|
|
|
|
|
75
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: August 18, 2015, 06:40:21 AM
|
Alright, I've got the morning to cover this before the temperature climbs to 30C here so let's hope I can get this all out before I melt because I've been meaning to write a log about this for like a week now and I've been really looking forward to it too seeing as this is going to be one of the most important logs I've written so far! After months of building up to it, I have implemented: Explosive Attacks! I feel like I must have gone over this at least a few times before but just to give a refresher now, the explosive attacks (which I STILL need to come up with a less verbose name for) are attacks that player can perform on the heavy downbeats in a song. Think of something along the lines of a big dubstep drop, or maybe a heavy bass drum hit at the start of a [musical] measure. These attacks do much more damage than any other attack Riff has and they also come in many variations depending on what state Riff is in as well as what inputs you perform beforehand. Anyway, before I had started on Explosion, I was probably stuck for a few days just trying to figure out how I was going to even program it. For the longest time, I thought I was going to make a class just for explosion and then hard code every explosion such that I could get creative in code, but instead, I decided upon making a Projectile class. This is very advantageous because it means that I could give the enemies projectiles (or explosive attacks) of their own! Before I get to the fun stuff, a quick rundown on the Projectile structure. I'll preface it with this little factoid; a third option I was considering for programming projectile was to not even make a projectile class and just have the projectiles be characters of their own because functionally, projectiles are almost exactly the same as Characters in structure! Projectiles have different states (flying, impact, ect), and each state has a list of frames of animation (or not if you just make your projectile a particle effect but that's a different story). I decided against just using Character though, as projectiles do have enough differences that they deserved their own class. So, with that decided, I proceeded with probably THE BIGGEST copy paste job of my entire programming career, copying all of Character, Move and Frame into Projectile, ProjectileState and ProjectileFrame, a sheerly terrifying undertaking that I'm sure many programmers here know the horrors of. Thankfully, it went smoothly, for the most part! So, on with the juicy stuff! To test out the projectile class, I decided I would start small and easy and try and create the most well known projectile you can possibly think of, a fireball! That's super simple right, it's basically just a moving hitbox! Well, turns out it gets a little more complicated than that. Having just a traveling sprite that disappears when it hits something is easy, but then there's making it show a different sprite on impact, making it play a sound as it's traveling, ensuring that it gets deleted after a certain amount of time, so on an so forth. Here's the XML for just a basic fireball below if you're interested. <Projectile> <Amalgam name="base.xgm"/> <Speakers> <Speaker name="default"/> </Speakers> <Voices> <Voice name="loop"/> </Voices> <States initial="default"> <State name="default"> <Frames> <Frame> <Affectors> <ApplyVelocity/> <PlaySound maxActivations="1" voice="loop" sound="fireballLoop"/> <If delay="300"> <True> <Destroy/> </True> </If> </Affectors> <EntityQueue> <ChildEntity name="body"> <InternalEntity> <Quad> <Corners> <BottomLeft x="-2.56" y="-1.49" u="0.0" v="0.0"/> <TopRight x="2.56" y="1.49" u="1.0" v="1.0"/> </Corners> <Material name="missileExplosionMat"/> </Quad> </InternalEntity> </ChildEntity> </EntityQueue> <BoundingSets> <HitboxSet damage="100" hitstun="10" hitFreeze="16"> <ReactionMotion> <Knockback addX="19.0" setY="4.0"/> </ReactionMotion> <BoundingShapes> <BoundingBox minX="0.0" minY="-1.0" maxX="2.0" maxY="1.0"/> </BoundingShapes> </HitboxSet> </BoundingSets> </Frame> </Frames> </State> <State name="impact"> <Frames> <Frame ticks="10"> <Affectors> <StopSound maxActivations="1" voice="loop"/> <PlaySound maxActivations="1" speaker="default" sound="fireballImpact"/> </Affectors> <EntityQueue> <ChildEntity name="body"> <InternalEntity> <Quad> <Corners> <BottomLeft x="-2.56" y="-2.63" u="0.0" v="0.0"/> <TopRight x="2.56" y="2.63" u="1.0" v="1.0"/> </Corners> <Material name="missileImpactMat"/> </Quad> </InternalEntity> </ChildEntity> </EntityQueue> </Frame> <Frame> <Affectors> <Destroy/> </Affectors> <EntityQueue> <ChildEntity name="body"> <InternalEntity> <Quad> <Corners> <BottomLeft x="-2.56" y="-2.63" u="0.0" v="0.0"/> <TopRight x="2.56" y="2.63" u="1.0" v="1.0"/> </Corners> <Material name="missileImpactMat"/> </Quad> </InternalEntity> </ChildEntity> </EntityQueue> </Frame> </Frames> </State> </States> <Reactions> <OnIntersection yours="ATTACK" theirs="BODY"> <ChangeState name="impact"/> </OnIntersection> </Reactions> </Projectile>
Anyway, finally, here's how it looks in game!  Not bad! Now that we've got the basic stuff working though, let's move onto something a little more in line with GODHOOD; an actual explosive attack! Starting out, I decided that I would go with the most basic explosion you can perform, the neutral explosion, performed by being in a ground state while holding no directional inputs. Turns out, seeing as I had a fireball already implemented, an explosive attack wasn't nearly as hard, if not easier! Neutral explosion doesn't even have a travel speed, it just occurs and that's it! Appart from a few additions that needed to be made so that forces were properly applied to enemies, it was pretty easy to churn out:  I did a Waki sprite specifically for that explosion so that he would appear like a silhouette in front of the explosion which is an effect I want to get for the actual game, and as a result, he comes out looking rather demonic almost... which is PERFECT! Having fun at this point, I decided I would move onto something slightly fancier; side explosion, which is performed while holding left or right and standing! Turns out this one was even easier than neutral because I had literally everything I needed to make it! I just needed to create the XML and I was good to go:  Now that I had two working explosions, I figured it was time to go for the REAL fun stuff, so I decided I would create a more complicated explosion this time! Rather than ramble on about what it is, I'll just say that if you input a quarter circle motion and the explosion button, you get this:  This one took a little longer because I needed to create a system where projectiles could fire more projectiles but with this system in place now, I have the opportunity to get REALLY creative with these explosions and I'm really looking forward to it! All I have to do at this point is edit and post the explosion episode and than I have a pretty big announcement regarding the state of this project! I'm probably going to do that really soon actually because I really REALLY can't wait to post about it!
|
|
|
|
|
76
|
Community / DevLogs / Re: Cavehook - Grappling hooks, lava and fungus
|
on: August 13, 2015, 06:03:45 PM
|
|
Alright, I have to admit, you had me at grappling hooks. I've always adored grappling hook mechanics in games, especially ones that are more physics based. I remember having tons of fun in these sorts of games, or really, any game that had a swinging mechanic where you could build up momentum and get into a rhythm. I don't know if going on a tangent about other games is a keen idea but it totally brings me back to Spiderman 2 on PS2, being able to build up crazy speed. I was so pro at that game, haha.
Anyway, if there's anything that needs to be said about your demo, it's that it is nearly impossible to put down! In its current incarnation, it definitely has a fair level of challenge! I think I ended up actually ended up putting about 20-30 minutes in just playing it. Hell, if this was the Playtesting board, I'd be working on a full write up about it now, but we're not, so I'll just assume whatever issues I had with the game are probably being worked on! If you're interested though, I could send you one in a PM though (or I could just write it here but it seems kind of weird just dropping a fat review right in the middle of the devlogs board)!
One quick note that I probably should inform you of though. As far as I can tell, the game doesn't work in Firefox, it just loads to the ditherworks logo and stays there forever. Works fine on Chrome though!
Anyway, hope you have fun working on it, and I look forward to seeing what changes :D
|
|
|
|
|
77
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: August 12, 2015, 11:50:14 AM
|
Alright, finally got around to uploading the episode for AI! As I said, I was able to accomplish more than just artificial intelligence that week (which is now roughly two weeks ago, I'm really falling behind on these videos (but fortunately now's my chance to catch up))! I was actually able to implement the core for GameRule! But first, here's the video:  Anyway, GameRule! Despite it being something that drives the entire game, it's such a broad concept that it's core ends up being very lite so it only took me about a day or two to implement it as well as a few basic Game Rules! Simply put, a GameRule (originally I was going to call it System actually but I felt like that might be a little too ambiguous) is basically function that is updated alongside the gameplay and is responsible for every possible event that may happen during gameplay. While very simple at its core (literally just an Update method and that's it), it'll basically allow me to add any sort of core aspect or even some modifiers to the gameplay. The most obvious examples would be a GameRule that spawns enemies if there are too few, or perhaps a GameRule that ends gameplay after the player has defeated a certain amount of enemies (exactly the two GameRules that I've created to test the new system out). Off the top of my head, a few other GameRules I can think of are GameRules that: - restart/finish the gameplay section if the a specific character dies (the player/a boss respectively)
- restart/finish the gameplay section after a certain amount of time
- if a certain message is true, send a message to HiveMind in order to get the AI characters to behave a certain way
A lot of these things are actually going to be needed in the future too. All of the levels I have planned play slightly different from each other and have different criteria for when the gameplay section is complete. Anyway, that's all there really is to GameRule. With that said, I usually put a little spiel here at the end talking about what I have to work on next but the truth is, I'm so behind on these posts that I literally already have it done and I just need to post a log about it! Besides, this one might be best to keep secret until I post the log (probably within the next few days). To phrase a hint in the cheesiest way possible, let's just say that it's one of the most explosive mechanics to be added to the game!
|
|
|
|
|
78
|
Developer / Playtesting / Re: Lunoptus - a short and difficult first person shooter
|
on: August 08, 2015, 04:36:08 AM
|
|
On the note of the pickle mage(haha), it's fine that that is the default player model, I would expect there to be nothing seeing as you never really see your own model. I probably should have added that it would probably just be easier to disable shadow casting on the player model and wand though.
Interesting to know that the element type does actually influence the amount of damage you do, but on the note of damaging the eye vs damaging the crystals, I'm all for making the eye something you can hit, but I wouldn't make it the ONLY thing you can hit. As I recall, those things were small compared to the rest of the body! If you ask me, the better idea might be to make it so that you could hit both the eye or the body, but make the eye a crit point where you do extra damage.
Ooooooh, when the menu said, "Press 'N' to bring up the info screen," I had assumed that it meant that pressing N just brought back up the screen I was looking at, as in the controls screen. I had no problem remembering the controls so I never bothered pushing it!
Also, nope, never found any of the health mushroom! As I said, I never really took that much damage until I meant to take damage so I never really had the need to look for a health pickup. I never really made it that far past the fire/earth areas either so I never really got the chance to look!
Neat sounding heal though!
|
|
|
|
|
79
|
Developer / Playtesting / Re: Lunoptus - a short and difficult first person shooter
|
on: August 07, 2015, 05:23:51 PM
|
Hey! Gave this game a try for about 20 minutes or so! It has a few nice points but it could also use some work in some areas. Here's the full story: - Starting up for the first time, unfortunately, the very first thing I noticed is that there is no mouse lock. While this wouldn't be a problem if you played fullscreen with one monitor, I have two monitors so whenever I would turn right too far, my mouse would be outside of the window and I would lose focus and fullscreen. The same could be said for people who just like playing in windowed mode, except they'd have problems in all directions. I don't know if web unity can't do mouse locking or if it's just a bug with my browser (I'm on firefox for reference), but it was definitely annoying to have to try and regain focus, set it back to fullscreen and hope I didn't take damage in the process.
- Getting in game, I have to say, the whole predicament that the player character seems to be in is rather... interesting, though in a good way! At first glance, those obelisks were actually rather creepy and I definitely got a good creeping out when I finally realized that the moon had been staring at me the whole time after I had noticed it closing it's "eye" (I obviously didn't look very closely at the screenshots).
- As I was playing, I was starting to theorize that perhaps I was one of these obelisks and that I had gone rogue from the obelisk overlord which is why I was having waves of them sent after me. Then I noticed my shadow:

Nope, I'm just a pickle with a wand.
- Getting to the actual game play, unfortunately, I have to say the whole thing suffers from two big problems: the fact that it plays very slowly, and also that there is very little feedback as to what you're doing.
- The slowness of the game can be attributed to multiple things, but mostly all of it comes from the combat.
- I have to say, those obelisks are insanely tanky. I never really got a sense of how many shots it takes to kill them since it seemed like they were dying almost randomly (which I'll get to), but when you spawn that many of them, even going so far as to spawn them all over the map, it felt like it took a few minutes to eliminate one group and by the time you finish, a new group is spawned a few seconds later (in case it hasn't been spawned already)
- Now while I said that the obelisks are tanky, I must also add, the towers are TAAAAAANKYYYY. I had managed to clear a group of enemies really quickly and the timing window I had still wasn't enough to kill the tower. I eventually managed to get it taken down, and it was at that point that I realized that I still have 3 more towers to go.
- In the end, since the obelisks just basically chase directly after the player, pretty much every battle basically consisted of herding all of the obelisks into one spot and then circle strafing them while throwing projectiles at them until they were all dead. If they took different paths to the player, it might make things a little more interesting.
- While I'm on the note of combat, I might as well cover the whole topic. First I wanted to say that the options I'm presented with for attacks weren't bad, but they did seem kind of weird.
- With the matter of the 1 damage attack vs the 2 damage attack, when I came to realize that the only downside of the 2 damage attack was the fact that a very minor gravity affected the projectile, I pretty much used exclusively the 2 damage attack. It's downside was pretty much nonexistent for the double damage you get out of it.
- As for the spray and the shield, I found myself almost never using them. I can see what you mean by the spray being buggy as the projectiles seem to disappear as soon as the spraying is over. I tried using it at point blank but it didn't seem to accomplish anything so I dropped it. The shield definitely did work, but it seems like the enemies have such poor aim that I never really needed to use it. The only times I found myself getting hit were when either when I lost focus of the window from clicking outside, whenever there were a TON of enemies or if I just wanted to take damage.
- Also, the scroll wheel seems like a really strange choice for a key to activate those two powers.
- Oddly enough, the walk speed didn't actually bother me. In fact, it was odd, I actually had quite a bit of fun with the jumping when I realized that the angle of the surface you're on influences your jump. It was actually pretty fun to jump down hills because I made it a little game to try and bank off the hills in such a way that you make big leaping jumps and pick up a lot of speed. I felt like a little ninja, haha
- Anyway, the other point I mentioned before was that the game lacks good feedback regarding the players actions.
- I'm gonna start by saying that the objective of the game seemed rather unclear, though that's not bad because I kind of feel that with a game as mysterious as this, the objective being unclear is probably intended. My best guess is that the way to "win" is to destroy all the towers but the farthest I got was destroying one so I guess I'll never know.
- My other issue was with actually damaging the obelisks. For the first five minutes, I thought the way you damaged the obelisks was to hit them directly in the eye. I thought the crystals falling off them was just sort of a neat way to indicate that you were damaging them but it wasn't until later that I realized that it's actually the crystals that you need to aim for in order to damage them.
- I have no idea what the damage type you start with corresponds to. I can't tell if it's random or if there's something influencing it because I could have sworn that at some point, the element that I was shooting just changed as I was walking around. I also have no idea if there's any sort of fire beats ice beats rock beats electric thing going on.
- One thing that I will say is that I actually very much liked the particle effects. The ice one looked especially cool! In fact, I actually liked the aesthetic of the game as a whole. I don't know if it's just me, but there's always something about Unity games that give them a "Unity" look but I didn't get that with this game which means you did some good work tweaking the shaders and graphics!
- Last thing I want to mention, there was sort of an oddity with some of the projectiles the enemies shot. I can't tell if they were trying to home in on something but sometimes they would just shoot up straight in the air and turn every which way, just flying in random directions. Not sure if it was a random occurance or a bug but yeah, a little weird.
Anyway, that's basically everything I wanted to cover with the game! It may be a little slow and cryptic but I definitely appreciate the style. Also, it goes without saying but I have to say for a first game, this is definitely a job well done! [/list]
|
|
|
|
|
80
|
Community / DevLogs / Re: GODHOOD - A rhythm hack'n'slash!
|
on: August 03, 2015, 03:05:56 PM
|
After much abject laziness, I've finally posted the cutscene episode of development (now with youtube's fancy new UI included)!  Anyway, now that I finally have the cutscene episode it's finally time that I get started on posting progress on the AI architecture in GODHOOD, which is to say... it's done! I'm super surprised but programming the architecture for the AI only took me a few days, and that's including the amount of time it took me to create a few states as well! I would have made posts about as I went through it but I went through it so fast that it just sort of flew by. Because of that, here's a not-so-quick summary of how it went: After much deliberation, I decided that the best course of action would be to stick to my guns and base the AI on a decision tree! Seeing as decision trees are a pretty well known concept, it didn't take me long to implement. On top of that, for the actual decisions themselves, I have the Condition architecture which the character's have been using since the very earliest days of the engine! Anyway, what I was more worried about though was how I was going to handle the actual states themselves. In the end, I decided that since the Smunch character already has all his moves based on keyboard input, maybe it would be best to base the AI on the same idea as well, having it simulate inputs rather then directly manipulating the character itself! I felt this would be advantageous because if I ever implemented a feature into one of the enemies that I wanted to test, I could just swap their AI interpreter for a keyboard interpreter and play the character myself! With that in mind, I decided I would get started and make a very simple chase state: If out of range, move towards the player. Here's the result (framed in a very strange manner because I was trying to get the file size below 1MB for tumblr and failed :S )  Despite kissing a little too close up to Waki, the AI works! Anyway, I decided I wanted to see what happens when I make so that if Smunch is range, he attacks instead of just stopping.  There was nothing left of him afterwards... Needless to say, it made the game literally impossible. I'm not sandbagging here, I actually made a serious attempt to play after that and I think I only got about two of them before I got obliterated. But hey, at least I have something attacking at all! Having that done, I decided I'd split apart the attacking into a separate state that gets switched to when the character is within range. Unfortunately, this led to much the same issue as above; every single Smunch would just converge on Waki as if he were a black hole. What I needed was some sort of messaging system that allowed the AI characters to communicate with each other so that I could create a system where whenever a Smunch would engage Waki, he would flag himself as "ATTACKING". That way, the AI units could just check how many other units were attacking and if there were too many on the offensive, the others would just retreat and watch from afar. This led to the creation of HiveMind, which is my very extremely simple system which allows a unit to select a Hive and send a message! While very simple right now (and not really optimized since every message is a string), I feel like this can come in handy in the future, such that I can have certain enemy types send messages to other enemy types, almost like a hierarchical command! Here's how it looked in the end:  Also, for those of who may be curious, here's how the XML looks for their current AI: <DecisionTree> <States> <Chase name="CHASE" distance="4.0" buffer="1.5"/> <Cautious name="CAUTIOUS" minRange="15.0" maxRange="30.0"> <ExitCond cond="MessageCountLess" hive="Smunch" message="ATTACKING" count="3"/> </Cautious> <Attack name="ATTACK" attackChance="0.8" range="6.0"/> </States> <Decisions> <If cond="MessageCountLess" hive="Smunch" message="ATTACKING" count="3"> <True> <If cond="TargetWithinX" distance="6.0"> <True> <State name="ATTACK"/> </True> <False> <State name="CHASE"/> </False> </If> </True> <False> <State name="CAUTIOUS"/> </False> </If> </Decisions> </DecisionTree> Anyway, bear in mind, a lot of these states are very likely to get changed in the future as well as the characters themselves for a variety of reasons. First and foremost, when in the Cautious (retreating) state, Smunch looks really weird literally just running away plus you can sort of get his AI mixed up and attacking in the wrong direction if you can get on the other side of him without getting too far away (because you're still technically in range of him). Long story short, come game phase, the wills are always going to face Riff. It should make things easier for both of us. Really, the states in general all need to get changed as well, because I really only created them for the intention of testing out the AI. There's still a lot more customization that I want to invest in the Wills once I actually get around the thoroughly designing them. Anyway, this post has gone on long enough! Surprisingly, there's still stuff I have yet to talk about even though it's really only been like one week since I last posted (almost exactly, wow) a message here. Rather than drag this post on into infinity though, I think I'll just make another post in a few days on the other feature I created last week as well as the big BIG things that are coming up this week! Needless to say, I am very excited for what's to come!
|
|
|
|
|