To RPG or not RPG
Deathworks on 2007/08/29 07:51
of Deathworks
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 (^_^;;
Deathworks(log in to comment)
Comments
Deathworks on
2007/08/29 17:12:
Hi!
Thank you for the advice.
Actually, even my big dream, which is of course not meant to be finished in that week (^_^;; , would be more or less like the Super-Famicon games (Dragon Quest, RPG Tukuru) with simple 2D fields (in the big version with simple animated tiles for torches or water) and separate fighting screens for encounters (you know, the ones where you see a picture of the enemy/enemies in front of you and first have the option to fight or run, and if you fight you get the option to attack, block, use an item or a spell for each member of your party. Fighting would not be real time, but turn by turn, the classic way). In the big version, there would be, of course, complex interaction events where you have multiple choice dialogues and so on, but that won't do for a week project :) :) :) (actually, back then I had movement on maps bigger than the screen and a good portion of the event system, with events loaded from files and interpreted by the program, already done in C++ when I encountered that accursed library issue.)
AI was definitely a reason why I reconsidered about the card game - if a card game is to be any fun, you should see some pattern/strategy behind the computer, but not so much as to be able to completely predict its play - and such an AI is way beyond my current skills in any programming language (^_^;;
I know how much graphics can drag things out, I could show a few unfinished sheets for animated sprites for different 2D RPGs to underscore that point (T_T). This is why I say that I definitely won't do any fancy graphics or animations for the week project.
(If only I wasn't so proud; there is tons of free graphics, sounds and musics available for J-RPG, RPG Tukuru, Like A Quest Hyper, so if I simply supported their sprite sheet layout, I would be off the hook... (T_T) )
Although it has been some years since I last encountered it, and I have forgotten most details about that encounter, I am pretty sure that wxPython is just the right library to do 2D RPGs (if you don't need MIDI music for Linux or can live with WAV music - for the time being, I will simply keep things quiet :) :) ).
Because of my interest in the big project, I have already checked that all the routines I would need for a 2D RPG are offered by wxPython:
Defining Screen size
Putting Graphics on screen (with options to put only parts of them there
Keyboard and Joypad input (the only way to play a graphical 2D RPG is with a Joypad :) :) :) )
File access routines provided by Python itself seem also sufficient and there seems to be a random number generator in the core libraries, so that last tidbit is also taken care of.
Of course, Python has a few rather unusual data types (dictionaries!?), but I think I can manage with that.
Therefore, I think, provided I can restrain myself to the real minimum for a fun game and stick to simple graphics, an light-weight RPG may be feasible within that time.
Anyhow, sorry about the ranting. I am honestly thankful for your advice and I wish you good luck as well. Let's do all our best to get some fun entries together.
Deathworks
RB[0] on
2007/08/29 18:16:
Also note: a lot of ppl don't have joypads, and it would be nice if you used mouse, or at least supported it, maybe an options.cfg file or options screen
Deathworks on
2007/08/29 18:24:
Hi!
But everyone has a keyboard. And a mouse is simply NG for 2D RPGs, so I go for both pad and keyboard allowed as the player likes.
Deathworks
Neppord on
2007/08/29 22:47:
If you have played a round in other languages you must have sen similar data structures to Dict Hash-maps in Java for instance. I don't know what data structure that lyes behind the Dict object in Python( that is the nice ting, don't see what you don't need), it could be a tree or hash-map or just mapped lists.
richard on
2007/08/30 02:47:
Really, there's even two implementations under the covers: one that's purely used for string-only keys and then another that's swapped in if you use a non-string key. It's really quite cool if you're up to looking at some C code :)
Deathworks on
2007/08/30 09:27:
Hi
Actually, I have already decided that dictionaries are good for implementing file tables and the like.
Usually, I would use an array of strings to do that. So, I would need an index number to find a string and then would need to check if that string was actually not empty. To complicate matters for the big version, the soft-coded events would use strings themselves, so the number would need to be converted from string to numeric format.
With a dictionary, I can simply use strings instead of the numerics (the table data are also retrieved from a data file, so they start out as strings anyway!) and checking whether an entry exists can be done easily by using 'try' ... 'exception' (attempts to access non-existant entries would be an unrecoverable bug anyway). I think that would make the designing of the routines a good bit easier.
Actually, more than languages, I had contact with engines, like Kirikiri (I like that a lot, if it wasn't for the horribly limited file access capabilities - ah, it is Windows only, although they are currently developing a new, multi-platform version).
Deathworks
Tigga on
2007/08/30 17:44:
richard on
2007/08/31 00:18:
If it's more likely that the key is in the dictionary than not, then the try/except approach might be appropriate as it will be a little faster. This is only important if you're doing a lot of these kinds of lookups, of course :)
Deathworks on
2007/08/31 09:01:
Hi!
Well, the lists I was referring to should actually contain any requested element. Basically, the (big) program would load several lists/dictionaries with a hexadecimal string of a fixed length for a key and file names for values. During game play, mainly the event interpreter would come across hexadecimal strings given as arguments and will use the lists to find out which file it is supposed to load.
Therefore, if a key is requested that does not exist, this is an unrecoverable bug in the event or list data, which should hopefully never occur.
Judging from Richard's reply, try...except seems alright, so I think I will stick to that. Especially since it feels very much like error handling.
Deathworks
Cthulhu32 on
2007/08/29 14:25:
Well here are a few tips that I've collected during the PyWeek phases about game styles and what to create when you are working solo.1. You never have enough time to do a "BIG" project by yourself, this includes making an entire engine in little under a week.
Past winners of PyWeek have usually had help from other libraries like physics libraries or PhilHassey's excellent PGU library. Take a look at the solo entries, and generally the best games you play are the ones that either create your obstacles/goals randomly, or do not have a whooole lot to them.
2. Graphics will absolutely eat your time. Big projects such as RPG's require A LOT of graphics.
Some of my favorite entries have very minimal graphics such as TSMaster's delivery game with the planets & packages. A card game would also eat a ridiculous amount of time, and all your graphics would probably be lower than you wanted them to be.
If you are really set on an RPG, my biggest suggestion is to research small RPGs that use time to their advantage. For example, take a look at Rogue & Rogue style RPGs. Basically each step you take, all enemies are updated. When you fight, they react. That way your AI does not have be any more complex than a cause-effect system.
I would personally try to go for a simplified Final Fantasy style engine if you are going to create one from scratch. You have movement, interaction with objects/people, and certain tiles that will have randomly occurring battles. All of those would not be too hard to implement, as long as the game was SMALL and there were not complex AI routines.
Good luck!!