Screen Messages

I’ve just finished the classes for printing messages onto the screen. It’s basically the same as the dialogue classes, but requiring fewer variables: the text is read in from a file given as the argument of the event type “message” and blitted to screen.

Coming back to the code after quite a while has made me realise how much I shouldve commented the first time around. I’m going to go through all the files and properly document them, drawing up a diagram of where all the classes and functions lead.

How I do things (part 1)

A brief tour of how I’m doing those gamey things, for you to compare with your own code, as inspiration for new code, or to mock cruelly.

Moving the Character: Within the mainloop, I write:

pygame.event.pump()
movekey = pygame.key.get_pressed()
if movekey[K_LEFT]:
self.char.move(“left”)
if movekey[K_RIGHT]:
self.char.move(“right”)
if movekey[K_UP]:
self.char.move(“up”)
if movekey[K_DOWN]:
self.char.move(“down”)

Now I needn’t use the strings which the following code uses with If loops; I could just pass the movekey on and subject that to If statements like here, but I didn’t when I wrote this, and just haven’t gotten around to changing it. So, within the Character class, we have:

def move(self, key):
xMove = 0
yMove = 0

if (key == “right”):
xMove = self.x_dist
if (key == “left”):
xMove = -self.x_dist
if (key == “up”):
yMove = -self.y_dist
if (key == “down”):
yMove = self.y_dist
self.rect.move_ip(xMove,yMove)
locxnow = self.loc.GetLocationx()
locynow = self.loc.GetLocationy()
locxnow = locxnow + xMove
locynow = locynow + yMove
self.loc.SetPosition(locxnow, locynow)
print self.loc.GetLocationx()
print self.loc.GetLocationy()

This means I have twice as many If statements than I need, and will definitely be changed soon during a mass cleanup. It’s just that so far, once something worked I just kept moving, rather than optimising. But as I approach an plateau (as I have now) it affords me coding time to go back and clean things up.

There’s a whole world out there

Another event type added: this one changed the map and curret list of active events. So it’d be used for going from a worldmap to a village, a village to a house etc.

No, wait, it doesn’t work. For some reason the map overwrites but the eventlist appends, so all of the previous map’s events are still active in the new one.

Ok. I’m sure there’s a rational explanation for this…

Reading in Events

Mmm, I love persistancy….ugh. But it has to be done; it’s just not good to have numbers and strings defined in your code, with lots of if statements. So I’ve set the list of events to read in my a file. So this isn’t persistancy as such, but at some point things will need to be written to file for the save games. Next I need to write a sub-routine which sets up the current environment by reading in the map and list of events. Something like:

ChangeWorld(map, events):

newevents = ReadFile(events)

newmap = ReadFile(map)

return newevents, newmap

I guess this would first be called by the initial menu screen, which sets the gameloop attributes map and eventlist, and then called again by the event class whenever the player changed location. It’ll have to be defined within the event class, in this case.

Grid Reference l3,3t

I’ve written a file reader class for the maps, so that, like the dialogue, map information is read in from an external file, put into mapobjects and stored in a map, which can then be looped over and drawn. The file simply contains the co-ordinates, image file and permeability of what is to be drawn.

Now I think I’ll start drawing things, make the text from the dialogue print somewhere other than the terminal, and we just have something whole, albeit embarrassingly small, given the number of hours I’ve put in.

What I’m Playing

I actually got this done late last night/this morning, but as I had to get up only a few hours later, I elected not to blog it. The dialogue classes have been integrated with the main loop and read in from a file, whose name is defined by an event, which is stored in a list of eventlists, which is compared to the current location of the character when they hit the action button (gasp). The dialogue prints what the NPC says, then your options which you chose with a keyboard entry, and so on. However, there are some bugs at present involved with returning to the main game loop, but I know how I’m going to fix that, which will also be how the conversation produces a gamekey (my initial idea on how the story progresses based on what you’ve done).

So dialogue.py consists of 3 classes: DialogueOption, ReadFile and Conversation. DialogueOption contains the out text of the NPC, your choices in response and the corresponding keys. ReadFile, well, reads the file, and for each occurance of “start” or whatever, has a new dialogueoption created from the following data, and fills it all into a conversation. Conversation has a list of all the dialogueoptions, plus a list of all the keys. So, you see the first line of NPC text, your options a, b, c. Then if you press b, the code looks for b’s key in the list of keys, and returns the corresponding DialogueOption and runs it. Repeat until fin. This way you can have an infinite number of options and an infinite number of exchanges, based on the speech that is simply written in a text file. It requires hardly more typing than the text to be printed on screen. That’s what I wanted.

I’m aware that this blog must be pretty dull for non-pygame users (and maybe even for them) what with the lack of images/story from the game. Alas, that is still in R&D in the dark corners of my mind, but I can talk about the games I’m playing to stoke the old creative fire.

So, currently, on the SNES: Chrono Trigger, on the GBA: FF6, DS:FF3, FF12, Animal Crossing (anyone wanna visit?) and on the Xbox360: Eternal Sonata and Oblivion. I’m planning to “acquire” the new FF4 and Tactics for the DS as well, if I can find the time. Can anyone suggest any other SNES or Xbox games to try? Or anything else? Oblivion isn’t the style I’m going for, but some friends of mine refused to sleep because of it, so I’m giving it a go.

Ok, just a little glimpse. The opening sequence is (will be?) part inspired by [voices of a distant star]…

Dialogue – so dull

I really need to figure some way of writing the in game conversations at a much faster rate than at present. I’ve just finished a conversation that has two backs and forths, and it took as much code to write the text and set it into the classes as the classes themselves. Not Good. Ideally I just want to write the text in a file with a key to indicate which text this answer should call. Python has the pickle module but that’s really more for persisting data than writing in a file and reading in. I have some idea about how to do this, but file I/O coding is such an annoyance. Pre-persisted data is so much nicer.

I’ve done this in C++ but not yet in Python; not sure I wanna get into it tonight. Maybe I’ll just warm Tessa up…

Conversation

So I think I’m about half way to writing a class to manage the on screen conversations in which the player gets to make decisions on what to say. It works fine with the in-code option selection, but they really shouldn’t be too far away from keyboard selection, I just haven’t written the class structure that will send that information to the conversation class yet. Of course, it prints in the terminal window rather than the game window, but I feel that shouldn’t be too difficult either. One thing that worries me is the amount of effort required to make up the SpeechOption and Conversation classes – more typing than the actual words being used. Unless I can see a way around this I predict many, many tedious hours ahead, once I finally know what my storyline is going to be.

On the point of actual game elements, I’ve just started to play “Eternal Sonata” on Tessa the Xbox360 (named after Teletha Testarossa from Full Metal Panic!) and I like the part free movement, part turn based battle system. This is the first Japanese RPG I’ve played on the new generation consoles, but I’m looking forward to researching the others. The battle system is maybe the most important part of the game that depends on coding – I think it’s really make or break

Classes

So far the python modules contain the following classes:

GameObject: has a unique id and contains a location class – everything that will be drawn should reference this

Location: has x and y co-ordinates for drawing on screen, a map id for the relevant map it belongs to

Attributes: list of rpg type things that each player character will have, and sub-routines to change them through levelling up, battles etc.

Character: contains location, attributes, sub-routines for drawing and moving around screen (and changing location) based on the Key inputs retrieved in the main game loop

EventList: a simple class that stores the type, location and arguments of all on screen events. will be stored in an array when read in from file. when the action button is pressed the main loop checks to see if the character is near one of these, and if so calls the event class passing the arguments.

Event: takes the arguments from the eventlist and calls internal functions based on them. these aren’t written yet but will include the calling of classes such as Battle, Conversation, ChangeMap

MapObject: this stores all the background images on the screen, their locations, image files and whether or not the character can move over them.

The way I’m doing it what gets drawn on the screen and the mechanics of the game are handled almost separately, so that you could play the game without the graphics running. I don’t know if that’s the right way to do things. At the moment I’m using free sprite sets so I can see that things are working properly, but when I get access to a scanner I intend to hand draw all the images and then go over them in Gimp. That gives me some time to think and practice how I want everything to look. I had intended to spend the first few months getting familiar with PyGame, and then start the game proper, I may as well carry on as I am. The mainloop certainly needs re-writing, but all the modules can be kept as they are, or with some additions.