Since for me pyweek is all about learning, I intend to aim for what I've missed in previous pyweeks. That is, planning, balance and sounds. My primary goal will be finishing a game, of course. I'll probably also be around more at IRC than last time, and will be happy to playtest or discuss ideas with anyone.

I'm thinking of a twisted tree, but I haven't got my mind set on anything yet.

Need to go think now. Good luck, everyone. :)

I made my team, voted for themes... Just have to wait a bit and then I can start. Hopefully I'll have time to finish!

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.

Deathworks

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.

Deathworks

OK, again here, after pyweek3 and pyweek4. This is a smaller team than previous times, we are looking for new ways to work together.

Last Sunday we held our planning session at Leito's place, in Buenos Aires. We started brainstorming ideas for games that would fit some of the 5 themes.

From First planning session

First time in PyWeek. This is just a test. Greets for all you!

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.

Deathworks