|
204
|
Player / Games / Re: Let's discuss Smash 3DS
|
on: October 09, 2014, 04:08:26 PM
|
Now that I have a bit more time I'll go a bit more in-depth on my impressions. I used to play Brawl fanatically. Melee too, and even the original, but I was never good at those two. Last year I went to a low-key Smash tournament thing and it turned out to be in Project M. I won the tournament, but I still fucking hate PM. I don't want to rant though, so I'll leave it at that. Anyway, I'm glad the developers made some concessions, and this game feels like a good balance between 'accessible' and 'complex'. Or, if you want to generalize, between Brawl and Melee. I was pretty bummed that Smash Run couldn't be played online (even if only with friends), and even more bummed that you couldn't actually encounter or chase down your opponents in the stage (though five seconds of thinking that through reveals why -- with powers and a speed stat to keep up with disadvantaged players, things could get nasty. But Kibry Air Ride allowed you to fight your opponents while gathering powerups, so I was hoping for something like that). I was most bummed, like extraordinarily bummed, by the inability to change the time limit from anything but five minutes. I want to get all my stats to 1000 and run around, damnit! Once I get someone to play Smash Run locally with though, it should be a great alternative to just straight-up smashing, and fighting the impressive roster of enemies to gather big honkin' powerups never gets old (to my OCD self, anyway). The controls work well for what they are, my only big complaint being those damn unintentional wall clings. The input to do it is a bit too easy, making for some annoying situations. Classic Mode is fun, but I was hoping for the enemies on 9.0 to have a bit more sting. The 9 AI was never crazy great in any Smash game though, so I guess it can't be helped, but since it's a carry-over from KI:U, I expected to die in three hits and lose all my gold. Master Core is definitely tough on 9.0 though, which is good. The music is great, which shouldn't be any surprise. The Smash arrangements have always been top-notch. I was a bit underwhelmed by the the Final Destination theme (a remix of the otherwise good main theme). But I'm so glad that Shulk exists so I can listen to Xenoblade's superb soundtrack. I hope they'll have some more of the good ones from that game in the Wii U version. Global Smash Power would be a lot better if it told you how many players it was out of, so you could know if you were close to the top or not. Anything over 1,000,000 generally is pretty good, but I'd still like to know the specifics. Street Smash is a nice diversion, as are: completing the Challenges lists, playing Trophy Rush, or trying to get kills in Cruel Smash (I've only ever managed 4 before, and it was through AI screw-ups). Overall, there's a lot of stuff to do, and take all my criticism with a grain of salt because I actually have played this game for hours and hours and hours and am basically just whining about small stuff at this point. I really like it. The controls were a bit weird at first, but I'm warming to them. I like that the "adventure mode" was replaced by "smash run", which I find much funner. Also:  Little Mac rules. Strange - I checked my Little Mac record for Home Run and I had 2,891 feet with a GSP of 1,109,789. So either the feet-to-meter conversion isn't the same as in real life (904.6m ~= 2967 feet) or GSP is different across regions. I guess that shouldn't come as a surprise, but it is "global"...
|
|
|
|
|
205
|
Player / Games / Re: Let's discuss Smash 3DS
|
on: October 09, 2014, 11:44:46 AM
|
I've played a lot of it  its slow, a bit faster than brawl, but no wavedashes, no crazy combos and stuff, idk it looks really """casual"""
I disagree.
|
|
|
|
|
208
|
Player / Games / Re: Nintendo 3DS
|
on: September 30, 2014, 08:52:55 AM
|
|
I've played smash for aeons on GC controllers and never use the c-stick except for fast-fall down aerials. Everything else doesn't need it unless you're a SuperPro ZSS player using her DACUS all the time.
Once the game comes out I will definitely put up my FC as well. Too lazy to find it right now.
|
|
|
|
|
209
|
Developer / Technical / Re: Polymorphism and Child Data
|
on: September 28, 2014, 08:26:11 PM
|
Yes, it could get messy. I mean, you could devise a hierarchy (more than one abstract parent) but it would still have that problem to some degree. There may well still be something easy that can do what you're looking for, but I've never come across it personally  There are always workarounds, if all else fails.
|
|
|
|
|
210
|
Developer / Technical / Re: Polymorphism and Child Data
|
on: September 28, 2014, 08:02:05 PM
|
I think you can just make use of abstraction and have the cars without nitro have an empty function for it. But in that case it's basically what I said before, and the parent 'has' nitro, you are just contracting the implementation to be done by the children so that nitro() can be handled differently between a racecar and a jalopy. From the wikipedia page on polymorphism: abstract class Animal { abstract String talk(); } class Cat extends Animal { String talk() { return "Meow!"; } } class Dog extends Animal { String talk() { return "Woof!"; } } void letsHear(Animal a) { println(a.talk()); } void main() { letsHear(new Cat()); letsHear(new Dog()); } Applying this to your first example: class ParentClass { function doSomething(); abstract function doSomethingElse(); }
class ChildClass extends Parent{ function doSomethingElse(): }
var anyOfTheAbove:ParentClass = new ChildClass();
anyOfTheAbove.doSomethingElse(); // This isn't an error!
|
|
|
|
|
211
|
Developer / Technical / Re: Polymorphism and Child Data
|
on: September 28, 2014, 07:07:53 PM
|
|
Well, if a child class does something that a parent class wants to, why not move it up to the parent class instead, then make the child call it from there? I think that's how the standard procedure goes, but I haven't dealt with polymorphism much either.
|
|
|
|
|
212
|
Community / DevLogs / Re: Bear Hero (Platformer Roguelike-like) [DEMO]
|
on: September 27, 2014, 02:32:44 PM
|
   Been working on deities. They're mostly concepts so far, actual gameplay related stuff is up in the air. I have to balance flavor and usefulness for all of them, which means a lot of scrapped ideas. It's still a lot of fun to think about, though. Yeah, the pots/crates/etc. are just there for decoration. Or unending torment and long sleepless nights, whatever floats your boat. I was toying with the idea of a mimic enemy though, so the pots may see use eventually.
All joking aside, part of my confusion was that the pots being brownish red and blue made them seem like analogues of the red and blue apples, which led me to associate them with health and magic. In order to spare future morons from confusion, perhaps a different color set for pots? Or some other sign that they are not interactable? That's a good point, though no immediate fix comes to mind. That correlation gives me an idea for a "Transmute Pot" spell, though 
|
|
|
|
|
213
|
Community / DevLogs / Re: The Mash Engine!
|
on: September 27, 2014, 11:34:55 AM
|
|
How are you handling collisions? Are you using GM's built-in collision detection? If not, do objects collide with every potential instance in one frame? (For example, an enemy getting hit by two bullets simultaneously.) Also, if someone flings an object at a wall at ludicrous speeds, will it be guaranteed to collide with that wall? And regarding physics, are you using any form of GM's built-in solidity, hspeed, vspeed, etc.? Lastly, how is parenting being handled? It seems like every object needs to be a child of obj_entity, but what if the user creates their own parent/child dynamic outside the engine's scope? (for example, obj_teleportTarget is made by the user, and all children of that object need to have it as their parent) Will users have to go through obj_entity and create their own can-scripts for non-canon parent relationships?
|
|
|
|
|
214
|
Community / DevLogs / Re: Bear Hero (Platformer Roguelike-like) [DEMO]
|
on: September 22, 2014, 02:08:53 PM
|
Yeah, the pots/crates/etc. are just there for decoration. Or unending torment and long sleepless nights, whatever floats your boat. I was toying with the idea of a mimic enemy though, so the pots may see use eventually. I got around to separating hitboxes/hurtboxes. It actually wasn't that bad, but I had to do some thinking to make sure I didn't overdo it. Nothing to show, so I'll ramble here instead  Every enemy already has a hurtbox that is also used for collision with terrain. Problem is, that box is generally several pixels inside the visual boundaries of the sprite, so that's why attacks that should have connected were whiffing. The solution is to keep that hurtbox how it is but then add a non-collisive, non-damaging hitbox. The first solution that came to mind was for each enemy to perform rectangular collision checks for attack-parented instances each step, but there was a problem. Initially, I was taking advantange of GM's collision events to handle whether or not an enemy is hit, but throwing out rectangles outside an enemy's mask isn't the same. Collision events are performed for every instance of the specified type in contact with the object, every step. Since enemies don't become invincible after being hit, they also store objects that have hit them already into an array so they don't get hit again. But it's perfectly fine for multiple instances to connect with the same enemy in the same step. The same couldn't be achieved with throwing out rectangles without a while loop through all existing attack instances for each enemy -- which will get really slow really fast. It's obviously a very convoluted and bad solution, so I dwelled on it for a bit before going ahead. Anyway, the solution did end up being quite simple. Every enemy spawns a hitbox object when it's created, which has a mask different from (and larger than) their hurtbox. The object follows their target around invisibly and uses GM's collision events to check for attacks via collision events like before, then passes all the necessary info to the related enemy and it handles things from there. Such a simple solution, and I think it's already making things a lot better. You can hit a knight/wizard in the head now, for one thing 
|
|
|
|
|
215
|
Community / DevLogs / Re: Bear Hero (Platformer Roguelike-like) [DEMO]
|
on: September 17, 2014, 11:51:18 AM
|
 Here's a frog. More interesting name forthcoming... maybe. They spew arcs of freezing water at you, but they will do it even when you're not around (as per Cranky's suggestion). Good game, enjoyed it very much. I'm not very good at it.
My only complaint: When the controller is selected I would still like the Enter key to confirm/submit name. Every time I type a name I hit enter, sigh, then hit START on the controller.
Yep, I've found myself doing the same thing on several occasions. I will probably just make it recognize Enter and Joystick Start regardless of key configuration, since neither of those can be used to type names with anyway. It's on the list! I haven't encountered any bugs, although there was a treasure room where the only way forward was blocked by a spike, but maybe I just didn't figure out how to go through there if there is a solution to that. You can make it through that room by sliding with good timing, but I've since removed it. The window to get it right is way too small, turns out. A couple of thoughts about gameplay related things: - I think the blue knight with the yellow cape has a weird hitbox, it seemed like I was hitting his leg sometimes and he was unaffected by it. - I found it weird that enemies that are clearly 2 tiles tall don't have any hitboxes on their heads Yes, the knight's box and the head thing have been gnawing at me too, and the solution is to introduce separate hitboxes and hurtboxes. I've been putting it off because it's a little extra work to set up on my end, but it's 100% going to happen, and should solve both of those issues. - When enemies are in hitstun and flashing (the one enemy that displays an exclamation mark when hit does this I think) it feels like I should be able to run through them without getting hit while they are stunned. I would often times run into enemies after hitting them when I am cornered thinking that it would be fine since they are stunned. I'll consider this, but it feels a little weird to be honest. It would be hard to determine when exactly the enemy can hurt you again. I recommend sliding when cornered instead. - the floating skull enemies could maybe display a small red timer after death so the player could be better informed about the impending explosion. I'm trying to avoid clutter on the screen, but I'm relatively confident that I can modify the explosion windup effect to be more obvious on its own. I'll try something involving shaking, scaling, and perhaps blending. I think the difficulty is fine, its definitely making me feel like "next time I'm gonna make it farther" every time, but that isn't really what I want to talk about. I felt like the game wasn't really doing a good job of introducing me to some of the enemy types very well. What I mean by that is, that for the player to learn what a particular enemy does often times means to put yourself in harms way, as that is the only way to trigger their attack. Observing some enemies didn't convey very much information at all. I think it would be better to give some enemy types a "stupider" AI, at least in the first couple of rooms, so that their attack patterns are exposed to the player from a safe distance. Like make the blue knight attack thin air sometimes and the wall clingig bug drop down randomly without you standing underneath so that the player gets the chance to know about their ranges/patterns without having to die to them first. Like bone throwing enemies in castlevania that throw their bones regardless of where the player stands, a way to convey information basically. Some enemy types were already doing this, like the 8-way laser shooting guy and the poison mushroom thingy, I enjoyed their design a lot more in comparison. I also liked the mage design a lot, after fighting the brown mage, the player immidiatelly knows what to expect once you encounter a blue one, the similarity in visual design conveys important gameplay information, and I liked that a lot.
When playing at first, it felt like the game wanted me to play "hit&run" style, but was already introducing elements that hindered my movement, like spikes, bats and the floating skulls. You might think about delaying the introduction of those elements for the second floor, so that the player can be better taught about hit&run tactics. Basically first reinforce the notion of hit&run by giving them room to maneuver and only after take that room away by introducing those elements that control space.
Good points, and I agree with most of what you've said. Knights slashing thin air is kind of silly, but I could see beetles falling on their own, and so on. I think it's not too much to ask that the player learn that standing in front of a knight = bad, but I'll try to keep trial-and-error to a minimum. Later enemies will be based off existing templates, at least to some degree. For example, the magus is based off the mage, as you mentioned. I'm expecting players to remember that things that carry swords can probably slash them, though. Played a bunch, really digging the demo. Thanks for releasing it.
One thing: When I try to dash-slide through Knights, I almost always get hit and most of the time, they don't get stunned. I think it's worked correctly a few times, so I suspect the issue might be that the hitbox/sprite matchup for the knight is somehow confusing? I can slide-dash pretty reliably through all the other enemies.
Anyway, great game, really digging it. It has that "one more run!" quality already.
Thanks for playing! Dashing through knights is definitely possible, but trickier than it needs to be right now. I think the hitbox/hurtbox separation that I mentioned above should help fix this to some degree. In other news, the Alpha Beta Gamer blog was nice enough to give this game a feature! I certainly appreciate it, since I'm content with never doing any PR ever 
|
|
|
|
|
218
|
Community / DevLogs / Re: Bear Hero (Platformer Roguelike-like) [DEMO]
|
on: September 14, 2014, 09:00:39 PM
|
Back from the grave! I obviously expected to be slowed down somewhat by going back to college, but I've let other things get in the way. Anyway, just expect development to move a bit slower now... but I'll still try to update semi-regularly. A fair deal of new spells, items and classes have been put in, but are unfinished to varying degrees. So I'll just show what I worked on today.  Ghosts are mischievous and yellow. They want nothing more than to welcome you to the afterlife in a swift fashion. More to show soon, hopefully.
|
|
|
|
|