Nice art. Like using QWER for attacks, works well.
I've attached a capx with some mods. Covers some of the following. Here it is:
https://www.dropbox.com/s/abaik7rk5b4e3 ... d3.capx?m=
Here's a crack at your questions:
1: Not seeing this. Tried a number of times. 6th zombie always dies. I can kill any zombie that spawns.
2: I didn't see this specifically. However...attacks did do some other wonky things (PK, I can see the movementBox, ditto on the fire attack -- which doesn't always show up -- and at one point I couldn't do any attacks anymore.). Will take a look tomorrow.
3. Noticed that. Probably something to do with your picking. I'm sorry to say but...the UID picking for collisions was throwing me (little short on sleep today...).
4.Never saw backwards running, or frozen attacks. Only saw an enemy get stuck once, and that was after I'd tinkered some code.
5. Alrighty then:
Performance:
Actually, this performs quite well. I ran it on my EEE and my desktop, and was surprised to see it running quite well even on the netbook. I made a couple of small performance enhancements, but they really shouldn't be very noticeable.
Gameplay:
Movement: Not a fan of the 'skating on ice' movement for the main character. Actually...it's pretty bad. But that can be adjusted easily. Looks like you aren't setting your acceration/deceleration for PSI, which is part of the problem. Also, cosmetically, if you could adjust PSI's stride length to be shorter when moving slower, this would also lessen the 'skating on ice' look. I don't know how this would be accomplished with spriter, as I have no experience with it.
Attacks: Need more feedback for attacks. Consider having the zombie's flash when you hit them, green to yellow to red as health declines.
Floating healthbars would be another option -- often used in brawlers -- but that may not agree with your aesthetics.
Dismemberment would be great to have at some point as well, and would also communicate an enemies state, but would probably be more performance demanding. If you are targeting desktop only, I'd say go for it.
Collisions:
Right now it's too easy to get boxed in by zombies where you can't move...at all. The idea of being swarmed and having to force your way out of a group is fine, but right now you just get trapped. It's frustrating.
I think need a way you can 'push' against enemies. So, instead of seeming like you are hitting a brick wall, it seems like you are colliding with something that has some 'give', and which can be pushed away from you. There are many ways you could accomplish this, using push out commands and such, but I'll leave it up to you whether or not to go that route.
Misc:
Comments:
Pardon the bold, but I feel this is important.
You need to go through and comment all your events.
If you don't do this now, your going to find it impossible to continue at some point. Comment ALL events. Even the stupid ones you think you could never misinterpert or misunderstand.
This advice comes from many people wiser than me, but is backed up by my own personal experiences of the misery of poorly annotated code. You can literally end up having to scrap 100's of hours of work because you just can't claw though your own spagetthi.
It's not fun. It's tedious, it makes everything go a lot slower, and it's mandatory for any serious project. Rant out...
Image Borders:
A few of your images have very small borders. If there is any chance an object will be scaled, you should have a transparent border of at least 2 pixels on all sides. Otherwise, when scaling up, pixels can be 'warped' out up against the image bounding box, which is quite ugly. See: speechBubble's, footprints, jawbone, paper, skull, bone, circuitboardpattern, Buttons, etc...
You can do this easily in C2 by going resize, adding 4 pixels to each dimension, and changing 'stretch' to 'align center'. You might not be planning to scale internally, but it's good practice regardless.
Speech Bubbles and Text Panels:
These are going to eat up a lot of memory if you plan to have any more of them. At least ditch the panels for a spritefont, which will be more flexible, save you memory, and look better. See:
https://www.scirra.com/tutorials/629/sp ... when-where
Also, look for blackhornets GiveYourFontsMono program. It's freakin' sweet.
Text bubbles are harder, but frankly, most of them look the same, so having a couple text bubbles and filling them with spritefont text should work fine.
If you want more variety in their appearence, and even less mem usage, try making a speech bubble tilemap to build custom bubbles. You can draw them in a layout in seperate tilemap instances, ID them with an instance var storing their name, then save them as json into a dictionary with names, like "TallBubble", "LongBubble", "DiagBubble", etc. Then, spawn as needed.
Events outside of groups:
It looks to me like, in places, you have events that you intended to put inside a group, but didn't. Close all groups, and examine any exterior events to see if they aren't where you want them.
Would love to see:
More gore. It is a zombie game after all, and gore is actually easier in 2D:
Flame burns zombie's down to a skeleton.
Acid pools dissolve zombie legs; then, of course, they come crawling toward your brains.
Dismemberment, as mentioned above. Fun addition: physics enabled intestines that spill out, and physics enabled eyeballs that pop out on a hard hit and dangle there.
High performance mode where corpses don't fade away. Decay; body parts rot slowly longer they are on screen(every couple seconds, spawn new, slightly more decayed gib, and fade out old one).
On a "Not Gore" note:
Being able to pick up objects and toss them is a classic brawler trick. Maybe a psi twist on this: hold down to levitate all nearby, moveable objects, release to send them flying at nearest zombie.
Final thoughts: movement while attacking:
This is not a right/wrong thing, but more of a design decision: if it were me, I would make it so you retain movement for most attacks. At least Psi Blast and Flamer; PK I would keep as it is (disables movement), Psi kinectic Swing I would maybe rethink (as it stands, it's...er, not that impressive. maybe a showy, more powerful last ditch attack in it's place?).
To me, the main characteristic of the classic zombie attack is: you have to keep moving. Movement is the name of the game, as it's the only thing keeping you from being eaten alive...you can move faster than they can.
Now some games -- like many of the Resident Evil titles -- disable movement while attacking for that very same reason. You have to decide when to fight...and when to run. Arguably, it can make things very tense (see how well this is used in RE4).
BUT...that's a survival horror game. Not a brawler.
Since you are making a more action oriented game, having to stop to attack just feels...irritating. It feels like 'run a bunch to get far enough away to attack a little...then run a bunch more'. Not good.
As such, I would suggest a compromise, by restricting movement to different degrees depending on the chosen offense. So:
Psi blast is weak, but quick and light; thus, you can move almost normally (say, 2/3's speed) and fire it.
Pyro is medium range, powerful; you can move enough to adjust your aim(1/3, 1/4 normal speed), but that's about it.
TK is moderately powerful, quick, long range, can push enemies back; thus, having to stop and use it is not as much of a penalty, which is why I would leave it as is.
Of course, you will need to lock movement so that, when firing, going backwards doesn't actually reverse your aim. Though, maybe walking backwards is slower.
Finally, I would consider increasing PSI's overall movement speed, but play around with reducing speed when she is damaged.
. . .
And...nope, can't think of anything else right now. <img src="{SMILIES_PATH}/icon_rolleyes.gif" alt=":roll:" title="Rolling Eyes">
Hope that was way too much. <img src="{SMILIES_PATH}/icon_mrgreen.gif" alt=":mrgreen:" title="Mr. Green">
Cheers,T