I think I'm going to ban them from my life... forever. What I wouldn't give to trade in all my large projects for a clean slate.
I'd rather not know I have so many of them sitting around... piling on the weight of failure... ya know...
My latest is in such a tough/complex state that I can't motivate myself to continue each night.
I keep thinking of new (easy) things to do. Anything to keep myself from solving tough problems. :| grrr..
*sigh* - When your bitch sessions are posted more than your progress sessions, something is wrong.
ts
ID:86802
 Dec 2 2009, 7:13 pm
|
|
I know I certainly get bogged down with trying to make my projects big and extravagant. To an extent, I think it's good practice in that it pushes my poor neurons a bit further as I wrack my brain. However, the bigger the project the easier it is for cognitive dissonance to sneak its way in.
Hmmm, I probably should learn how to bundle my stuff into libraries. For example, I've come up with some working A* pathing that simply works off of turf.Enter(). Whether or not I ever release a game, that library could prove invaluable. | |
Foomer's advice is spot-on. I made and betaed almost every game I've ever done on BYOND in a week or less, and then poured on the features after I already had players who wanted them. I think Pokemon Challenger had about 11 development hours on it before I got some people involved in a real game (20~ waves)
Release fast, iterate often. (I'm not practicing the second one on PC though) | |
Foomer wrote:
Try converting as many game systems as you can into libraries. Converting old projects into a bunch of libraries might be a good way to take "light" breaks from other projects. Great idea. | |
Is there a good guide out there for creating libraries, or is really just as easy as creating a new project and associating it with any project you want to use that code with? (Of course, modular coding would be a requirement.)
| |
I don't know of any guides. Just make sure your code works with absolutely minimal risk of interfering with an existing game. Ideally everything should work through self-contained datums that you interact with through procs. If you find yourself directly modifying or creating too many new variables for things outside of your library's datums, you're probably doing things wrong. But there's always exceptions.
After that, just be sure to include a demo and documentation and package it as a library. Its also a good idea to run it past someone who's experienced in that sort of thing so they can tell you if you're making any huge mistakes or not. | |
Its also really important to have good design information and know exactly how you want things built before you build them. Although sometimes that's pretty hard to do.
I also highly recommend the advice of Brian Reynolds who wrote: "Get something running in the first month that you can actually play. (It doesn't matter if graphics aren't so great.)" If you can do it in less than a month, that's even better. Once you have a playable game, its much easier to find motivation to work on it.
Finally, this is why I keep my projects small. As I've said before, Tomb Explorer only took me two days to finish, while Solar Conquest took me about two weeks. Anything larger than that I get tired of it and give up.