Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Nadaka]

On a less controversial note, I'm finally starting to understand why my Python wasn't working!  Yay Apple for making it horribly confusing!  Now I need to relearn some syntax and start playing around with Pygame's features.

Apple has a habit of doing that. Making critical configuration options invisible and difficult to access. Ever tried to open the debug window in Safari an a mac? Muahahahahahahaaha! Its in the menu, only after activating it by an obscure code typed into the console, and you have to retype it every time you want to start safari.

[Bricks]

My extent of using Safari has been limited to downloading Firefox, so no, I've avoided that conundrum.  I like a number of Apple's products, but I'm not rabid about it, and I know when they've made some horrible design choices.  Hell, my MacBook is so personalized that I can't really even stand to use someone else's.

Spoiler: Game stuff that no one likely cares about. (click to show/hide)

I'm working through the logic of this whole weapon-creation thing.  It's tricky, because I don't want the player to have immediate access to everything, and I want the weapons to be crappy at first.  Right now, each weapon design has four characteristics: the effective range, the rate of fire (number of shots/turn), the ammo capacity, and the ammo itself (which ranges from darts to missiles to flamethrower fuel to lasers).  Originally I was planning to have five settings for each (not ammo, of course), but it's becoming difficult to fit some weapons into certain ammo capacities, and I don't like how definite the effective ranges are.  It might just be a slider for every option.  Once you have this weapon design, you can try to make it from whatever weapons you have on you.  Depending on how close the weapons you own are to the weapon you are trying to create, the new weapon will have a certain starting condition (like 10/40).  You can repair that weapon, Fallout 3-style, to bring it closer to the max condition.  The maximum condition, which I'm calling the quality, will be dependent on how much experience you have with that weapon design (or a weapon design like it, so you can make small lateral adjustments without enormous penalties).  The idea here is to encourage the player to choose a weapon style and stick with it - I didn't like how in Fallout 3, you were always better off specializing in Small Guns, since every other weapon type was basically unavailable until halfway into the game.  I also didn't like how that same skill governed revolvers, assault rifles, and sniper rifles, because it meant that player didn't have to make any gameplay-style trade-offs.

[eerr]

So the game is about weapons-mageagment?

A system somewhat resembling of fallout 3?

Sounds interesting so far. But what is the core?

[Bricks]

The core is OH GOD I HAVE NO IDEA WHAT I'M DOING.  Currently flailing about in python, trying to learn the I/O for pygame so I actually have something to look at once the real coding starts.  Anyway, I have no idea what you mean by core, but it's going to be a roguelike either in the traditional style or in Fallout 1/2's action-point style.  The latter probably makes more sense, but I foresee greater issues getting it to work.

Current progress:
-Made a function to check the keyboard events
-Closes when I hit the escape key
-Prints 'yay' when I hit return
-Learned a number of tricks about handling lists and dictionaries
-Found out that there is a better way to handle keyboard input, starting over
EDIT:
-Realize that what I was working on wasn't totally useless, finally got my keyboard input functions straightened out

I'll probably start working on a number of non-I/O elements to keep me from getting bored.  I need to start ripping things from Fallout 3 so I can make an algorithm that seems more or less fair for the weapons.  On the design-side of things, I need to figure out how I want armor to work.  The idea is to allow customization there, too, but since I'm avoiding any idea of magical stat bonuses (this lab coat provides +1 intelligence!), I'm not at all sure what the armor should do.  I'm leaning more on the mechanical super-soldier type armor side of things, since that would allow for more interesting armor mods, like enhanced speed, built-in power sources, or something.  It would also allow for there to be a heavy to light armor spectrum without making light armor seem horrendously pathetic.  I want everyone to be able to experience the coolness of power armor without being totally weighed down.

[Muz]

My choice is a combo of using Lua for the brains and Multimedia Fusion 2 for the boobs GUI. Lua is very easy to learn, quick to code, without having to deal with low-level processes. MMF2 is even easier to work with, but very bad with code.

Visual Basic, Java, and Flash seem to work fine and a lot of games use it.

These aren't the best long-term choices, but I'm assuming you want to make a game in a year, not 10 years, and that you don't have the mental stamina, discipline, and experience of legendary coders like Toady

I find C++ to be unwieldy for game design, though mostly use it for text-based games.

Also, don't underestimate the power of Excel spreadsheets when doing game design & balance. Back in my noob days, I'd try to do balance/powergaming in C++/Lua.. but turns out that Excel does the same thing in a third of the time.. and neatly too!

[Bricks]

Yeah, I'm actually in the... third or fourth revision of my anticipated weapon system and Excel/Google Docs equivalent is going to figure heavily into correlating my damage/accuracy/weight numbers with the stuff I adapt from Fallout 3.  I was reading about A* pathfinding last night and got the idea (a few hours ago) to use some sort of pathfinding method (in the fourth dimension) to find good weapon combos for a schematic randomizer.  That way, a player could mash 'go' a few times and get some reasonable designs to work on, or I could let the game try out the randomizer for generating random loot.  A long-term goal, but fun to think about.

Currently trying to wrap my head around classes (programming, not RPG).  I've done OO programing before, but generally I've been provided with relevant objects and didn't have to think too heavily about what went into each one.  I'm a little worried that making bad classes now will bite me in the ass when I try to rework them later, so I'm taking it slow (probably slower than I should).  Avoiding rewrites is probably a hopeless endeavor, especially in my first serious foray into Python.  I'm also not seeing an easy way to take a tileset image and translate that into the game's sprites (apart from cutting up the image myself, giving each one a different name, and assigning a number to each image).  Pygame has to have something to take apart sprites.  Found it.  I knew it couldn't be hard.  I foresee some issues if I want to change the font colors (some sort of limited palette DF-style would be best, although I wouldn't be against shifting the palette depending on location, time of day, or for special 'visors' like IR and night-vision).  That's not a big deal, though.

[TheDarkJay]

For objects just try to think of things logically.

For example, an inventory is ultimately just a list of items. It makes sense for all items to therefore inherit from a common parent, easier to store them and work with common properties like value and weight. A similar logic applies to characters and objects, with world positions, health and so-forth.

A good control scheme I've found is to maintain as little difference between NPCs and the PC as possible. What do I mean? I mean have it so that the only real difference is whether the keyboard or the AI is what bosses them around. Is it the AI that decides what weapon to draw, or is it the inventory menu? Does this difference affect the internal workings of the object at all? Should it?

Admittedly a system like this does take a little more effort to get going, but it's so much more flexible and convenient when you get to the meat of the code.

A good book is Game Coding Complete, which aside from containing interesting, amazing and often hilarious tales from the pixel mines, and wonderful insights into the world of professional programmers, also contains some very good theory and practical tips (such as this design pattern). Some of it is a little dated (it is like 6 years old by now), but all-in-all a great read, should be considered one of the bibles for aspiring game programmers.

[Bricks]

There are some obvious objects, yeah.  I'm a little confused about how I can do some sort of nested inheritance, since weapons and armor will have a lot of specific variables and something like a healing item will only have a few.  There's also (hopefully) going to be a notion of schematic that each weapon/armor should inherit once it is actually made (either by the player or the level generator).  The more abstract objects are the ones I am concerned about - should the map be an object?  Probably, as it will be its own graphical layer and have special associated functions.  Should each map tile be an object?  Maybe.  Handling things like walls vs. empty space will be easy, but entrances, exits, and doors will all need special code.  Menus can probably be handled as objects, too, and I'd like for them to be as general as possible.  Ultimately, I'm going to have to draw out some sort of map for the more important objects.

[TheDarkJay]

Giving each tile an "OnSteppedOn(entity& stepper)" event or similar could indeed be very useful, and walls and floor could be differentiated by a simple boolean, "bIsPassable", the question is whether or not it'll introduce needless overhead to your program.

[Shades]

the question is whether or not it'll introduce needless overhead to your program.

If it makes the code easier to read then do it and follow the principle of 'optimise later'. It's easy to get caught up and waste significant time trying for an amazing solution when you later realise you'd have saved practically nothing in the scheme of things.

(I do this all the time..  find it hard to practice what I preach )

[qwertyuiopas]

Something I thought of once was rather than a passable flag, have a collision type as a full int or so, and to see if something collides, use a binary and. That way, you can throw your spectral dagger through a wall to backstab a demon, since your "normal" mythical-metal-sword won't affect it, passing right through the demon harmlessly.

Also, if you wanted to add an AI barricade, you just use one of the unused flags.

The problem, is that you can't expect much more than 64 bits from a single unsigned long (long?), maybe only 32.

But still, that is at least 31 more than a simple "can collide"

(And imagine an enemy that could walk through solid rock, but not metal. And rock weapons would be naturally harmless to it)

[Bricks]

That's a level of sophistication greater than what I need, but it would be cool for a magic-based game.  Everything that blocks the player should also block enemies and bullets.  I think I can handle this well using pygame's sprite groups (sprites are basically image containers with built-in movement and update routines, and groups are ways of categorizing sprites for simultaneous processing).  Plus, I can make sprites belong to multiple groups, so an enemy, a wall, and an item could be in the same group for drawing to the screen, but only the enemy and the wall would be in the group for collision detection.  Right now I'm playing around with drawing methods and seeing which ones are going to work best, since pygame has a lot of features I don't think I'll need to touch.

EDIT:
Someone check my logic on this one.  If I make a general "item" object, I could make a "weapon" object that inherits all of the methods of the "item" object, and then I could make a "weapon design" object to handle weapon schematics.  Then, the "weapon" object could contain a "weapon design" object that it would know to access to look up all its properties, and it would make linking a schematic to an actual weapon a matter of simply passing the "weapon design" to the appropriate creation code for a given "weapon."  Sound sane?  I think I just keep getting confused between object definitions and instances of objects.

EDIT2:
Ampersand now moving around screen.  Yay?  It all needs to be rewritten anyway.  I'm a little concerned that pygame's Sprite class doesn't allow for easy persistence.  I never liked the roguelikes that suddenly reinitialize everything about a level just because I stepped in and out a door.  Eventually I'll want to clear that info from memory, but it should stick around for a while.  Also, sprites seem like a potentially bad way to handle items, since they can either be in an inventory, worn, or dropped on the ground.  It might not be too difficult to switch from worn->inventory->on ground types of items, but I foresee an assload of bugs.  A more consistent method would make giving enemies inventories a smaller hurdle.

[eerr]

For the love of god, do not make a stiff object tree.

[Bricks]

For the love of god, do not make a stiff object tree.

I don't really want to, as I don't intend to think that much about it.  But if I can make things run smoother, and if the inheritance is straightforward, I'm OK with it.  Either way, lots of revisions are going to happen.