Do not confuse this with the official Skellington for PyWeek - the package is based on Skellington 1.10, but adds extra functionality some might find useful but others might not need. It's not a game engine, but rather a nice package of generic code I've found useful in game projects in the past. It's also very much in the beta stages, so bugs should be expected. I might be testing it more thoroughly during the PyWeek warmup, but since the rules state any code must be released one month before the competition, I won't be making any more updates even for my own use until after PyWeek.

I don't like repeating myself, so head for the Skellington Plus project's home page for more complete information.

Let's see - it's two days into PyWeek, I have worked all Monday and what do I have to show for it? A chat server and a client with a nice looking background, basically. Still, I don't think that's a particularly small feat, considering I've never done network programming in the past. I have a game concept I like very much (more on that later, let's just say it's turn based strategy), plans for both multiplayer maps and a single player tutorial, and I think I'll nail the game balance too. I hope I'll be able to implement at least the basic gameplay features by Wednesday evening, so I'll have enough time for testing it all.

Some people have warned me that it's hard to find an audience for a multiplayer-focused game in PyWeek, but I hope that at least some of you will actually play my game too. It's not that troublesome to arrange matches on IRC, and I'll be taking the simultaneous turns approach to minimize waiting time between turns. Anyway, it's already been an educational and fun experience, and I haven't even gotten to the game part yet, so hopes are high. Have fun, everyone!

Wednesday is forever lost. I had to go to school today, and didn't make as much progress as I hoped to. :P Well, I still have 2,5 days left before I'll go to visit Helsinki this Saturday. There's not much time for beta testing, but I'll try to live with it. I didn't really anticipate how much time I'd have to spend just to get the client-server relationship of a multiplayer game working, so I've had to work quite hard to get even this far, but I'm still confident I'll have something to show you guys when the week is over. And it'll be a turn-based online multiplayer strategy game.

My game concept is centered around two things: the rock-paper-scissors relationship so often seen in strategy games (though this time the player actually controls an army of rocks, paper and scissors), and yomi. The twisting factor combines these two aspects - any turn any player can pay a certain amount of resources to use the 'twist it!' -button to turn the rock-paper-scissors relationships upside down. This can turn battles in the favor of the player that used the feature, but if the opponent anticipates this move, he can counter it with a clever placement of his own troops - or by using the 'twist it!' -button himself!

This will transform the battle into a mind game, as the players try to outguess and outsmart their competition. At least if I ever get my code working like I have planned. :P I might have to drop single player and some extra features like fog of war and unit splitting and joining, but the core of the game should work without them. Have fun coding, everyone!

I just uploaded the first playable (at least sort of) version of my game. It still has glitches, bugs and all sorts of other evil thingies, but the basic engine is there.

To be done before end of PyWeek:

• Finish unit buying functionality (buying at the second base slot, disabling buying when an unit was in the slot at the beginning of the turn)
• Add twisting function
• Add checking of victory conditions
• Add sound effects

Well, at least I completed something. I have a feeling that I tried to tackle a bit more than I could handle in a week, but at least I've been learning a lot of stuff and improving and testing Splush. I'll publish a more complete post mortem next week.

Everything is over. Still waiting for the torrent, but I guess it's the right time to analyze my doings a little. My approach to coding was quite different from last time, and didn't work quite as well, but at least I learned a few valuable lessons.

Stuff that I did right this time:

• Didn't give up, even when it seemed quite hopeless to finish the game as I had planned. In the end, I have some sort of a game, even if I it doesn't have all the features I would've liked it to have.
• Increased my supply of generic utility functions to ease coding.

Stuff that I didn't do right:

• Bit a little more than I could chew. If I had really been able to use the whole week, the game might've been more complete. But I started a bit late and finished early, and my early plans were way too ambitious for a one week, one man project.
• Didn't test the game nearly enough. Even the final version has some trivial bugs that crash the game or make it behave in a way it shouldn't. And I'm still not sure if the game is balanced or not.
• Didn't plan my architecture well enough. Ok, I was new to network programming anyway, and didn't quite know what it would take. Anyway, I'll have plenty of restructuring work ahead of me.

And finally, the fix to make the game not crash when trying to join a game. On line 77 in main.py, replace

          if (input_addr != None):

with

          if (address != None):

and the game should connect instead of crashing. I also found one other bug - having an unit in the first buy slot in a base can block buying at the second slot, and buying at the second slot might result in errors. Both bugs are fixed in a new version I'm working on now, and I'll publish a new version of the game and also an updated version of Splush after PyWeek voting has finished.

Finally, one site suggestion for richard: Add an author tag to the Diaries RSS entries. Should really help in organizing them.

Seems like my game worked even worse than I thought it did - I suppose most of the crashes and weird behavior is because of the network architecture, though I haven't completely ruled out the possibility of some logical error either. I might have to declare the whole project a failure for now, and not continue working on it. Overall I still like the game design I had, but seems like I don't yet have the time or the knowledge required to properly implement it. Perhaps using an existing network library (Twisted?) would have yielded better results. One bug reported in the feedback was a bit more weird - this one:

Traceback (most recent call last): File "C:\Downloads\pyweek\tubasc_robast-0.6.9\run_game.py", line 16, in main.main() File "C:\Downloads\pyweek\tubasc_robast-0.6.9\lib\main.py", line 27, in main parse_config() File "C:\Downloads\pyweek\tubasc_robast-0.6.9\lib\util.py", line 71, in parse_ config file_path = os.path.join(get_config_path(), "config.txt") File "C:\Downloads\pyweek\tubasc_robast-0.6.9\lib\util.py", line 52, in get_config_path os.mkdir(path_name) WindowsError: [Error 3] The system can not find the given path: '%USERPROFILE%\\.tubascrobast'

The code this traceback refers to is included in Splush and has been used in Which way is up too, and I have not heard it misbehaving in the past. I'd like to know the operating system of the respondent, and how his environment variables HOME and/or APPDATA are configured. I'll probably continue using the piece of code in future projects too, so making it as bug free as possible is an important concern for me.