Hello! I am a fatfur game developer and I have three ideas for a game I need help choosing between. You can get more details on it at http://www.furaffinity.net/view/27965247/ , but I will still give you a rundown of each ^^
The first idea I have is a game I’m already making, and it’s one I’ve posted about before; Staff of the Fat King. It’s an RPG where food takes the place of EXP and can also be used as a currency or ammo for abilities. As I’ve said, I’ve been working on this, and the main reason I’m reconsidering is because the game is proving to be very difficult to make due to how extensive player animations are. I also don’t really have any ideas for the direction of the game aside from the food mechanics, so I’ve been hit hard by scope creep. I was wondering if I should delay this game for a while and instead switch to the other two, since it might be good to start over from scratch at a later point in time when I know exactly what I want.
The second idea is for a Pokemon-esque game where you can fatten your creatures (which I will call Blubbermon for now) in battle to change their stats and such. For example, one Blubbermon has an ability where they rapidly lose weight when they get fat enough in exchange for random stat boosts throughout the battle. This game would be a bit easier to make than SotFK in that it will not have a ton of animations to make, instead needing a variety of stationary sprites for the Blubbermon roster. However, that would still lead to a fair amount of work to do per Blubbermon, especially since I am not that good with drawing perspective (or at least not as good as I’d like to be).
The third idea I had was for an action/puzzle platformer. Instead of coins dotting the level, there would be morsels of food strewn about, which the player can collect to fatten themselves, This obviously hinders their mobility, but can also lead to alternate paths (such as through destroying weakened ground). I was also thinking of having some other elements that can enhance your mobility at larger sizes; the one I was currently thinking of was an army of minions that can carry your tubby butt around and toss you onto ledges but cannot jump themselves. This would be the easiest to make from an art perspective, but it might also prove difficult to make stages and such.
So, those are the three ideas I’m thinking of working on. What do you think I should do? Staff of the Fat King (AKA SotFK), the fatfur RPG where you gain weight; Blubbermon, the fatfur RPG where you make your monster friends gain weight; or the currently unnamed platformer, where you gain weight and jump around? I have a poll at SotFK Poll , so vote there and tell me what you wanna see!
Ooh, tough choices! I think I’ll give Staff of the Fat King a try before trying to make a decision–it seems like you’ve been giving these a lot of thought, so I will too~
First off I would not drop your Fat King game unless it is totally broken. From what I have read so far it sounds like it is less scope creep and more your project turned out larger then expected (which is very common).
To give you an example of how this can occur lets use your second project for instance. While it may look simpler on the outset, it could easily balloon bc you may require more characters in it then in your Fat King game. Lets say you only need 3 characters for fat king, at 10 sizes, with lets say 3, 3 frame animations for each size. Lets say that is 3*3*10*3=270 sprites (there are probably some tricks you could use to cut that down, but working off worse case scenario).
Now lets say that in your Blubbermon game you need 3 views, a front view when looking at them, a front perspective view, and a back perspective view. Lets also assume 10 sizes again. So at first glance without having to worry about animations you are looking at 3*10=30 sprites. Much lower then 270 right? But lets consider how many Blubbermon you should have? You cant have too few or it will get boring, after all people need to collect them so you chose a reasonable number, lets say 9. Now lets look at the sprite count 3*10*9=270 sprites (once again assuming you have to draw each sprite from scratch)
My point from above is a project can become much larger then you think originally. What I would suggest is taking some time to sit down a thoroughly document what your scope is in all 3 games. Once you do you will have a better idea on what their complexity might be.
When it comes to getting help you have two options. Either make a version of what ever project you are working on that is very limited in scope and try to use that to draw in help, or work on a smaller project to try to build credit with.
On canceling I would not cancel the project unless you really just do not want to do it anymore, or if you have accumulated so much technical debt that you cant work with it and rewriting it from scratch is not feasible.
That third Idea sounds very interesting. It sounds a little like Lemmings crossed with the Sonic XL mod. I recommend going with that one because it would be easy to expand on and easy to get something started. If it turns out you make a level and hate it, then you’ve only made game logic and a single level. With your other two ideas the scope and the amount of details required would be daunting if you’re a team of one.
I’m intrigued by the platformer; I don’t typically see those… In regards to weight gain, anyway. It makes sense, as it’s the one genre that you’d really get to feel your character’s weight. Unfortunately, that’d be the same thing that will frustrate players, who might be annoyed that they’re being punished for gaining weight.
I don’t know how concrete your concept for the platforms is, but I’d likely skew toward puzzles rather than action, with the proposed minions taking center stage and the fatfur being demoted to platforming tool. Minions could use their belly as a trampoline, drop them on monsters to crush them, wedge them in gaps to form a bridge or block passages, and use their natural buoyancy to cross bodies of water.
I think I already replied to this, maybe on the poll, or on FA somewhere. I seem to remember that you have learnt a lot of stuff since you started, and know that SotFK is not where you’d like it to be. With that in mind I’d suggest actually continuing with it. Perhaps take some time out to refactor it and make something that’s cleaner but does exactly the same as the current release. This gives you a better foundation for progress (making it easier and faster to move forward).
If you move onto something new it’s going to be much harder to return to SotFK later, especially if the code is no longer clear to you when you return. If you refactor, then leave it for a bit it won’t be so overwhelming if you come back to it.
You might want to apply to be part of the Dev group here and have a board/category for your project(s).
On a personal level I stink at platformers, so if you choose to develop something else I’d probably prefer the blubbermon one - but it sounds like a lot of work if you are looking to get 100+ balanced monsters!
What you said for SotFK is pretty much on-point, but the math for Blubbermon isn’t exactly on par. I was planning on having at most 3 sizes for each blubbermon, since stat changes across anything more would be really hard to keep track of. As well, I don’t know if I would have 3 views; maybe only 2 if I can get away with it. Because of that, each blubbermon would be between 32=6 or 33=9 sprites each. That would mean that, by the time I reached 270 sprites, I would have between 270/6=45 to 270/9=30 blubbermon. Not to mention, another reason I have gripes with animation over sprites in general is consistency. If I don’t have to be drawing the same person 270 times while guaranteeing that they are 100% on-model, then that’ll also be a lot of stuff that I can stop worrying about.
That said, I still understand what you are saying. 270 sprites is quite a lot, while 30-45 creatures isn’t. I think that Blubbermon could be doable if I paced myself better than I did with SotFK, but it is still gonna be a lot of work. The platformer is definitely the low-work game option.
Finally, I am not going to cancel SotFK. If I said to cancel it, I probably misspoke. I want to hold off on it until I can grasp what I wanna do to make it either fit into a smaller box or easier to work on in its giant size. Still, thanks for the comment, I like being able to get good feedback like this that a survey can’t really provide
So, if I do delay SotFK, I will likely not be using the same code I have been using when I return. The main point of delaying it isn’t just so I have more experience to tackle it, but also so that I can better figure out what I want the game to be. Everything outside of the battle and experience systems on the current version were pretty much afterthoughts, which is why the game has had so much stuff pile on top of it to try and make it better. If I do delay the game, before I come back, I will likely sit down and fully think all of this stuff out, which will likely lead to a game much different than the current incarnation. I will refactor everything and keep working on the current version of the code if the verdict does land in favor of SotFK, but I will likely start anew code-wise if I decide to come back later. After all, seemingly self-documenting code looks a lot less readable after several months of distance.
Also, since you know the community, do you know what I should do in regards of getting help here? I can’t afford to pay anyone for a freeware passion project like this, but I’d feel horrible asking people to do free work for me.
Growing the character was fun to watch. Your care really shows in the animations, and it made me wonder how many sprites you had to make for the game so far. It seems like you put in a lot of work!
I was wondering where the title came from. Do you mind sharing what the background for that was? I think knowing what sort of world we’re playing in would help tons with figuring out where to go with this game. The same goes for the other two ideas!
The story is still kinda being developed for all three games, but SotFK has a lot more in that department because of how long I’ve been working on it. So, without further ado…
Long, long ago, the world was united under a benevolent king. He was known to all as the Fat King due to his immensely obese size, and he kept the world peaceful. However, he had no heir, so after he had passed away, the kingdom crumbled. Before he died, he told those closest to him that their children would be the new heirs to the throne, and that the first person to surpass 1,000 lbs to follow in his wake would be destined to reunite the kingdom. Thousands of years and thousands of failed attempts later, the world looked as if it would never get its fat king. And then the player shows up.
The main plotline is fairly basic and just an excuse to get the player gaining, but there are a lot more smaller details surrounding it, such as who populates the world and who helps the player on their calorie-driven quest ^^
Ooh, a succession war. I like it! It would be pretty fun to have a rival in this game who was trying to reach that milestone first. And the bigger you are, the harder it is to move around or even just maintain the weight you’re at. Then you’d also be racing for magical artifacts that help you stay mobile, or digest faster, or find food. You’re trying to gain weight while keeping up with your rival and fighting them when your paths cross–maybe stuff them so full of food that they can’t move for a while, giving you a head start to the next artifact! Rivals are fun~
In regards of getting help, I suspect in the first instance posting here is a good start:
Obviously the re-booted boards are all a bit new, but there’s a coders group you can register for too (I think you can only apply for one group in each 24hrs). Exactly how that group works is really a question for @grotlover2 (in the fullness of time - I imagine he’s really busy right now).
You may be suprised that people want to contribute to things for free, for a little kudos, or just because they’ve the chance to help make something they like the sound of happen. Afterall we all get enjoyment out of playing these things at the end of the day.
You’ve already made a start by putting SotFK on Github. Having distributed source control makes code contributions so much easier. Even if it’s simple asks like “Can I do x better?”, being able to see the source as a whole makes it easy for the rest of us to suggest things. Maybe start any new project on there? Oh yes, and code assuming someone else will be reading/changing it so comments and JavaDoc (or it’s equivalent). It requires a bit more discipline and time for sure, but it does pay off, even if that other person is yourself some years down the line!
Thanks for the continued help! I tend to get mixed messages when it comes to commenting, though; I know I should use Javadoc and such, but in terms of normal commenting, my college professors say that it’s better to strive for code that is self-documenting than to clutter your code with too many comments. What do you think is best, or at least a good middle ground to aim towards?
Ya I just picked some arbitrary numbers for example so I expected my math to be off . Happy you found it useful and as @dingotush mentioned feel free to ask any question or for help on your game. This communities goal is to help games like yours become full games after all.
I agree that in the best case the code should essentially document itself, providing members and methods are well named. Sometimes though the code is far simpler than what is causes to happen, or more complex than you’d expect it to have to be.
My personal rules are (which I don’t always stick to - I’m no saint):
Javadoc every class, method, and member. This gets you a long way to documenting most things. I do members because I’ve found these I what I forget the use of most. Having the generated Javadoc open in a web browser is easier to browse and search than using the facilities of an IDE I find.
If the code doesn’t adequetly explain what’s happening add a comment (or refactor the code).
If the method body is getting long add comments for each broad chunk of code.
If the code is intrinsicly complex, like parsers, multithreading, exception handling, using reflection be more generous with comments.
If you’ve intentionally left something out to come back to it later add a comment explaining what should go there and end it with “TODO” or “FIX!” Your IDE can likely find and flag these.
If you’ve found a bug and had to add additional code also add a comment explaining the changed code lest you have a “Why did I do that?” moment and are tempted to change it back later!
I had a poke around in my own code to try and find a simplish example (and actually found a bug elsewhere because the code didn’t do what the Javadoc/comments said it should do). Anyway here’s a fairly typical example of what I do. Let’s see how mangled the board makes it, and if it makes sense without any other context than Yaffaif being a text adventure…
package gamef.model.act;
import gamef.Debug;
import gamef.model.GameSpace;
import gamef.model.act.part.ActPartAutoCloseExit;
import gamef.model.act.part.ActPartCombatFlee;
import gamef.model.act.part.ActPartLeaveExit;
import gamef.model.act.part.ActPartMobilityExit;
import gamef.model.act.part.ActPartOpenExit;
import gamef.model.act.part.ActPartStandUp;
import gamef.model.act.part.ActPartUnlockExit;
import gamef.model.chars.Actor;
import gamef.model.loc.Exit;
import gamef.model.msg.MsgList;
/**
* Action to use an exit to pass from one location to another.
* This may consists of many small steps: unlocking, opening,
* leaving, arriving, closing, locking.
*
* @version $Revision: 1.27 $
* @author David Cooke
*/
public class ActionUseExit
extends AbsActActor
{
private static final long serialVersionUID = 2012061601L;
/**
* The exit being used.
*/
Exit exitM;
/**
* Construct the action.
*
* @param actor the actor using the exit
* @param exit the exit being used
*/
public ActionUseExit(Actor actor, Exit exit)
{
super(actor);
exitM = exit;
}
/**
* Invoke the action.
* This compound action is split into many action parts.
*
* @param space the game space
* @param msgs the message list
*/
@Override
public void invoke(GameSpace space, MsgList msgs)
{
Actor actor = getActor();
// Set visibility fot the first part. When the move happens visibility
// will change.
//
setActVis(actor);
if (Debug.isOnFor(this))
Debug.debug(this, "invoke(space, msgs) " + actor.debugId());
// Moving while in combat is an attempt to flee that may or may not be
// successful.
//
if (space.isInCombat(actor))
append(new ActPartCombatFlee(actor));
// If the actor is sitting or lying down then get up.
//
if (!actor.getPose().isMobile())
append(new ActPartStandUp(actor));
// What if they are caught in the sub-loc? Eg. a cage. FIX!
// Unlock, open, check they can move and fit through.
//
append(new ActPartUnlockExit(actor, exitM));
append(new ActPartOpenExit(actor, exitM));
append(new ActPartMobilityExit(actor, exitM));
// Leave the old location. This adds new parts as needed for arriving at the new
// location such as warming up the new area, arriving, activating
// traps etc.
//
append(new ActPartLeaveExit(actor, exitM, false));
// Deal with cases where the exit closes itself (like a swing door),
// rather than the pc/npc choosing to do so.
//
if (exitM.isCloseAuto())
append(new ActPartAutoCloseExit(actor, exitM));
execNext(space, msgs);
}
/**
* Get the exit being used.
*
* @return the exit
*/
public Exit getExit()
{
return exitM;
}
}
I also follow a personal mishmash of the original Indian Hills style guide (the ones I can find on the net have been heavily adulterated to remove anything except KnR braces) and GNU style. Somewhere along the way, when C++ was new, I picked up the habit of postfixing members with ‘M’ - I find it clearer than endless references to “this”.
Thanks one last time for the help, this will help me a lot with whatever I end up doing in the future, both inside & outside of the fatfur games I’m doing ^w^
. Happy you found it useful and as