Hi all, I've enjoyed pygame the last two times I've done it, but this time the magic is missing! I think part of it is that my current project is turning out too much like my last one, and I'm reinventing the wheel :) In conclusion, see you all next time!

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!

Since the last diary entry we have made major revisions to many parts of the game. Here is a rough delineation of our progress: - Application Frame work: 95%% - - State Stack : 100% - - Event Signaling : 100% - - Music and Sound : 95% - Graphics: 80% - - Collision Detection : 80% - - TileMapping : 95% - - Rotatable View : 95% - - Splash Screen : 80% - - Art: 10% - Game Mechanics: - - Physics: 0% - - Game Logic: 0% - - Level Design: 0% There's still a lot of work to be done but with DR0ID_ hammering out the collision and graphics and two full days to continue work things are looking good!

I am new to pyweek and I thought this would be a great opportunity for me to learn python. Today is September 5th. I am finally starting to learn python and I have a game idea... woohoo... however with no python lang. experience, the true challenge begins :) Good luck everyone BTW my game idea is: "Battle of the Twisted Tops"

More progress! The game was too easy, now there's an angry dog runnning around the field. I improved the AI both for the opponent and for the dog, but it's still pretty rudimentary.

There's also a single music track that plays endlessly, and a simple level editor. My focus for tonight is creating more rules, a couple of levels, and then the core will be pretty much done.

Tomorrow I need to figure out how to create a GUI, adding input for new rules, a short explanation of the game. After that, more rules until the week is over! :)

I found two more subtle bugs in the alpha-beta pruning. This is a function that is seriously less than 10 lines of code, and was more or less translated from pseudocode in wikipedia. The bugs caused it to improperly prune search paths early, so rather than crashing or showing a blank screen or any of the usual things you get when you make a mistake, it just played a little stupider. I only found the bugs by inspection while optimising the code -- I couldn't tell just from playtesting.

Before finding these bugs I was able to play a close match, but usually win, against the computer with a depth search of 5. Unfortunately the computer took over a minute for each move on my fastest desktop (hence the optimising).

I implemented two standard chess optimisations: iterative-deepening depth first search, and a transposition table. The ID-DFS improves alpha-beta performance (despite appearing on the surface to do more work), and also means I can set a time limit on the search and have it return the best result found so far. The transposition table is a cache, with some tricky code to get it to behave well with the alpha-beta pruning (again, several subtle bugs resulting in less-than-perfect play -- luckily by now I could spot when the computer made a bad move it should have known about).

With both optimisations implemented the depth=5 search takes a maximum of 14 seconds, and typically much faster later on in the game (as the winning path becomes more obvious and the translation table fills up). Because of the bug fixes that came with optimising, the computer beats me consistently even at depth=3 (which is searched in under a second).

I've run a couple of computer vs computer games at various different depths. One apparent design flaw in the game is that the inital player gets a large winning advantage -- a depth=3 player can beat a depth=4 player easily if they move first, and only narrowly loses against depth=5. I might try some slight juggling of the initial position to remedy this; otherwise I could make games happen in two rounds, at either side of the court.

Next stop: pretty graphics.

too much work, couldn't do a anything for pyweek so far.

still, I want to produce *something*. So I came up with the idea of doing a super-simple rts. like so:

• Both players have a group of starting forces
• The need to capture factories, which produce new units every x seconds (if someone owns them).
• flag-capture-win-condition a la battlefield maybe?

Game duration should be 5min, only 2 players. Only 3-5 unit types, which differ in speed/attackrange/attackstrengh/defense

My plan is to write a simple prototype and then make it work in a browser ... ajax ahoi. going browser-based will probably make it akward to play, but it should be a proof-of-concept of some type

I had to work most of the time since the competition started but the next few days are dedicated for pure pyweek Added some selectable options on the title screen, including a function to scan any available level files and let you choose one Wrote most of the class to load a level xml file and parse it Still using a hardcoded test level, need to switch it to the new xml format to test it out Next ----- Render the loaded xml level Add collision code for loaded objects and platforms Create a level editor for the xml files then can start adding enemies, objects and possibly objectives

Hi!

Since I only have one day left to do as much as I can for my own project, I am sorry that I have to announce that I will not be able to do any more playtesting for others this week.

I have fallen so far behind schedule that I need all time I have if I want to get even a light version of the game finished.

I am really sorry about this selfishness, especially after asking people to help me with my playtesting, but I hope people can forgive me.

I will be back by the time judging takes place, so I am looking forward to see and hand out points to Drakko's game and all the other games.

Deathworks

Hi!

I have uploaded the new test version.

Changes include:

* Reduced most version checking to simple warnings. (Thanks go to Tee)
* Added automatic disabling of full screen (needs test with problem system) as well as non-full-screen version.
* Added first level of in-game-menu
* Number pad RETURN is now handled as 'confirm' as well and number pad 0 has been added to 'cancel'
* Removed unnecessary '()' from creature class definition (Thanks go to ServalKatze)

This version includes font rendering in the in-game menu, leaving only pad input absolutely untested (although there are one or two font routines I may later implement that may cause additional problems.

All in all, my programming speed wasn't bad - well, when I was programming and not sleeping.

As things are, I will probably not be able to finish the game. I will try to finish the basic item handling code and inventory functions today, as well as implementing a basic event system.

If that works out, I might be able to create enough content for a light, no-combat version of the game - probably having a lot of unused features included in the code (^_^;;

Anyhow, even if I fail at that, doing this has been worth it, since I think I can use the engine as a good basis for creating my proper engine. Looking at it, I see that it is much closer or at least more easily adapted to a more flexible implementation than I have initially thought. So, rather than salvaging, I guess, it will be an expansion :) :) :)

So, I will give my best during this final day. I hope that the absence of crash reports means that the test versions thus far have worked fine on most machines.

Deathworks