One Fish Two Fish, Red Fish... Dude Fish?

Dumb things can sometimes be the downfall of my programming.

So David went ahead and overhauled some of the current programming structuring, esp. for my sprite object class which was sorely, sorely, sorely needed.  It now reads more like a dictionary of methods instead of the inane ramblings of an amateur programmer.  David: 1 Kevin: 0

And introducing, on the right hand side... oh. Nevermind

So the SpriteObject class I've been babying got it's first minor overhaul, and I must say it looks much nicer, and the plus side is David now, more or less, understands how to use my baby for gameplay purposes.  The only downside is he changed the names of some of the functions so now I get confused sometimes, but the added organization and naming protocols more than make up for the lack of familiarity I now have with the names.  I must admit, my naming conventions got pretty bad at some points.

Almost as bad as this doodle

David's clean-up aside, what have I been working on?  Finishing up patterns and level implementation.  I added a few minor points of functionality for enemy patterns (the ability to flip the patterns horizontally, and the ability to set patterns to looping or non-looping, again, minor points of some limited flexibility) and then spent the better half of my evening trying to figure out why Bill wouldn't go and sit as his freaking assigned target point.

(At this point, I'm working with four enemies sharing a same target pattern with different target offsets, or they all share the same set of points to go to, but they start at different points on the path.  I've named them each.  Bob, Brett, Bill, and Ronald)

I have fixed the bug, but I'm still not entirely sure why Bill kept skipping his target and trying to go to Ronald's before Ronald even had a chance to arrive at his own target.  Needless to say, this is not good and warrant's some more attention... that I shall give at a later date.

Ah, Procrastination

Once I get the levels working, which simply consist of multiple phases built onto one another, the game framework should be finished and me and David should be able to simply add on to the game from here until we have a complete product.

Indeed.

However I'm not entirely sure that I won't just scrap the whole damn pattern/phase system half way through the project in exchange for something more powerful, robust, and flexible.

I toss the term flexibility around often when I discuss code, to me flexibility is a piece of code's ability to handle many different situations and preform more in fewer functions.  Not fewer lines of code, optimization is not my strong suit, but simply give a few pieces of code that do lots of good, juicy work.  The more I look at the current pattern/phase system I've developed, the more I'm convinced that a new system will have to be created, and this time I'll have to really sit down and think through what I want the system to do well in advance of the start of my coding. 

or not.

...That's funny, it seems like somebody has given me similiar advice before....
Oh, right.  My professor.
Turns out I should listen to College Professors, who knew?!  My great enthusiasm to begin a project does not protect me from poor spur-of-the-moment implementation! (Though sometimes that is honestly when I am at my best)

Regardless, The system I have works, I just don't know if it will be able to handle all that David and I will want it to crank out, I designed the system, unintentionally, to be independent, each enemy has their own patterns that aren't known to others which in some instances can be great, but may need to end up changing.  In such an event some may say the current code I have can be salvaged but... Well let's just say it would be probably easier to devise a new system.

Which may make me do this.

It will probably be for the best though, help with my understanding of crucial elements of gameplay.

And how to make my code look as purdy as David's.

Until next time!

How will this end?

Oh.

-Kev