notachocoholic said: I saw a suggestion about possibly making the back hand flat instead of a fist. did you try that or did it just not work out?
I’ll be completely honest: open hands on hips kinda suck to draw(at least for me). I did fist on hip since it’s easier. I gave it a brief try after said suggestion, but gave up pretty quick. Couldn’t be bothered fighting with it, didn’t have the patience at the time. Could still change though.
Color test(ie. not final quality).
Solids or stripes?
arachnofiend said: She should do the “come and get me” sign with her free hand if you leave her idle long enough
Every character will have a few idle actions when left idling too long. This could very well be one of Vriska’s. Along with probably throwing her dice into the air and catching them. Could be a taunt too, but we haven’t really thought about that yet.
A new idle pose for Vriska. More dynamic than the last as a pose. Less dynamic to animate though. Ah well.
Work is officially beginning on Vriska. Above you’ll see the near final idle pose and thumbnails for most of the ground stuff(something new I’m doing).
For those wondering about Rose, I simply wanted to start on something fresh.
Q:Not sure if you'll really have time to answer this, but do you have any advice for someone attempting to start a similarly themed fighting game project, who is trying to gather support somewhere?
That’s a pretty good question. I’m not sure we’re the best people to get advice from, but at the very least I can give advice based on what we’ve learned and from mistake we’ve made.
First things first is assemble a core team. Whether you’re making something from “scratch” or using an existing engine(either a fighting game engine, like MUGEN, or a more general game engine, like Unity), this should consist of a good lead/core programmer and a good lead animator, minimum. Optimally you’d want additional assistant animators because it’s a LOT of work for one person. I’m talking hundreds of frames of animation per character. Upwards of a thousand, depending on the wanted quality of the animation and needed actions per character. Additional programmers depends on the lead programmer. They may or may not want assistance.
Someone should also have, at least, a decent idea in game design in general. They don’t have to be separate team member mind you, a good programmer should probably have this.
Completely optional; but someone on your team who is experienced in fighting games. They’ll know what’s good and not good in fighting games, mechanically. General game design knowledge could cover this.
Plan. Make sure you know what you want to make before you start making it. Also how you want to make it(from scratch or existing engine). Make a game design document. You don’t want to plan every single little detail straight away, but you’ll want to solidify the core stuff. Mostly the type of fighting game(2d or 3d? traditional fighter or something different?) and a solid idea of wanted mechanics and game feel. Core game stuff. Stuff that’d be difficult to change mid production. A solid, cohesive artstyle is something you’ll want to lock in before the real art starts.
Research other games in the genre. Get an idea of what’s good and what works, and what not to do. Don’t be afraid to take ideas from other games.
Prioritize prioritize prioritize. Programming is top priority until you have a solid base engine. Rough animation is all that’s needed to test and play with the engine until it’s solid. Hell, you can probably use sprites from other (fighting) games for testing. Once the engine’s solid enough, the real animation is equal top priority.
Sound, music and voices are the very least of your priorities. Let’s be honest, sound in general is technically not necessary until everything else is complete. You don’t ACTUALLY want to leave it to last, but it’s definitely not one of the first things you want to sort out. Auditioning for voices before so early in development was one of the biggest mistakes we’ve made. Likely burned a lot of bridges.
Have something down before approaching people. Before you assemble a team, or anything really, make the design document. If you’re competent enough, a small tech demo. At the very, very least, some art.
There are countless ideas out there. Many go unfulfilled because they never got past the “vague idea phase”. Homestrife started as a forum thread where the OP was someone basically saying “wouldn’t a Homestuck fighting game be cool?”, then just people throwing ideas for character attacks around. This is gonna sound super arrogant, so I apologize in advance, but it likely never would’ve taken off had I not found it, whipped up some sprites and, a bit later, a short game design document. Luckier still was when a programmer dropped in to back me up. Even luckier still was when Darlos9D came along after that programmer dropped off the face of the earth.
No one is gonna jump on the project unless they really believe in the idea. Having a tangible idea that is solid, not vague, with a solid, existing, foundation will help immensely.
I’d also say that it’d probably be a good idea to not make your game public until you have something solid to show. Unfortunately we didn’t have this option due to the nature of how the project started. We only had a few mockup screenshots and some rough pencils for about a year before we had a finished sprite. Another year passed before we had an basic engine.
That said, once you have a solid foundation you have 2 options: 1. Put out the call to join the project. And/or 2. Search for and approach people you think would be a good addition to the team/willing to join.
Luck and Patience. Homestrife started slow. Hell, it’s still going slow. But we’re persevering. We truly want to see the project through. It’s our entire motivation. We need help to be not slow, but the amount of people willing to assist in their spare time, for free, is quite low. We’ve been very, super, lucky collecting the team members that we currently have. We’ve gotten scores more people saying “I want to help but I have no real skills of use” than people offering genuine help. This is probably a good point to segue into…
Don’t compromise the plan/idea. We want to recruit people to help. We’ve put out the call a few times and gotten a bunch of responses. Very little of these responses make the team. This is because we’re not willing to compromise the quality of the project. I’ve had to respectfully turn down several animators because I didn’t think their skills we’re quite high enough to meet the quality we want for the project. This goes with any “department”. Do not be afraid to turn down people if you don’t think they can meet the wanted level of quality.
Be nice and respectful in everything you do. This sounds like a basic life lesson/moral thing, but it’s very true to an indie project. I like to think we’ve been good to all of our followers and team members. If we were asshole to everyone, I don’t think the project would’ve gotten as far as it has.
Sorry if that got a little long winded. Hopefully at least some of this advise will help you. Good luck on your project.
The following answer is from Darlos9D, our lead programmer and fighting game buff.
You raise some good points. Several of which have been addressed in the past, though I’ll admit our information dissemination isn’t the best right now. (I really need to compile all the game features and quirks on the wiki…) So, I’ll go ahead and hopefully put some fears to rest.
It hasn’t been implemented yet, but the game will eventually have an “unblockable setup protection” in place. When a high or low attack is blocked, for the next few frames during blockstun, all incoming attacks will essentially count as mid. Now, the opponent can get the timing down and make a series of incoming highs and lows HARD to block, but attacks that strike at the same time will never be completely unblockable. The same goes for right/left side attacks.
I think you’re overestimating the complexity of horizontal position/velocity affecting the blockability of many mid attacks. When the attacker is above the defender, attacks are either high or mid. When the attacker is below the defender, attacks are either low or mid. This means, just like any other fighting game, you’re going to want to block high while the opponent in the air or doing an overhead, and probably low otherwise. This system won’t make an opponent who is above you suddenly able to hit you with a low or anything wacky like that. Really, the system is in place to simply avoid instant overheads with jumping neutral light attacks and such, but to still allow a wide range of decent jump-ins. The only ambiguity might come from an opponent who is rising or falling past a defender, right as their relative above/below state changes. But really that’s no worse than ambiguous cross-ups, which is par for the course in fighting games. Quite frankly, anyone who manages to make use of that ambiguity deserves the advantage.
Good point on the never ending blockstring coming from multiple characters. I was going to worry more about that sort of thing once the game reached a certain state of legitimate playability since I doubted I’d be able to preemptively account for all possible issues that come from a game with more than 2 active fighters. There are certainly some existing examples of how this might be dealt with, such as alpha counters or pushblocking. There might even be something else that could be done, such as some kind of system that limits blockstrings similarly to combos.
Parry likely won’t be too ultra-powerful, since I imagine it being more like Guilty Gear or BlazBlue where it simply shaves off a few frames of blockstun. Useful at certain points in blockstrings, but not horribly overpowered. Dodges will provide only a small amount of invulnerability at the start, followed by some recovery. This is specifically to avoid incoming attacks that have few active frames followed by long recovery. (a highly active attack will outlast the invuln, and an attack with low recovery will let the opponent recover in time to take advantage of the dodge’s recovery) One of the most obvious types of attacks like that will be grabs, which dodges largely exist to counter in this game since you cannot simply “jump out” of throws. Of course, there will naturally be other attacks that fit those criteria that dodges will situationally be useful against.
I’m not sure what you’re referring to when you say “Moving towards the attack you want to block.” We currently have no forward-moving defensive options planned.
I hope this answers some questions.
Q:HeY What're you gonna do about cross-ups and blocking and breaking blocks and mixups and stuff, is it just gonna work like mahvel?
I’m not 100% on what you mean exactly, but all of those will be a thing.
- [EDITED] By default cross-ups will exist due to the nature of a 4P game, but they’ll still exist 1v1. Getting hit from behind, blocking or not, will turn you around to face your attacker.
For blocking, we don’t intend it to be the best option for defense. In fact, it will end up being a last resort kinda thing. While blocking, you will take chip damage from ALL attacks. This includes normals. Chip damage will not be able to kill you, but there might be exceptions for supers. We have no current plans to have “guard breaks”, but grabs will be unblockable(but dodgeable). The only way to avoid damage(when we implement it) will be dodges and a parry. There’ll be a high, low and backwards dodge/dash. We’re currently debating if anything should be done for a forward dodge/push.
- High/low mix-ups are already a thing in game. It’s slightly more complex that a usual fighter as your vertical position compared to your opponent will change the high/mid/low value of most attacks. You can read about that here.
Everyone should note that everything is far from final. We’re still testing mechanics and whatnot, so a lot of things and things we’re planning are subject to change.
EDIT: Oops, apparently I had misconceptions about a couple things and was told off. Check italics and strikethrough for changed info.