NoAdmiral

Unfortunately for you, there are no clear-cut answers to your questions, as everyone has different preferences as to which language to use or which engine to make a game in.

Fortunately, someone has made this helpful guide to answer many of your questions.

 

If you still have questions after reading through that, I'm sure the community here would be glad to point you in the right direction, but you'll find that most of what people here will say is echoed in that guide.

I try to spend as little time in design-mode as possible.

 

That's not to say that I don't like design or engage in it, but I definitely focus on development, and I go through a ton of iterations of whatever game I'm making. I'd rather not spend too much time thinking about how to implement a mechanic or an idea that I ultimately can't find a good place for, and thus wind up crowbar-ing it into my design (which so rarely makes for a good gaming experience); and so I prototype almost constantly. As I figure out which mechanics work with each other and fit the overall feel of my game, I implement them.

 

I should note that I've learned not to get attached to any of my ideas--I've thus far tossed out (or put on-the-back-burner) more mechanics than I've implemented (and been satisfied with).

Instead of making new resources all the time and occasionally blowing up the one's you've already spent the time to put in, why not just give players motivation to abandon a given safe-hold?

 

Something like zombies learning that the player is holed up there (attracted by the light/smell/what-have-you) over time could encourage players to use safe-places as temporary havens, moving on and opening the space for other players more frequently.

Or, you could make supplies dwindle over time in the area that is secured, such that the players have to travel further to get food/ammo and are thus at risk (outside of the safe zone) for longer periods of time because they have to travel further.

 

I'm not sure if these ideas are in line with your game-play mechanics, but I think, as a player, holing up in a building doesn't sound like much fun for long periods of time. If there were benefits to hopping between safe-zones (securing one, then abandoning it in favor of another), I think I'd wind up not only seeing more of the game-world because I'd be on the move, but because I'd probably log-in more frequently.

 

That's just my two-cents, though; again, I really don't know your game's design, and I just want to throw out ideas in the hopes of helping.

I like the idea of multiple health bars, but I think they tend to make more practical sense in 3d games, where an arm or a leg can be easily targeted.

 

However, the three zone division seems like a good way to do this in 2d. One way to handle the leg-damage issue (just falling over and the like) is to have the character die when the legs are out of health, but have the legs only take damage from falling. That way there's no specific targeting issue (I don't know how the combat in your game is going to work, or whether or not the player will be able to aim). Likewise the body could function normally (like a single health bar), and the head could have some other form of damage, like having really high armor (or whatever you decide to use) but really low HP, such that you could take many little hits (no damage to the head at all), which is somewhat realistic, but one good blow would put the character down.

 

Anyway, that's what I thought of on the bart-ride home. Hope it gives you some ideas.

Kinda proved my point with your statement but *yawn* to exhausted argue the point.. Gnite ppk

 

I don't think this thread should be an argument.

It has grown into one, of a sort, but it shouldn't have.

 

Sinister, just reading the name of the thread, I would think you would support the idea that designers should not be idea-people, but rather a more involved and versatile tool  in the development process.

 

This thread started as a reasonable discussion about what it is to design versus develop a game, and the question of what is a designer's [practical] role. Early in this thread there is a lot of advice given (free-of-charge) for how to make your ideas tangible, to be able to present them to a development team and get them to want to code and mold and draw and render that idea of yours--but it involves more than just tossing out ideas, it involves getting your hands dirty and starting out all alone (or with friends) until you have something to convince that team that they want you as one of theirs.

 

Instead of being an argument, this thread should be a source of information, Ideas are a dime a dozen, so what? Concept sketches and diagrams of how a mechanic work (to show that this has really been thought out, and practiced) aren't. Prototypes are even better. You, the armchair-designer, as it were, probably can get a team to develop your idea, even if it's a group of hobbyists, but you have to show each member of that team that they want to want to spend their hours-in-a-day making that game, and it has to be something that the team as a whole can do in a reasonable amount of time. The bigger the project (and thus time-investment for each member of the team), the more work you need to put in to giving these artists and programmers a reason to pick your project over all of the other great projects out there. Concept sketches and diagrams of GUI and the like might be enough to present when working with a small project, but the moment you start introducing new and complicated ideas   you need to show prototypes of mechanics or design; really you want to be as precise as possible, and sometimes that precision only comes with an actual applet or mini-game (again, I think Jonathan Blow illustrates this nicely in this video).

SinisterPride:

I think, though, that the process of prototyping (or constructing a playable model of a mechanic) may not only give you something to show people who may be interested in being a part of the development team, but it could also change the way you look at your mechanic.

 

For example: Maybe you have an idea of exactly how your control scheme will work (as you laid out in one of your other threads), and it really might work very well, but when you explain it, without showing it, all I think of is QWOP, and I no longer want to have anything to do with the project.

 

I think a big part of why people seem to be resistant to the idea of a pure "Designer", is because everyone on the team is part of the design process. Maybe one of the graphics programmers develops a really cool shader or figures out a way to include some graphical flourish that was dismissed as being beyond scope before... that person just influenced the design. Maybe only aesthetically, but that's part of design. 

 

So, when someone comes along who doesn't want to show how a mechanic should behave or present a few concept sketches to get a feel for the aesthetic of the game, one really starts to wonder how integral their role in the development is. 

Out of curiosity, why would a player choose to play with the complicated controls when simpler controls are available?

 

To be honest, when I first read your post, I thought:"I don't want to play that game". Now, that was based solely on the complex control-scheme you've laid out, and while it might be that this game could be everything I've ever wanted in a game, that control scheme just sounds frustrating and reminds me of the few minutes of laughs followed by more minutes of tedium that were QWOP.

 

Anyway, I don't mean offense, but, like Dave said, this is something that NEEDS to be prototyped first; I think this explains why pretty well.

If you're just trying to replicate Final Fantasy style game-play, and don't care too much about programming the whole game, try RPGMaker. It's pretty good out of the box, but if you can script, it gets really powerful and versatile.

 

I'm not familiar with Python or PyGame myself, but I'd imagine you're more likely to find tutorials for languages such as C++, so you might have to do a little translation (which is good for learning), but I'm not sure where exactly to find these (I suggest searching the forums, as I'm pretty sure I've seen links to them recently).

I like the solution proposed to this question the last time it was asked: that a quest system be handled much like an inventory. When an NPC gives a character a quest, he/she literally gives the character the quest

While the character has the quest in his/her quest-inventory, he/she cannot be given that quest (to prevent a character running the same quest multiple times at once), and repeatable quests could have the character either drop the quest or give the quest back to the NPC (one idea thrown out was that the NPC had a limited inventory of quests, like one/character, so giving it back would allow him/her to give it back again when you wanted to repeat the quest).

I don't have any real advice for which engine to use, but as far as your game concept, I would check out Desperate Gods design philosophy. Instead of having all of the rules hard-coded, they pretty much just provide to rules and the tools, allowing users to modify the game (at least in concept) as they see fit. I think it's an interesting idea that might make what you're trying to do either a little easier (as far as coding rules) or more difficult (for designing the rules).

I don't think you have to work through that entire list, in fact, I think you can get started working on your big-project now. Just realize that what you're going to code at this point probably isn't going to make it into your finished product. I think it's easier to get burnt out on programming when you're making all these games you don't want to make (you have your own idea, right?), so I'd suggest jumping right in to the most simple aspects of your game.

Start with something like tile-based maps and player movement (you can start with text-based maps and such). Integrate a way to easily design cool maps (maybe something that loads from a text-file). Add the ability to move between maps. Convert it from using text graphics to sprites. You get the idea? Whenever you get stuck on an idea, go work on something quick that will help you figure it out.

In line with what others have said, try to avoid copying code from the internet or books unless you know what it's doing and why, and don't be afraid to brute-force something (your code doesn't need to be pretty yet), you can come back and re-factor it when you have a little more experience.

I'd suggest buying yourself a copy of C# Game Programming for Serious Game Creation. I see that you're using C++, but that book answers a lot of your questions (looking at your post history), including this one, and I think translating the code from C# (a very easy-to-read language) to C++ might be good practice for you. Alternatively you might find you like C#'s syntax to be more your speed, in which case, great.

Which language you use is entirely up to you. You seem like you're more comfortable with C++, so why do you want to switch?

I think this site has some pretty good tips on tile-based game development. You can get started on a text-version of your tiles now and "upgrade" to graphics later when you know how to do so.

Other people will probably be able to give you better ideas than I can for audio, AI, and graphics libraries (or tutorials), but it can't hurt to look at things like OpenGL or DirectX to see if that's the kind of programming you want to do.

Another entirely viable option is to use RPGMaker (not sure which version is the latest). It's pretty simple to play around with and make simple RPGs, but can also be expanded to do (as far as I can tell) anything you want through its scripting language.

Hope this helps.

I'm not entirely certain if this is what Lorenzo was suggesting, but if you have an array indicating where everything would be after their moves on a given turn, you could populate it by looping through all of your entities and assigning movements to them. Then, after they have all decided where to move, check which areas contain two or more entities (you wouldn't need to check every tile, only ones with at least one entity) and process their actions that way (if one is a prey and the other is a predator, just kill the prey; or, if both are predators, move one of them to an adjacent empty tile, etc.).

I think that would give you your desired effect.

You could check each direction and set a min/max velocity in that direction in the event of a collision.
In the event of a collision on the right side of the object, the velocity along the X axis would be set to zero if it was above zero (this would allow negative X values because they would move you away from the object with which you are colliding).