For my next game, I've been thinking I'd need a couple of new pieces of EyeCandy. For the uninitiated, EyeCandy is an extremely useful little object I put together a buncha months ago. It's basically a non-interactive sprite that kills itself after a given time. In my old games, things like explosions were a pain because I had to keep track of 'em, drawing each frame and killing it at the end. Now they're easy, I just create a new Explosion object and let it go. It hooks into the timer, draws itself, and cleans itself up, leaving only the fresh scent of pine.
Anyway, I've got a couple of cute pieces of EyeCandy, explosions and sparkles. I've been meaning to make puffs of smoke that the vegetables in Olive Wars can leave behind as they fall out of the sky.
I dunno why I didn't think of this sooner, but I need to make some EyeCandy numbers that display for a short time and disappear. Remember in "Pac Man" when you ran over a ghost? A little score appeared in its place for a short time. Such a thing would be perfect for EyeCandy. With some of my behavior stuff, I could even make the scores bounce-n-wiggle. I'll probably work on it next week.
On a related note, has anyone ever created an object model that they were completely happy with when the project was implemented? It seems that my projects go like this. . .
- Design object model
- Create headers and code
- Get model working and debug model
- Realize that the model would've worked better if designed differently
- Return to top
Unfortunately, the cycle appears to be endless. If I go back and redesign, I often find an even better way of doing it, or I find out that my new model is over-engineered, and it doesn't really work any better than my old one.
This came up because I was thinking of new and creative ways of doing Sprite objects. Coming up with movement behaviors and attaching them to Sprites isn't really possible in my current model, but it sure would be cool. Moving Sprite objects around, however, is quite simple right now, and I don't know if making some kind of "Mover" algorithmic object that can be attached to a Sprite would really make things better. I think it's gonna end up being one of those questions for the ages, because my Sprites work and they're easy to use.
If I ever find the rules that govern the mysterious "redesign vs. don't-mess-with-it" point, I'll write a book.
My book will be subtitled "What the government doesn't want you to know about the deadly year 2000 crisis" so I'll sell a lot of copies :)
Finally, I must state that rec.games.programmer is not going through a phase of juvenile newbie flamewar wannabe-itis --it's always been that way! People have been talking about breaking up r.g.p into a collection of "serious" groups since 1992 with zero success.
IMHO, every primary schooler who's learning to program is doing it so he can write games. Rec.games.programmer is always gonna be the front-line in attracting that element. Serious discussion of game development is always gonna be second-tier for that group.
Sorry about the rant. There have just recently been a set of forged "I'm a gay programmer" posts on the group (yes, 7th grade "you're a fag" humor). I can only assume that somebody's OS or graphics card was insulted :)
