Hi!

I have dared and registered for the challenge. Let's just hope, I will really be able to follow K.I.S.S. and come up with something I can finish :) :) :)

Anyhow, I don't have any friends for playtesting and I only have my own Windows XP machine to test things on.

Therefore, I would need some help with playtesting.

Would it be possible to use the upload here and then diaries to handle it?

To make matters worse, I am going to visit some relatives over the weekend around the 9th, so I will have to finish the game and everything by Thursday morning. So, playtesting would probably be possible only from Monday and Wednesday (if I can get something running by Monday :) :) :) ).

Hi!

As I mentioned in the other comment, I am currently brainstorming for the genre of my game.

After some consideration, card game doesn't sound that good anymore - needs a lot of graphics + a proper AI to be any fun. That's probably too much for one person in 4 days or so.

Now I am considering a stripped down RPG (engine). With hard-coded events and minimized graphics without animations, the workload should be just within reach.

But that gives me head-aches as well, since programming an RPG is my one big dream and has been so for a long time. In fact, several years ago, I had started programming an RPG in C++ with wxWindow (very outdated version even then) until library installation problems stopped me cold. Ever after, I looked into programming RPGs in different languages/engines. And now, being able to return to wxWindow (now called wxPython/wxWidget), I have started to work on the engine in Python again, and I really hope to get at least somewhere with it.

Currently, all I have programmed in Python thus far is only defining a few constants (like display size), loading a path name from a file in the main directory, and creating an empty application/frame under wxPython. No game code or anything has yet been implemented, so I don't think the existance of that project would be cheating (the C++ code is a different language and the library is outdated. In addition, it isn't even tested because the library failed me during game testing some modifications).

However, I am a bit worried that people may be suspicious of me because my PyWeek game would be similar/a simplified version of what I have already planned (but not programmed) as my one major endeavor.

Mmmmhhhh, especially since RPG is one of the things wxPython is best suited for (^_^;;

Hi!

One final(?) issue which has been bothering me for quite a while is the issue of licenses.

As far as I can tell, since I am only using wxPython and not including any of its code in my release (requiring people to install the library themselves), I am not really facing any license requirements or anything from that side (that is, I don't need to provide their license information or source, right?)

Similarly, using Python and its core libraries should also not have any effect on my freedom of licensing/copyright, right?

So, the problem is, what license agreement or copyright note should I include in the readme.txt of my release.

Oh, I have seen that page on licenses the link of which is given in the information here on the page - but frankly, forcing a license agreement I barely understand myself on the user seems risky at best (with my luck, I might inadvertedly violate that license agreement myself right from the beginning - I am thinking about all those weird source code clauses in GNU GPL, which frankly scare the xxx out of me).

Would something like this be good enough, or do I have one of the 'official' licenses?

Copyright and Terms of Use

This software is copyright 2007 by Deathworks.

By using this software, the user agrees to the following terms:

Liability
The software is provided as is and the user uses it at their own risk. The user accepts that Deathworks will not be held responsible for any damage caused directly or indirectly by the use of this software.

Redistribution
Deathworks grants any user the right to freely redistribute the unaltered and complete package of this software. The recipient of such a distribution will be considered a user of this software with all aplicable rights and limitations, as described in these Terms of Use

Derivative Works
The program code can be used completely or in parts to create new derivative works which may be distributed under any license the user likes, as long as that usage can not be used directly or indirectly to limit Deathworks' rights concerning the original work including his right to grant permission to redistribute and modify the original work. In addition, any derivative works must be clearly marked as being not identical with the original work and the creator has to mention the original work in the documentation and offer any user access to the original, unaltered work on request. That access may be by means of directly sending an unaltered package of the original work, or by providing a current, working link to a download of the original work.

Works Using this Software
Users may freely create works that are using this software (that is depending on it while not containing any parts of it) and distribute them under their preferred license, provided that such usage can not be used in any way to limit Deathworks' rights concerning the original work including his right to grant permission to redistribute and modify the original work.

The Graphics
All graphics included in this software may be redistributed freely under the following conditions:
* The graphics may not be changed, except for resizing and format converting.
* Credit must be given to Deathworks. A simple statement of 'This picture was created by Deathworks' or anything equivalent to it is sufficient.
* Any modifications to the personality of the characters shown in the pictures or any cases of linking other identities to the characters shown in the pictures need to be clearly marked as alterations, so that any audience will understand without fail that what they are presented is not the original design.

Hi!

Considering that this is a real time challenge and that some contestants, like me, have never done something like this, maybe providing links to portability FAQs would be useful.

Especially single person entrants are likely to have experience only with one platform, which may make them unaware of issues that other platforms may have.

For instance, the fact that the default Python build options automatically converts any new line definitions encountered in files to its own format can be found easily in the reference and would be something people are likely to search for.

But the fact that some systems are case sensitive concerning file names and others are not may not be obvious to people, depriving them of possibilities to minimize debugging necessities.

Thus, I think it would be helpful (actually not only for the contestants) if the help or rules included such links/information.

Hi!

This entry is just my rant about what considerations I have made about the game to be created. In accordance to the rules, I haven't done any coding, but I have considered some general aspects about the code.

I am now determined to make a small RPG. It does seem like the simplest thing for me to do.

So, I have been brainstorming abstractly what I may need.

Initially, I considered hard-coded events, but the more I think about it, it seems like a really stupid idea. I would only create a completely obscure monstrous source code that even I won't understand the next morning (^_^;;

Implementing a really proper and nice-looking event system is clearly not possible in such a short time (My calculations are - because I have internet only until Thursday afternoon - that Python programming must be finished by Tuesday morning at the latest, so I have one day to do content expansion). Besides obviously implementing only the minimum functions, I guess that using separate files to store text (like in message boxes) would be the best way to handle things since I don't need to work with dynamic length arguments in the file loader for the event proper.

After having determined that, I also figured that handling saves may be easiest using a similar method, splitting the data that needs to be saved into several files put into a common directory. So, I have to check what functions (preferably in the default library or wxPython (^_^;; ) can be used to handle directories (I remember seeing a function that can check whether a directory exists or not, and I think the FAQ over at python.org mentioned something about how to delete files).

It will be interesting to work with dictionaries and arrays (ah, I just checked the documentation, you call them lists here (^_^;; ) simultaneously. The way I see it, dictionaries are most efficient when dealing with index data provided as a string, which would be the default for anything read from a file, whilst arrays work best if I had numeric index data. So, during implementation, I am going to examine which kind of index data is more likely for each candidate and try to choose the type accordingly.

Originally, I considered allowing only exactly screen-sized maps, but I reconsidered, figuring that the benefit in terms of game fun of having things you find only by going to the edge of the map clearly outweight the potential trouble the few lines of extra-code that would require (I would need variable sized maps and would need to handle centering and being close to the map border; all of these should be easily implemented, but since they increase the amount of code, I consider them basically a liability).

I also spent a little thought on speed vs. memory concerning events, figuring that memory is more important.

The thing is, event files need to crunch the event data quite tightly, while interpretation is likely to benefit from cutting it into smaller pieces for easy handling and reference. The question I asked myself was whether I would want to have that cutting up into smaller pieces take place for all events when they are loaded (in effect when a new map is entered), or only for one event when it is accessed.

Converting all events upon entering a map would be time-efficient since conversion happens only once, but it would probably waste a lot of memory because each event would be cut into dozens if not hundreds of tiny strings (which are bound to have a bit of ID and processing stuff added by the system).

Converting only the current event clearly saves memory since only one converted event is kept in memory, but it means that conversion has to be done again and again, every time the event is triggered.

I figured that conversion is probably not so slow a task as to hinder gameplay, so I figured that preserving memory should have a higher priority.

Concerning the completely unintuitive handling of globals and locals in Python (yes, I do believe that giving spontaneous overriding priority over access is not an intuitive system), I guess the safest way is to access globals always using the __main__. terminology, even if they are on the right hand side. I find it simply odd that, when working within a given code block, I can address a global by (name) if it is on the right hand side, but need to write __main__.(name) if it is on the left hand side. Two different notations for the same variable seem to be unnecessarily confusing. Thus, I will always use the ugliest, but unfortunately only universal terming.

During the brain storming, I figured that I may want to do an HTML manual. This should be relatively portable (although I will not do any IE/Netscape/Whatever compatibility code or any Javascript at all (^_^;; ) and allow for giving detailed instructions in an easy-to-read fashion. If you are now raising concerns about the time, that is already considered: The last phase of the development (Wednesday to Thursday afternoon) is playtesting/debugging. This means that I am basically on standby, only modifying the program or its data in response to bug reports. More likely than not, that means that I have some periods of interactivity where I can't do anything. That time would be ideal for working on the instructions since they would have no impact on the bugs in the game and it needs to be written last anyway, since it should describe the features the program has, and not those I wanted it to have at the start of the programming.

Finally, I think it is a good idea to add a lots of comments. I figure that during programming and debugging, time is a luxury. And with the amount of programming/coding I will have to do on the first day, it is quite likely that I will forget many of the details I came up with during the process. So, by Tuesday, large parts of the code may be completely obscure even to myself if I don't comment them properly.

Besides, this competition is meant to help build a code base for Python. While I don't think that my code will be briliant or something, I do believe that people will be able to learn from it - but only if they understand what I am doing or trying to do.

In addition, library/engine images are a pet peeve of mine. It is frustrating me to no end that Kirikiri, which is basically C++ without the portability (to be implemented in the next release) and without the 300+ error messages if you don't tell the compiler your computer sucks at chess and you like the color green beforehand, is generally considered a dedicated digital novel engine. Kirikiri's standard functions offer all you need for many types of game and other applications, but its distribution includes KAG (Kirikiri Adventure Game system) which is a dedicated digital novel engine written in Kirikiri.

Similarly, I see people talking about PyGame all the time for game programming, but I think that wxPython may actually be easier for certain game genres to use (RPG being top because of the default joystick/pad availability, but also strategy (not RTS, though) and simulations). And as I mentioned elsewhere, wxPython also comes with really good and helpful installation instructions (not to mention a seemingly comprehensive and helpful demo, which needs to be downloaded separately, but which is really worth it.).

Mind you, I am not saying that PyGame is no good. It is simply that I believe that it is more suited for action and RTS types of games while things like wxPython may have advantages when trying to do other genres (actually, I find it really odd that Ren'py is based on PyGame (^_^;; ).

I think I will implement a few simple spells, so that levelling the character results in new options (and so that combat becomes less monotonous). But I will quite obviously not implement event spells (spells triggering special event code), instead sticking to simple healing and damaging spells and their kin.

At the moment, I think animation is most probably not to be implemented since it would increase the amount of artwork required too much. I realize that this is a painful decision because animated characters are something players expect of an RPG, but with these time constraints, it is just illusory (^_^;;.

I may use sound effects (not sure about that), but no music since I would be limited to WAV if I wanted things to be fully portable (wxPython has a command for playing general media, but that is not supported yet by Linux, I think). Besides, musics is not really my field, I am more with graphics :) :) :).

Well, these are all the considerations I have made thus far.

Hi!

This was really terrific. I knew I couldn't get the theme until 11.00 local time (9.00 Greenwich), so until now, I didn't know what the theme was.

I had planned to sleep long, so I am well-rested and work throughout the night Sunday-Monday - but no, I woke up far too early and couldn't get back to sleep - so my concentration is kind of less than it would need to be.

Anyhow, since 6.00 (4.00), I have started developing the basic routines - or at least I tried.

First painful discovery was that __main__ did not allow me access to the globals as I thought it would. The global command doesn't allow being macroed out, so Python offers you really no choice in this entire affair. (Geesh, so I have to be extra-careful not to have any accidental locals wreak havoc).

Well, with that out of the way, it was time for me to pay first tribute to sleepiness: Wrong kind of brackets used in dictionary definition and it took me ages to notice the mistake.

So, the first few hours were not that splendid. Well, I guess this only means that things will get better :)

Anyhow, my method for centralizing keyboard (and later pad input) while allowing for individualization seems to be working fine.

Now that I know the theme, the next thing should be making a simple main menu screen (after determining the name for the game) and completely implementing the main menu (it is kind of half done, even without displaying anything, because I used to to test keyboard input)

Then a small dummy tile set and off to map mode module coding (well, at least I have already prepared one of the globals needed to hold the map data, so that is taken care of)

And finally, I think my head is finally clearing up. So, I may have had a bad start, but I am not out of the race yet. :) :)

Hi!

After causing a bit of commotion with my programming style, I figured that sharing my source code thus far could help people understand how I approach my programming project and why I felt the way I felt about certain things.

However, currently, what source code I have programmed is not really enough to warrant an upload (I don't want to waste people's interest by making something as big and not delivering. Therefore, I will include the bits in this post (cutting out a few redundant comments, maybe).

So, if you don't want to see a Python newbie's awkward code for fear of getting confused, I suggest you don't read any further.

Since I didn't know the theme yet (starting about 6 hours before now without having internet access (^_^;; ), I solely concentrated on technical stuff, so there is no content at all yet.

Directory structure

Currently, with no readme.txt or so written, there is only one file in the root directory, namely main.py (okay, a very original name). In addition, the root directory currently has one subdirectory called code where all the rest of the code resides.

Currently, code contains application.py, constants.py, globals.py, mainmenu.py, and mainwindow.py.

main.py

(Header comment removed because layout crunched by HTML)

# This program was written for Python 2.5.1 in combination with
# wxPython 2.8.4.

# Initializing external libraries

try:
___ import sys
except:
___ print "Importing the standard library 'sys' has failed!\nPlease check the integrety of your Python installation."
___ raise

#
# try to import sys
#

try:
___ import math
except:
___ print "Importing the standard library 'math' has failed!\nPlease check the integrity of your Python installation."
___ raise

#
# try to import math
#

try:
___ a = sys.version_info
except:
___ print "You need version 2.5 or later of Python in order to run this program!"
___ raise

#
# fetch the version number of Python
#

if (a[0] == 2) and (a[1] < 5):
___ print "You need version 2.5 or later of Python in order to run this program!"
___ sys.exit()

#
# check whether Python is at least version 2.5
# Note: version_info was not available in 1.x versions of Python, which is why
# a[0] == 2 is sufficient.
#

try:
___ import wx
except:
___ print "Importing the wxPython libraries has failed!\nYou need to have the wxPython libraries (version 2.8.4 or later) installed in order to run this program."
___ raise

#
# try to import wx, which is the current method of importing the wxPython libraries
#
a = wx.version()

if (a[0] < '2') or ((a[0] == '2') and ((a[2] < '8') or ((a[2] == '8') and (a[2] < '4')))):
___ print "You need at least version 2.8.4 of the wxPython libraries in order to run this program!"
___ sys.exit()

#
# Check the version number of wxPython.
# Version 2.8.4 is required.
#


#
# Verifying top level
# -------------------
# This module is meant to be run by itself and will not execute as
# an imported library!

if (__name__ != "__main__"):
___ print "This module was not designed to be used as an imported module.\nPlease start it by itself!"
___ sys.exit()
#
# Abort program execution if this module isn't boss around here.
#

#
# Initializing original code
# --------------------------
# Note: In order to avoid conflicts with nested try ... except calls
# the following 'execfile' commands are not backed up by try except

execfile("code/constants.py")

#
# Initialize global constants
#

execfile("code/globals.py")

#
# Initialize global variables
#

execfile("code/mainmenu.py")

#
# Initialize the class for the main menu
#

execfile("code/mainwindow.py")

#
# Initialize the class for the main window
#

execfile("code/application.py")

#
# Initialize the application class
#

#
# Starting the Application
#
# ----------------------------
# Note: This 'module' is not meant to be imported at all. That is
# why I am not including the compatibility if statement.
DW_Application = DW_Class_Application(redirect = False)
DW_Application.MainLoop()

#
# What a big main program :)
# An instance of the my application class is created.
# Redirect = False causes error messages to go to Python's window.
# and then I start the standard main loop included in the basic application # class
#

constants.py

(Again comments shortened)
# Constants declaration
#
# This file initializes most of the 'constants' the game uses.
# Please note that these are not real constants, technically
# speaking and some may later be initialized from a data file.
# They are constants in the sense that they are not to be changed
# during the main program execution. Any changes to them are to be
# considered equivalent of restarting the program.
#
# Constants are marked by the 'Const' prefix in the name (right
# after the 'DW' prefix :) :) :) ).
#
# Screen and Display Constants

DW_Const_Screen_Width = 640
DW_Const_Screen_Height = 480

#
# Screen width and height; just as you would expect :)
# Used in application window initialization and various
# graphical calculations (probably (^_^;; )
#

#
# Map Mode and Tile Constants
#

DW_Const_Tile_Width = 32
DW_Const_Tile_Height = 32

#
# Tile width and height; again, quite obvious
# Used by routines handling map display, but also in combination
# with any display of items that are eligible for map display (e.g. character sprite)
#

DW_Const_Map_Display_Tile_Width = 15
DW_Const_Map_Display_Tile_Height = 13

#
# Height and width of the map display measured in tiles
# Used by map displaying routines
#

DW_Const_Map_Display_X_Margin = int(DW_Const_Map_Display_Tile_Width / 2)
DW_Const_Map_Display_Y_Margin = int(DW_Const_Map_Display_Tile_Height / 2)

#
# Derived constants used by the map displaying routines in many functions
# concerning map centering. Measured in tiles.
#

DW_Const_Max_Map_Width = 200
DW_Const_Max_Map_Height = 200

#
# Maximum size for any maps (measured in tiles).
# Needed by map loading routines to check for legitimate map size and #

#
# Miscellaneous Tool Constants
#

DW_Const_Hex_to_Dec = {"0" : 0, "1" : 1, "2" : 2, "3" : 3, "4" : 4,
______________________ "5" : 5, "6" : 6, "7" : 7, "8" : 8, "9" : 9,
______________________ "a" : 10, "b" : 11, "c" : 12, "d" : 13, "e" : 14,
______________________ "f" : 15, "A" : 10, "B" : 11, "C" : 12, "D" : 13,
______________________ "E" : 14, "F" : 15}
DW_Const_Dec_to_Hex = ["0", "1", "2", "3", "4", "5", "6", "7", "8", "9",
______________________ "a", "b", "c", "d", "e", "f"]

#
# These two constants are used if on the spot conversion from and to
# hexadecimal strings is needed.
# Note that Hex to Dec is designed to respond correctly to upper and lower
# case of 'a' to 'f'.
#

globals.py

(Header comment largely abbreviated, similar to constants)
# Globals declaration
#
# This file, which is also a top level initialization file, creates
# the global variables and sets them to default values.
# Global variables are variables that need to be accessed and
# often (but not always) changed by routines during the main program
# execution.
# Note: This file also contains certain option variables which would
# usually be changed via an option menu. Due to time constraints,
# the implementation of such a menu seems unlikely
#
# Globals are marked by the 'Global' prefix in the name (right
# after the 'DW' prefix, of course :) :) :) ).
#
# Map Variables
#

DW_Global_Basic_Map = []
x = 0
while (x < DW_Const_Max_Map_Width):
___ Helper = []
___ y = 0
___ while (y < DW_Const_Max_Map_Height):
_______ Helper.append("00")
_______ y = y + 1
___ DW_Global_Basic_Map.append(Helper)
___ x = x + 1

#
# The basic map data, provided as hex strings in a [x][y] array
#

#
# Options
#

DW_Global_Key_Delay = 500

#
# This global determines how many milliseconds input is being ignored
# after successful processing
#

mainmenu.py

(Comment abbrev. as usual) # Main Menu Class
#
# Currently, this will be used as a test file.
# Eventually, it will contain all routines relevant to the Main
# Menu of the game.
#
# Class definitions are marked by 'Class' following the 'DW' prefix.

class DW_Class_Main_Menu:
___ def __init__(self, DW_Window):
_______ self.DW_Parent = DW_Window
_______ self.DW_Current_Selection = 0
_______ self.DW_Max_Selection = 4
___ def DW_Up(self):
_______ if (self.DW_Current_Selection > 0):
___________ self.DW_Current_Selection = self.DW_Current_Selection - 1
_______ return True
___ def DW_Down(self):
_______ if (self.DW_Current_Selection < self.DW_Max_Selection):
___________ self.DW_Current_Selection = self.DW_Current_Selection + 1
_______ return True
___ def DW_Left(self):
_______ return False
___ def DW_Right(self):
_______ return False
___ def DW_Confirm(self):
_______ return False
___ def DW_Cancel(self):
_______ sys.exit()

mainwindow.py

(...)
# Main Window Class Definition
#
# This file contains the definition of the main window class which
# has only one instance which is created later within the single
# instance of the personalized Application class.
# Besides providing the basic output location, it links the input
# caught by the application to the routines in its children - well,
# actually, they just pass through, so this class is more like a
# container (^_^;;
#
# Class definitions are marked by 'Class' following the 'DW' prefix.

class DW_Class_Main_Window(wx.Frame):
___ def __init__(self): _______ wx.Frame.__init__(self, None, -1, "RPG")
_______ self.SetClientSizeWH(DW_Const_Screen_Width, DW_Const_Screen_Height)
_______ self.DW_Main_Panel = wx.Panel(self, -1)
_______ self.DW_Buffer = wx.MemoryDC()
_______ self.DW_Active = DW_Class_Main_Menu(self)
# self.Show()
_______ self.ShowFullScreen(True)

application.py

(...)
# Application Class Definition
#
# This file contains the definition of the application class for
# program. Programs (including this one) usually have only one
# instance of an application class.
# Besides being the container for the main window, the application
# will also be responsible for handling most input. Except for
# special cases like entry boxes, all input events will be
# here before being sent to the handling routines.
#
# Class definitions are marked by 'Class' following the 'DW' prefix.

class DW_Class_Application(wx.App):
___ def OnInit(self):
_______ """This routine effectively initializes the application."""
_______ self.DW_Main_Window = DW_Class_Main_Window()
# The main window is created
_______ self.SetTopWindow(self.DW_Main_Window)
# and explicitly defined as the top window
_______ self.Bind(wx.EVT_KEY_DOWN,self.OnKeyDown)
# Keyboard events are linked to the application's OnKeyDown event
_______ self.DW_Key_Lock = False # DW_Key_Lock states whether keyboard input is to be accepted.
# While it is true, no keyboard input will be handled by DW_Class_Application.
_______ return(True)

___ def DW_Unlock_Keys(self):
_______ self.DW_Key_Lock = False
# This tiny functions is called by a timer whenever there is a key lock
# The only thing it does is resetting DW_Key_Lock, thus lifting the key lock.

___ def OnKeyDown(self, DW_wx_event):
_______ """Handles mapped keyboard input for the application"""
_______ if (self.DW_Key_Lock):
___________ return
# If DW_Key_Lock is set, any input is ignored
_______ DW_Lock_Request = False
# The local variable DW_Lock_Request is used to store whether or not
# the input should be locked.
_______ DW_Code = DW_wx_event.GetKeyCode()
# The keycode is retrieved and
_______ if (DW_Code == wx.WXK_ESCAPE) or (DW_Code == wx.WXK_SPACE):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Cancel()
_______ elif (DW_Code == wx.WXK_LEFT) or (DW_Code == wx.WXK_NUMPAD4):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Left()
_______ elif (DW_Code == wx.WXK_RIGHT) or (DW_Code == wx.WXK_NUMPAD6):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Right()
_______ elif (DW_Code == wx.WXK_DOWN) or (DW_Code == wx.WXK_NUMPAD2):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Down()
_______ elif (DW_Code == wx.WXK_UP) or (DW_Code == wx.WXK_NUMPAD8):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Up()
_______ elif (DW_Code == wx.WXK_RETURN) or (DW_Code == wx.WXK_NUMPAD5):
___________ DW_Lock_Request = self.DW_Main_Window.DW_Active.DW_Confirm()
# ... compared to various cases resulting in calls to the appropriate
# subroutines within the DW_Active object in the main window.
# This way, keyboard mapping happens only once, namely here, while
# each phase of the application can have its own behavior based on the
# commands mapped.
# If the called function wants to lock the keyboard, it should return
# True, otherwise False
_______ if (DW_Lock_Request):
___________ self.DW_Key_Lock = True
___________ wx.CallLater(DW_Global_Key_Delay,self.DW_Unlock_Keys)
# Finally, should there be a lock request, the keys are locked (that is
# a flag is set to cause this method to abort prematurely and a timer
# is set to call an unlocking method after a specified amount of
# milliseconds has passed (that value is stored in the global variable
# DW_Global_Key_Delay.

End of Code

Well, this is how far I got that far. Not really big, I know, but I am still optimistic. And putting it up here has cleared my head a bit. And maybe now it has become clearer why I like execfile (^_^;;

Hi!

Yeah, even though I felt a bit better, yesterday I was simply too tired to get far. In addition, I also ran into what I now remember to have been an issue back when I first met wxWindows as well, namely wxClientDC. Somehow I can't get these beasts to work.

Fortunately, in the end I was able to get cooperation out of wxPaintDC and even found a solution where its placement in the parent-child hierarchy wouldn't pose a problem (basically, my design requires it to run as a child of the main window, but all the interaction (= drawing) is actually done by changing children of the main window).

And I even figured out how to force 640x480 screen resolution (although setting the frequency doesn't seem to work properly for me). Oh well, at least I have true full screen now.

I have looked at Skellington. I will definitely not use its run.py example, because it doesn't seem to really give me control over where a file is opened within the relative tree.
Instead, I am using something along the following lines:

try:
    DW_Const_Root_Dictionary = os.path.abspath(os.path.dirname(__file__))
except:
    DW_Const_Root_Directory = os.path.abspath(os.path.dirname(__name__))
DW_Const_Code_Directory = os.path.join(DW_Const_Root_Directory,"code")


execfile(os.path.join(DW_Const_Code_Directory,"constants.py"))

However, __name__ NameErrors also when I start things directly (^_^;; (everything worked fine when I pressed F5 while editing things in IDLE). I think, if I used "." instead of __name__, shouldn't that do the trick? I will have to test that once I get home.

Still, despite the various setbacks (and the fact that I am currently house-sitting over at my parents' place because they are expecting some furniture parts to be delivered this afternoon), I still believe I can make it.

With the main menu (at least graphically) working as planned, I have effectively tested all graphics related commands I need and keyboard controls are also working fine (while I will try to add pad control, in case of emergency, keyboard would be sufficient).

The next major task is mainly data management, data loading and data saving. The basic routines in Python are known to me, and my knowledge concerning them should be sufficient to handle things.

The only thing I am a bit worried about is whether to use 'b' mode or not. The manual says that the standard build of Python wouldn't require 'b' mode for text, handling any correctly and automatically converting them to Python's native format. Even if that wasn't the case, if readlines() was able to identify lines correctly, I should be fine for nearly all text data since I don't need to know what each line ends with (there is just one exception).

Otherwise, I hope that I can use walk in some way to fix things up (using it to read all files in normal mode and then write them back in b- mode or something like that).

Besides such portability questions (and the question if the MIT is completely sufficient a license and how to use it), the only difficult thing I will probably come across is putting text messages on the screen. There should be some wxPython classes and methods helping with that, but that may require some fine-tuning.
Well, I guess what Tuesday will be for :) :) :)

Ah, I wanted to share at least a screenshot of the main menu as it is now (graphics will be refined on Wednesday), but Pyweek wouldn't allow me to upload stuff from my parents' computer (could be their firewall; I tried doing things using Firefox and IE, but I always got an unclassified error and the program pointing out that the field 'file' (the one connected to the browse button) was required. Once I am back home, I will check whether things are as bad on the university computers.

Okay, the title of the game is not really subtle, but I think it is okay :) :) :)

Deathworks

Hi!

Putting aside the issue of the web upload being uncooperative, there was something else, I thought of.

Right now, if a screenshot is uploaded, a thumb nail is automatically shown in the Entry Listing.

Now, it would be really interesting to have the system also mark any entries with a small icon or something, which have something else uploaded, something that is not a screenshot.

The intent is to make it easier to find those entries that have already uploaded (preview) versions of their game.

Well, that is just an idea I had.

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).

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 (^_^;;

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.

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.

Hi!

This is just a random thought that came to mind after seeing the result of testing.

I am wondering how many people there are who do not have the target platform available for testing/judging?

The rules say: "All entries must run in Python on the latest available libraries"

In the case of my program (not a game yet (T_T), that would be

Python 2.5.1 (?)
wxPython 2.8.4

Theoretically, I wouldn't need to worry about anything less than the target platform, but hearing that people have problems running the software because of what may be old libraries can be quite disheartening.

So, I am wondering how many people there are who are unable for any reasons to install/use the most current versions of the libraries (I suppose, most of the newbies have the latest versions, so this probably applies only for the more experienced participants).

Hi!

Well, I am definitely too slow for this kind of thing.

Yesterday, another 6 hours were lost to visiting my parents (the reason I can't participate on Friday and Saturday is that I am joining them for a weekend trip - so we had to discuss some details), after which I was - again - unable to work during the night (damn, until a few weeks ago, I regularly couldn't sleep before 3:00 and actually could get things done until about 1:00, but now I get all sleepy at 22:00 (^_^;; ).

Still, with the few hours left to me, I will try to get a rudimentary event system running and try to design a few labyrinthine levels (twisted forest). I still want to provide something that can be called a game, as far as that it can entertain you for at least a few minutes.

Anyhow, regardless of how that works out, I can already say that this PyWeek was a great success for me. I have learned a lot about Python, and even more (in many ways) about wxPython. Talking with the people here has been fun.

Finally, my project for this PyWeek has quite unexpectedly turned into a real first step into the future. As I said before, originally, I had hoped to be able to recycle some of the code from my program to use in my big dream project. But now, looking at what I already have and how it works, the most reasonable thing to do is to actually make the big dream project an expansion/alteration of the current project.

Thus, my plans for the future are that, after returning from that ill-timed trip, I will start working on editors and expanding the engine of the game.

So, regardless of whether I will be able to finish a game for the deadline, I can honestly say that this PyWeek has paid off for me.

Hi!

(I know I should go home to do the final stretch of programming, but before that, allow me that last question)

How many people are planning to continue working on their projects after PyWeek? As I said before, I am planning to expand my project and turn it into the game I always dreamed of making. There are others who have great game concepts and who are forced to drop some features; for instance, I just read Hectigo's diary entry about his strategy game. I wouldn't be surprised if he continued working on it and making a deluxe version after the contest - it sure sounds as if it was worth it.

So, I wanted to know what participants think about their games - complete at the deadline of PyWeek or part of a continuing development? (Both views are equally good or bad, there is no 'good' or 'bad' answer to this, so please feel free to state your honest thoughts.)

Hi!

I gave it an honest try, but I simply didn't make it in time.

For those interested, I have uploaded the last version of the program I got together within the deadline in mai0_0_3.zip.

I had planned to reduce the RPG to a simply finding the path through the pre-set labyrinth thing, but a silent bug in the event system has thwarted even that (since I didn't get an error message, I wasn't able to find it in time).

Anyhow, I still think that some of the ideas that went into the code may be useful for others, so I would encourage people to have at least a quick look at it.

It has been fun participating in this and good luck to all!