I have made a decent amount of progress today.

The math library is almost fully functional now, just a few bugs in the rotation functions.

I am very very close on having textures working, probably just a small opengl binding issue.

If we can stay on track tomorrow, we hope to start actually turning what up until now has basically been engine work into an actual game.

Here is a quick image just to show things can move!

Thanks, Matthew

Cannot do anything on two first days, got other agendas. And the theme "One Room" is the most difficult option for me. Luckily, I have a rough idea on what I will make --thought about it in those two days where I cannot do anything with computer. From that rough idea I got the name for this entry, that is "Anttractor" (ant attractor). I don't know if that sounds cheesy :P, but that's the first name I could come up with and the name could give a big idea about what kind of game it will be. What concerns me is whether I have the adequate skill to make it --I'm still learning at coding. The best option for me now might be to make a kind of "survival-mode" game, so there will be no levels (no level-editing too, yeay!). My priority is to finish a game, not make it perfect. Let's see if I really could finish the game. Will have time to work on it this night and a whole day tomorrow. Hope I could get the main gameplay done.

So only a bit more progress from earlier.
Fixed a bug with GIFImage where it was handling some GIFs poorly and causing them to be all stacked and yucky - probably due to being additive gifs.
Got an updated Zombie - though it still needs work.
Fixed the day/night cycle to be nice and smooth.
Added Map Labels and Icons, you can see the HPBarIcon.

I am happy with how easy it was to add the icons (basically exact same code for zombies and survivalist) - but not so happy with how closely I have "stacked" my logical objects on top of the map entities representing them, seems like I am asking for trouble, but short on time so no fixing for now.
Finally, we have the start to our map spawning, with just the house, some trees and some initial zombies around.

Still left to do are adding a lot more buildings, characters and zombie types, and getting the generation all correct on those. Once that is in getting inventory/skills in, along with interacting with objects, to round out the core features.
Lastly will be adding actual combat and the zombie logic, which will likely be the last two days, we'll see.

After a second night of coding I have a basic pysdl2-cfffi RenderCopyEx-based renderer for PyTMX maps that supports flipped and rotated tiles (the tile layer, not the object layer). I'm not 100% sure it matches Tiled in every case, but it is really nice to be able to get more mileage out of the same tiles by spinning them around. It took me a while to figure out that you can use the X, Y, and Z keys inside Tiled for flip & rotate; the keyboard shortcuts don't seem to be shown in the menus at all; you have to use the online docs.

An input class keeps track of gamepad add/remove events and synthesizes the keyboard and gamepad states at the beginning of each frame into more useful "x motion", "y motion" and "jump" states. And you can scroll around the little map to prove the input is working.

The game also has a 2-screen intro with an image and some sdl.renderUTF8_Blended_Wrapped text - a handy under-documented function that renders several lines of text in one call.

So far I'm very pleased with how much better organized the code is than my previous SDL adventures. Instead of having a giant game loop with everything, it has a simple game loop that delegates to classes that take care of the different aspects of what the program has to do. I'm hoping to be able to keep the core event loop generic and have it always just call 'render' and 'advance(dt)' on whichever scene is current.

I have completed the game design and basic engine implementation and am now working on the gameplay elements. Since this is a card and dice game these parts are quite simple.

In the game you will play a hit man trying to complete a series of contracts before you are detected by the police. I've never done a card game before and it would probably be a good idea to make a paper prototype for testing but I don't think I really have time to do that so I'm going straight to the code!

I created a pretty detailed plan yesterday and I'm ahead of that right now but I know how that can change all of a sudden!

Unfortunately I'm not using one. I have a library for this that I wrote in like 50 lines of JavaScript, and I've been using it for the past year or two. Going back to the old way with a class hierarchy really makes me appreciate what I'm missing. It feels so clunky, I don't know how I put up with it for so long. My classes are already a mess and I'm just getting started.

At some point I'll have to port my JavaScript library to python. I'm not sure how exactly I'm going to do that. JavaScript's prototype-based inheritance system made writing it really easy and natural, and I don't think it'll work as well with python's more traditional system. But if I can figure it out, it would really be worth it!

I have had quite the large day on Monday of Pyweek 19. I have finished all the click actions for the items (when you click on them, stuff appears) and the clock now turns orange at 50 and red at 30 to simulate almost out of time. The bigger stuff is I added the actions. Only 2 actions per button are finished (Examine and Nevermind) and am working on finishing them. After that all I have left is the crafting system and the system to place the solar panel and then win/loose! Wish me luck! -- Hunter K. Variant Productions

I added monsters and begun the slot machine

I've managed to add in my first baddie! At the moment, the baddie has no AI, but I've also included code for having both the player and the baddie take damage and die. The player even does a little spinning death when he dies, like in LoZ.

I've made solid progress on the game engine today. I can now play complete sections of the script, and also drop into interactive mode to click on things, adventure game style. It has largely been coupled through the script system I mentioned yesterday, so all of the dialogue and cutscenes are completely data-driven from the start.

It's quite a powerful technique, and it reminds me of things like lettuce-style BDD tests. I can write a stage direction in the script, and later write the binding in code that implements that stage direction (and each character might have different stage directions implemented). This lets me completely separate the activities of designing the story and programming an adventure game. But the script system goes beyond just a list of steps: directives let me play arbitrary bits of script in response to events, so even looking at an object can trigger a dialogue between the characters.

I can't give too many screenshots without giving away bits of the story, so here's Ralph's walk cycle. Ralph is your buddy, who will drop in at various points and give you useful advice.