Do you smell that? yep - Progress! ^^

I finished some graphics for the game (the board now surely is done from the graphical perspective).

Serval added the functionality to the second button and started working on the editor. The editor even works for creating simple 5x5 Levels - so we are definitely on track! :D

But we will not finish today as predicted earlier by me... As currently the ideas for our game are just "flowing" - currently we have more ideas and concepts than we probably will be able to implement in the game, but still we will try to get as many as possible in it :)

ToDo for the next days:

Graphics:
- Intro-Graphics
- Putting together the Title Screen
- mysterious hidden extra-image

Code:
- Completing the Editor
- Including one remaining animation
- adding a small feature to the level loading code
- Setting up title-screen and incorporating functionality
- Scripting the Intro sequence

As small bonus to our today's daily status-report, we just briefly direct you to this completely mysterious and not very descriptive labeled link:

A completely mysterious and not very descriptive labeled link

Day 3 is coming to an End - 4 more are to come! =^..^=

Worked on the game all day today (eek! don't tell my supervisor!) and got heaps done.

Spent quite a while toying with different rules, including some lengthy debates with random people in the computer lab, and a bunch of first year game design students (whose helpful comments ranged from "It should have bunnies!" to "Make it pink!").

I've settled on a very simple blocking-style game. The "twist" factor makes it hard to plan a strategy, but after a few plays through it becomes more obvious. It's not the most original or challenging game in the world, but I'll stick with it modulo minor variations because it's working.

The minimax was a nightmare to write -- sure, it's a simple algorithm to understand, and it's only 10 or so lines of code -- but it's nigh impossible to debug. There's all kinds of tricksy corner cases they don't tell you about in AI class :-)

The evaluation function is still simplistic (it only looks at the winning condition, so it sucks at the beginning/middle of the game). I'll tackle this later.

The moves, both by player and AI are all animated now so it's clearer what's going on. You can set up the game to play with any combination of humans and AI bots.

Hi!

I know everyone is busy and all, but I really need to ask help for portability testing.

After writing the diary entry, I will (try to) upload a .zip-file containing the current test version of the game (mai0_0_1.zip). It would be really great if some people could test whether it runs. (especially Mac and Linux, since I myself am using Windows XP (although compatibility between Windows versions ...... (^_^;; ).

Unfortunately, I forgot to take some information home, so it is lacking from the readme.txt file.

wxPython can be found at the Download Page of http://www.wxpython.org

Their download and installation instructions should be sufficient to get things up and running.

This is still an extremely early stage of the game development, thus, there is not really much you can do, so the test (after installing wxPython (^_^;; ) will be over in a few seconds (and grow boring at that)

Basically, when you start the program, it should switch to full screen at 640x480 and display the main menu which offers 'New' and 'Quit'. If you choose 'New', you should see Mai-chan in a simple forest map (30 x 20, IIRC) and you can move her around. There is nothing to interact with yet, so that is all there is to it (you can't walk through trees, though).

If you can do all of the above, everything is fine. Otherwise, please try to get the error message with which things fell apart, and write a comment to this diary entry informing me about the problem. Then I can try to fix things. Thank you for your support.

Still, I think that this is already enough for me to avoid most portability problems later, since the program as is uses nearly all dangerous features the game will use:

* Reading data files
* Displaying graphics (including simple alpha-graphics (just 00 or ff))
* Accepting keyboard input
* Enforcing 640x480
* Various wxPython routines

This leaves only the following dangerous items unchecked:

* Text display (will be worked on tonight together with the event engine)
* Data writing (I think if I use the same addressing methods as with reading and then choose 'wb' for writing, things should go smoothly)
* Turning off the mouse display (mouse input is not supported and not wanted in the game; I think there is a method in wxPython to make the mouse invisible if it is in front of a window).

Those interested are welcome, of course, to read through the source code. Maybe (that's a big maybe) some of the ideas may inspire you. However, be warned that due to being behind schedule, the most recent code parts are effectively uncommented (if you are a masochist, try to understand the routines in mapmode.py).

Also note that there are quite a number of variables and functions that are not yet used in the game.

Sorry for being such a bother, but I never worked on a project with such portability issues (^_^;;

Deathworks

this is my first post on the site, my first pyweek and my first python project. My game is at a very early stage, but it is a 1D RTS (athough that fact is not really recognizable yet). I think that the project may be a little ambitious for a week, but im encouraged by good early progress. --scott

While we had two major successes again today, only one was technically our own work, so we only have one to show you.

Chris was busy in the morning and I slept all day, so we didn't get a whole lot done. I cleaned up the animation code and Chris worked on some new animation graphics and drew up our fire monster, Drakko. Hope to make some serious progress during the week though.

Hi!

By now I am a bit nervous, but I think it is still too soon to panic.

I figure if I want to have a chance to address portability issues, I need to have something running with most graphic and file routines by the end of this day so I have the whole of Wednesday to figure out how to fix things.

This being said, I have made some progress.

I have added a (hopefully) stable way for Active objects to request their replacement (the Active object handles each of the possible game modes, like gamemenu or map mode, taking care of graphics and input interpretation; it is an object created by the main window).

I wasted quite some time in its creation trying to use fake events in the existing event type, but in the end had to use a user-created type, heavily relying on the sample code that comes with the wxPython demo pack (^_^;;

Then I started implementing map mode. As expected, nothing really complicated, but simply a lot of stuff to write. A LOT.

I am still in the middle of it.

To make matters worse, last night, I wasn't able to fight off sleep. My last chance is tonight. If I sleep tonight, there is no way for me to make the deadline, I think.

At least, today I won't be wasting 6 hours waiting for a drawer at my parents' place, so I hope to make some progress today (^_^;;

(But as I said before, even if I don't make the deadline, I am determined to finish this game and release it).

Deathworks

Far away behind the horizon lies the archipelago of batwima. A collection of small beautiful islands floating around some twisting maelstrom(s). But not long ago an earthquake disturbed the eternal balance and now the islands are in danger to get sucked deep down beneath the water surface. Help the peaceful islanders to safe their homes and restore the balance of batwima.

Your islanders are scattered on several islands and your goal is to regather them. You can do this by spending some people to anchor an floating island, pull islands with ropes together and also release them. At last you can let your people wander from one island to another connected one.

Your only resource are your limited number of islanders, but beware of the scary tiger on flotsams ;)

I didn't get a whole lot done today, I'm sad to say. I did some minor polishing on the game, including:

• focus exception - when you switch to another window, I have code to trigger a pause menu. No actual pause menu exists, though (indeed, my hFSM code isn't in, yet), so it used to throw an exception that didn't make people happy. They should be relieved to know it's fixed.
• music - I'm no musician, but if you're going to turn the music off, there'd better be music there to turn off, right? So I made two short MP3 files, which I'll in turn process into OGG, and get playing ingame soon. There's a robot saying "tubes", which sounds a little like "noobs". Sorry about that. I'll get a better robot next time.
• transparent tubes - I think the balls are easier to see now.
• color distribution - balls are emitted based on a color distribution table. Eventually, each level will control its distribution.
• ball distribution - I take measures to keep balls from stacking up on each other at the top of the screen. You may still be able to glom them together through clever twisting. You're very smart.
• greener greens - The green ball should be more easily distinguished from the black ball. No progress on making color-blind-friendly assets. I have an idea of how to proceed; an alternate set of assets for the balls and the 'shipping labels' with colors+patterns to help disambiguate. I'll allow the player to toggle between these using a button (maybe 'C'), and mention this in the tutorial.
• brass rings - I probably mentioned this before, but it should be clearer where the player can click now, through the display of brass rings around the tubes.
• cheat button - press '1' to fake dropping a while ball into the leftmost crate. If you want to do such a thing.
• Py2EXE - I made a skellington-free copy of my game, which seemed to be the easiest way to get Py2EXE to work for me. I now have non-programmers testing out my game.

Ok, so now I'm ready totally for pyweek, but aargh! I have school. So lets just hope there isn't to much homework. :) Be back at 3:30 GMT