Development fatigue is a serious issue,
it takes drive to push yourself and work on those parts you hate
(e.g) the art if your not a great artist or programming if coding something new.
Although I say you still learn from all those failed attempts.
Nothing is a waste of time.
Its so important to remember where video games came from.
Its getting harder by the day with a lot of noise from established games and vanity (we all want to make our dream game).
Prototyping is probably the most important part of making a game (besides finishing it) its about getting that spark first,
I think with a good prototype you wont have to worry about game fatigue (you tell me).
[Developer's Fatigue:] Alot of what you said is true, but not necessarily all the time.
A good outline-plan (prototype) benefits the developer immensely so,
I agree but it isn't always the judging factor of development fatigue.
It can come from many places actually,
depending so much on the development process,
and how you go about working on your game/project.
. . .
Some of the things you went over, such as
no failed project is a failed product. It's always imperative to
pick up and learn from mistakes and errors, as it improves yourself for the next
project that comes along. Thus time is never wasted, like rollover minutes.
As for pre-established vanity from existing modern games and
creating your own dream game, I agree that it's important to recognize
your own abilities and the time frame in which you can accomplish something.
For example, it's important to note that Sphere is 2D Rpgs and you shouldn't
attempt to try and make the next Call of Duty out of it. Though neither should
you attempt to create the next Final Fantasy VI on your first go around either.
Depending on the challenge level of the project being developed, you could
easily find yourself becoming anxious at the heavy amount of programming
that'll be needed, or cursing yourself at the skill level that would be required.
For those incidents, I like to look at this chart:
[Logic One:] The higher your skill level and the lower the challenge, the more ease of development and progress.
[Logic Two:] The lower your skill level the higher the challenge, the more difficult it is to accomplish.
. . .
For myself, these are the Top 5 issues that come
about with causing development fatigue:
1.) Familiarize the Language - reading comprehension is a must. You wouldn't try establishing independence from a ruling foreign country if you didn't know their language, neither should you attempt to break into the indie gaming industry scripting in a language that seems entirely foreign to you. The importance here is practice, as it's the only way to develop reading comprehension. Especially if programming is a new thing to you, even Javascript can seem as an overcomplicated language to most infant eyes. Once you're able to read Javascript, and logically deduct what is happening in a script written by another person, then you're ready to go out on your own and swim without your floaty's.
2.) Entertainment - it's always important you pick the right project that motivates you in interest. Something that will feel like an accomplishment every time a piece of it is finished, and will drive you to complete more of it. Goals are another important factor in this, but it's important to make sure the goals are in small increments from each other. Too much range from one goal to another will cause either boredom or frustration, and too small of a range in goals will feel like you're not accomplishing much of anything (due to the lack of challenge, refer to chart's "apathy"). It's a great deal of importance to recognize that most of what we're doing here is hobby, something to do in our free time. Once your spend too much time 'pushing' yourself and the project becomes a chore, then procrastination or frustration sets in. Remember to keep that enthusiasm rejuvenated!
3.) Feedback - pair programming or having someone to look over your shoulder and criticize your work is important factor also. If there's no audience but yourself, then the feel of accomplishment is short lived and is unpropelled by an outside source. This is why communities like Spherical shine through for me, because they're not only there to help and support, but eager to see your work as well. There's nothing better than another opinion to hurdle you over roadblocks and to apply teaching or discipline when needed.
4.) Productivity & Procrastination - again, this is where goals and having an outline helps. It also has to do with the size of the project. If it too much or takes too long to accomplish even the minor goals of the project, then becoming bored becomes perfectly natural for anyone. The way I personally deal with productivity is to complete atleast one function or one system everyday. If you've done that, no need to push yourself and be happy with what you have done for that day. Never overwork yourself, because again, once a hobby becomes a chore it's no longer a hobby. It's a bore.
5.) Brevity & Breaks - always keep the project fresh in your mind, like a girlfriend you take out on the weekends but never have to live with. It's important to keep a distance. Once you start living with her, you begin to hone in on each other's flaws and imperfections, then onsets a negative attitude towards it. How I deal with this personally is everytime I become a bit bored or don't feel like coding anymore, I go outside and exercise or skateboard. When I come back inside, my head is clear and I'm ready to code again. Sometimes I'll simply just pace around the house while I think about what is there next to do programming wise, or try to get some artistic visualization of an image or scene in my head. Take a breather, it's important.
I've noticed taking breaks are probably the most beneficial when programming, in my opinion,
because every time I've quit for awhile I've always came back with a better or more familar approach
to scripting and creating projects in general. It's as if your brain subtlety learns how to perform better
when it has a minute to think about what it has done and accomplished so far.
. . .
Also note, that with Battle Systems even the most simple of ones require graphics first,
such as a font for text and windowstyle for boxes. So Battle Systems need dialogue
and Menu Systems developed before anything else, especially for Turn Based systems.
The way my Development Order Hierarchy works is by completing the things first which
will be needed in the next functions and systems to come along in the programming.
Of all that was listed, only Text (dialogue), Graphics, and Statistics (objects, player, and items)
are independent in comparison to the other things in programming, and should normally come before them.
The hierarchy is organized so that when you finish one thing, you can move onto another without being
overcomplicated by the amount of things needed to do to accomplish/complete what it is that you're working on.
There's also lessons to be learned in programming the things that come before the other, so there's a sense
of progression in difficulty within the organization of the hierarchy as it was being created.
Such as: Learning how to implement choices and conditionals before working on things like Tile Movement.
Note again, recognize that Battle Systems and Movement are the two most problematic parts in most projects,
reason because you'll always be going back to rework something into them until the project is finished.
Most things like initiating functions during collision detection will have to be worked into the movement as
work is being developed on an action battle system, for example.
Apologies for the late reply also, slept in late and didn't wake till about midnight.
Have a feeling it's going to be a loooong Monday. And anyone feel free to use this information to be adapted into a tutorial if you wish.
I'm thinking about making some, but it's going to be awhile before I'm able to with most of my time focused on my project still and all.