Can I get some help understanding new concepts?

Started by
6 comments, last by the_edd 12 years, 4 months ago
Hello!

I am finding myself struggling to understand new programming concepts. My language of choice is Python. Here is what I have accomplished so far and what I would like to do.

Goal/Current Progress

The main goal is to create a text-based RPG. I have downloaded the Qt SDK and the PySide bindings. In Qt I have created my GUI with the main portion of the screen set to display output while a single input line below accepts typed user input. So far I have been able to accept this user input, clearing out the line in the process when the return key is pressed, and display it to the main output area.

What I Need Help With

From talking with someone a while ago about GUI/OOP programming, he said it is best to have one file for each particular thing the program does. This means that the file I have that sets up and displays my GUI should be by itself and not have any game logic in it. The main idea here being that I could re-use this GUI without having to go through and remove all of the extra game code. What I don't understand very well is how I can "connect" these other files the game will have to run. I figure it's something to do with the "import" command, but I've never imported my own files before. So of course the idea I have is making a sort of "exit point" from the GUI file where the program takes what the user types and brings it over into a file that parses that text. That parsing file would figure out what it is the user is trying to do, and send control to another file to do that (like moving from room 1 to room 2, or opening a door, etc). I imagine there would be many individual files like this - parsing the input, moving between rooms, engaging in battle, etc. Also how would all of these external files be able to pass display information back to the GUI (room descriptions, NPC speech, battle dialogue, etc)?

I really do appreciate any help I can get with this. It's very frustrating, which causes even more frustration because without this understanding I unable to continue my project. I feel that once I can grasp these techniques I am missing I will be able to pretty much code anything I'd like to, and most importantly be able to finish this current project.
Advertisement
Python's a good language to go with. Have you read a tutorial or book? They will tell you about how modules work.

I know you want to jump straight in to working on a game, but a week or so's study in advance will ultimately help you move faster.

And don't worry too much about trying to tick all the acronym boxes. Experienced programmers get stuff wrong and have to rewrite or refactor code all the time.

The best way to learn (IMO) is to get stuck in, make mistakes, understand them and fix them for yourself.
While it's very nice to have your program properly structured (it makes maintenance easier, and it's more likely that you will be able to use the same code in other programs) it's much more satisfying to see gaming progress. Unless you plan the architecture of your game out in advance you may well start out with a program whose structure needs to be changed later anyway.

There's an operation we programmers do called "re-factoring" (after the arithmetic operation) that takes a working piece of software (i.e. one that passes all its tests) and changes the form -- the changes could involve making the code smaller, or making it run faster, or just making things easier to work with by re-structuring them so everything is more modular. The refactored program is then used as the basis for further development.

If you are still learning programming then two of the biggest favors you can do yourself are to a) write lots of tests (search for "test-driven development"), and b) regularly examine your program and refactor it (not all of it, just the grungiest bits). The first is necessary so you can be reasonably confident your refactoring doesn't unwittingly break anything. The second makes you more familiar with the code, and it's easier to amke he need for structural change as game play develops.

Also you should consider (though under no circumstances slavishly obey) the Zen of Python, which is printed when you import the "this" module. You can most conveniently do this from the command line with the command

python -m this

Personally I'd recommend that you gratify your impulse to see graphics on the screen before I worried too much about program structure. Progress of that kind is always very motivating. Good luck!
Thanks for both replies :)

@edd - I do have a great Python book, but the modules section (and the GUI section) don't really cover what I'm asking about. I'm also not finding myself able to shorten what I want to do down to an internet searchable query. What I am wishing I had was an experienced Python programmer (or any language would work I guess) that could kinda sit with me and go over things to help me understand these concepts.

@holdenweb - Indeed, I am aware of the awesome "import this", and at one point modified it to include one more line specifically for my friend: http://twitpic.com/yhega I think I see your intended focus: "Simple is better than complex". So, since I'm new to figuring out how to code with classes and GUI's and whatnot, perhaps I'll take your suggestion and just get something done now and worry about how to do it 'better' later. I'll either forget the GUI entirely and just have the game run in a console screen, or I'll just throw all my code inside of that main GUI file I have created.
It tends to be the case that open ended questions get broad answers that ultimately aren't really much help. So let's get specific. Pick one thing (for now) that's troubling you and we'll try to help you out with it. Give details (some code).
A quick suggestion, assuming I understood the question correctly: create a module that has one function in it: it takes a text string as parameter, and returns a text answer. This function now represents your entire game mechanic. (I assume text-only output is enough for now. If it isn't, you can always add other stuff later.)

This gives a nice, simple and clean separation of game logic from the GUI. You can now expand the game logic in this file, independently of how you might change your GUI code later.

There are other ways to structure it, but at some point you are going to end up either calling the mechanics from the GUI code, calling the GUI code from the mechanics, or having some third external layer that passes information between the two. (The latter is the MVC model and might be something to look into for the long run.)
Here's some code I think is sufficient to describe my situation (I pretty much am leaving out all of the code that simply defines how the GUI looks), and the error I'm getting.

gamewindow.py (the gui)

this is the code that takes the text the user types and sends it to a function to handle displaying the text
self.userInput.returnPressed.connect(self.write)

this function does two things. first it displays what the user entered onto the display, then it calls another function to further handle the input.
def write(self):
self.gameDisplay.append(self.userInput.text() + "\n")
self.handleInput(self.userInput.text())


this function is the 'exit point' i talked about in my first post, where control is handed over to a separate module that handles the text.
def handleInput(self, userText):
from commandparser import Parser
parse = Parser()
parse.command(userText)


and finally this function displays text to the user.
def displayOutput(self, msg):
self.gameDisplay.append(msg + "\n")


commandparser.py - the module i linked to with the import command above

from gamewindow import Ui_MainWindow

class Parser(Ui_MainWindow):

def command(self, cmd):
self.cmd = cmd

if self.cmd == "quit":
sys.exit()

msg = ("You typed '%s'" % self.cmd)
self.displayOutput(msg)


Now I am just completely guessing at the part here where I import the GUI class "Ui_MainWindow" and subclass it. I figured if I did that, I would have access to functions inside of it (the ones posted above). Unfortunately I encounter this error:

Traceback (most recent call last):
File "C:\Users\Antonymity\practice\gamewindow.py", line 79, in write
self.handleInput(self.userInput.text())
File "C:\Users\Antonymity\practice\gamewindow.py", line 85, in handleInput
parse.command(self.userText)
File "C:\Users\Antonymity\practice\commandparser.py", line 15, in command
self.displayOutput(msg)
File "C:\Users\Antonymity\practice\gamewindow.py", line 88, in displayOutput
self.gameDisplay.append(msg + "\n")
AttributeError: 'Parser' object has no attribute 'gameDisplay'


So it appears that I am incorrect in my guess that sublcassing Ui_MainWindow would give me access to its functions, so I am at a loss about how this parsing module can tell the GUI to display something to the user, let alone how any number of modules I write could do so. I don't think I would want to be including gamewindow.py into every file I write. So, this is pretty much where I'm at, unsure if I'm even anywhere near correct procedure for this kind of thing.


class Parser(Ui_MainWindow):

def command(self, cmd):
self.cmd = cmd

if self.cmd == "quit":
sys.exit()

msg = ("You typed '%s'" % self.cmd)
self.displayOutput(msg)


Now I am just completely guessing at the part here ...

I definitely think you fobbed off my suggestion at reading a book or tutorial too early. Prod and play with the example code and any exercises to cement your understanding.


... where I import the GUI class "Ui_MainWindow" and subclass it. I figured if I did that, I would have access to functions inside of it (the ones posted above).
[/quote]
You probably need a constructor (aka __init__ method) at the very least. See any Python book/tutorial.

As a side remark, if at all possible it's a really really good idea to strip your code down to the bare minimum that still illustrates your problem. This serves two purposes; first, it allows other people to run and understand it more easily. Your questions will receive a lot more answers this way. I'm still left with a rather vague idea of how your code is organized and connected, despite the effort you put in to a long response. The second reason is that in reducing your code, you will tend to spot the bug yourself. This happens surprisingly often (if anecdotal evidence is anything to go by, about 95% of the time).
Thank you edd, you've been a tremendous help.

This topic is closed to new replies.

Advertisement