In prior competitions, my team's submissions have always been very asset-heavy. This time I've decided to have zero data files and accomplish all visual effects procedurally. It looks like my game will have no sound unless a time fairy visits me.

I'm... really disgusted with my collision detection system. It's terrible. I tested it. Things jitter, shake, and twitch, and I'm not even using physics. D:

*Sigh* I guess now I have to either redo everything using pygame.sprite... or have a really bad entry.

It's looking more and more like I won't finish.

Now I need to learn pygame.sprite in under three days.

*Hangs head* I wish I hadn't been so stubborn about coding everything the hard way. Now look at it. It's a mess. It's a horrible mess.

I'm debating whether I want to continue. I want to finish this game, but I'm not sure how badly I want to. I've got it stripped down to its core and I still can't get it to work.

I may not submit my entry. In the state it is in now, I don't want it out in the world with my name on it. I will be trying to rework the collision, but I'm not sure how quickly I can do that, and I still have to figure out the level generator.

I'm very pessimistic right now. I've looked over my collision code, and it would be extremely difficult to fix it, and the resulting code would either be a monstrosity, or take a day or two for me to get working properly, depending on whether I fix what I have or start over on the collision code. And implementing pygame.sprite, from what I know about it, means that very, VERY little of what I have code-wise, and even then only game constants, will still be usable.

I'm still thinking it over, but I may decide to forfeit. This project has been one disaster after another. I want to have an entry, I don't want to look like a twit entering in a contest and then giving up, but I don't know that I can finish. So I may be giving up.

It's been fun, though. And I'll definitely enter again, but this time around I don't think I'm going to be able to get it working in time.

Not sure how to end this message, but... That's it, I suppose. :(

----====----

I'm leaning towards giving up. If I do, I'll probably finish this game later, but I'll shelve the idea for when I've learned pygame.sprite.

It was really foolish of me to try to make a platformer without using it, but it's really counter to the way I'm used to thinking. I have a hard time with high-level libraries. :/

I really don't feel comfortable submitting this as-is, but the stress of trying to debug the collision engine may be getting to me.

I'm unsure of whether I can finish in time. I can't figure out pygame.sprite for the life of me, and I need it to do the collisions correctly. :/

Any good tutorials on sprites in pygame? Or should I just throw in the towel?
Feedback would be really appreciated.

----

I'm reading through a tutorial on sprites, and I'm also learning just how little Python I really know. ._.

I'm officially putting my project on hold for now. I haven't decided whether I'm going to forfeit, but it doesn't look like I'll be able to finish in time and not miss most of my homework.

It's been fun, guys. Hopefully it'll all go better next time around.

Today I hope to get the bulk of the work done. There isn't too much to do, but it needs to be done. I've been mostly making the code up as I go along, but it's still coming along. I should have something that can be tested some time today, and probably at least have it fully playable and working by tomorrow, possibly with the option to tweak some of the settings of the level generator.

I'm giving the responsibility for collision detections to the player object, as well as responsibility for movement. I've also decided that the level generator object will have a platform maker-and-positioner as one of its attributes. That should greatly simplify writing the level-generating code. I've made five different platforms:Four normal ones and one for the goal point of the level. I've also made sprites of branches complete with string holding on to the platform, and also some of string coils for attaching one platform to another. The platform maker will position those automatically.

The level generator which will operate the platform maker will have the following settings, which I will add the option to tweak from a menu if I have time:
1.Length of Level (In feet, automatically converted to inches, then to pixels)
2.Density of Platforms (By how many per five feet of level on average)
3.Platform Height Range (By how many feet the platforms can be apart height-wise)
4.Platform Height Preference (By what part of the screen)

Also:Option #4 will have more of an effect as the value of option #3 decreases

The acceptable ranges of value for these parameters are as follows:
1.Ten to Fifty
2.One to Four
3.Zero to Three
4.Low, Middle, or High

Also:Number settings from menus will be in the form of "Sliders" that will only allow whole numbers, settings from within the code, though, can be any number.
(It's worth noting that I've put this under the GPLv3, so you can go ahead and change the level generator around so that it can accept different values. It's fine. I'm just setting mine up so that it can only be set up to use those values)
In the menus, the up and down keys will change the selected menu item, and enter will pick it. Also, moving the mouse over an option will select it, and clicking it will select it.
The one exception to this design will be the level generator settings menu. There, the left and right keys will select the option, the up and down keys will change the setting slowly (IE:Increase or decrease by one at a time), and the page up and page down keys will change the setting quickly. (The Density by two at a time, Length by five at a time, Range still by one at a time, and will set Height to High with Page Up, Low with Page Down). The mouse will work as well. Left-clicking an option will increase it like page up, except for Height, which will increase by one. Right clicking does the same, but decreases it. The mouse wheel will change values by one, increasing them when it is rolled up, and decreasing them when it is rolled down.

I've also worked out the controls. The A and D keys will make the player move left and right, the space bar will make the player jump, and the Q, W, E, and R keys will make the player throw the string at different angles. I may implement using the mouse to throw string, if I have time.
The player will be able to run at about five feet per second, jump up about five feet, and throw the string about three feet.

So... I have a plan for this, and I'm sticking to this one. :D

Nice and simple, easy to implement, and should be fun to play, too. ^_^

Now I'mma get back to coding. ;)

Another day of pretty good progress. I started out with some fun stuff, incorporating visual feedback of actions partaken by characters in the game simulation. Animations. Cool ones :)

My email program is refusing to start up, so I've lost my SVN logs for the day. This one's going to be a little more terse than usual.

Once I'd gotten the animations out of my system I knuckled down to the less-exciting inventory management screens. After some more IRC discussion on the topic I had a solid plan and managed to knock out the bulk of the code pretty quickly. There's still some user interface issues (like lack of feedback and no instructions). But the core is there.

cfuller contributed a world map view which I proceeded to mangle to fit into the game. The town icon above is one I threw together to be used on that map.

I moved on to putting in place the initial implementation of a skills system, and incorporated some initial skills into the combat and spell-casting actions.

I finished the day overhauling the character status displays in the tactical game user interface. That exposed some problems with the events triggered by damage, movement, etc. which I've also now fixed.

So far it's a playable game, but it's still missing chunks and I'm not convinced it'll be finished by Sunday.

I'm making good progress. Made some improvements to the level editor, added some more artwork, and created the first three levels -- very easy ones to begin with, to teach you the basics. Will have to come up with something more challenging tomorrow.

day2 and 3:
game loop, levels state basics done.
freeze and running step by step implemented

day 4: finally the basic gameloop, time services, and level
container is in order. Can freeze and do step by step.
Main Character redrawed, an draw some but not all animations for him.
Code for playing animations near finished.

Ideas for 13+ levels, but I fear...

Cuack! Need Time !!!

### plan: concentrate in the minimun to have at least some levels playables.
To h*** with niceties. Fast and dirty. Go Go Go!!!

too tired for diary entry. make brain crazy fuzzy no understand pyglet flip_x...

edit: link in screenshot:

Today I finished all the practical aspects of the game. Play mode works finally (figuring out timings for note spawns and strums was tricky) and jam mode feels good. I'd like to make charting out songs easier but for now good ol' vim and patience is doing just fine. From here on I'll be polishing everything up as much as possible before time expires. If it all works out, I will have time to implement a few more features I have in mind.

Well, it was an uber busy day for me, and then I haven't been feeling well this past little bit it has been quiet :S
So a bit behind schedule, but not bad. Markus is still working on lots of the things planned, so maybe those will come through - but the GUI *MUST* get done tomorrow now...

G'night all ;)

End of day 4(Morning of day 5)

There is currently no fun in my game... at all. I'm wondering how i'm going to be able to fix that.

You can now pick up boxes and deliver them and accumulate cash. There is currently no way to damage your ship or your packages, although collisions are working pretty well now, so it shouldn't be too hard to implement.

< 3 days left... need to make it fun!