I have trouble coming up with ideas that I like, and as such can't actually get any work done with the game as I get bored with it after a few days, and therefore I've never actually made an entire game. For this reason, I decided to come up with a gameplay idea I didn't really care about at all, but would still want to turn into a finished game, and that's when I came up with the idea of applying really bizarre and arbitrary programming constraints, thus making the act of coming up with a game that would work within these confines sort of a puzzle to solve. So, my first idea isn't too impossible sounding. Basically, I'm going to make Wizardry-esque, single-character dungeon-crawl RPG, with first person wireframe graphics, eight floors, random battles, and some simple puzzles. I'll be writing it in C. The constraint will be that unless absolutely necessary, I won't use any data types other than booleans, arrays of booleans, or structures comprised of nothing but booleans. The necessary exceptions would be string constants, for outputting text, whatever datatypes I'd need to get file IO working (there's no real way around this), and potentially -- and this is ONLY if I can't find any way to get away from it -- strings used to name various objects in the world (Monster names, item names, etc.). Additionally, if I use allegro or pdcurses or whatever for the wireframe graphics, there'll also be screen objects, but again, no real way around that. All of the internal processing and gameplay-related variables will be boolean. As I'm trying to learn LUA, I might include some lua scripts, but they'd be adhering to the same guidelines as the main program (Sort of. Lua doesn't have typing, if I remember correctly, so we'll see how this could be made to work).

Hahahaha. This reminds me of the programmer who was so sick of optimizing that he posted online for ideas on how to come up with the most inefficient sorting algorithm ever.

I think you have to do whatever you can to stay engaged, but I wonder if you're really addressing the core problem-- are you more interested in finishing a game, or are you more interested in interesting technical puzzles.

I don't think there should be any shame in improving yourself either way, but I wonder how much you'll learn about yourself and game development by taking such an elliptical path. Do you run the risk of ending up with a mess when you're done?

What about imposing artificial game design restraints instead? For instance, your wizardry game must be a side scroller with moveable walls and water tiles which respond to physics and simulate hydrology, or whatever. You still don't have to get married to the idea, but you also get to challenge yourself technically without creating a mess of code.

Methinks it would be more useful to put limitations on other aspects of the game. Especially if you've never finished a project before. Writing code with only booleans is just going to be painful, not inspiring.

Heres my suggestion for limiting yourself: Limit yourself to making a game that only takes about 30 minutes to play from start to finish. Limit yourself to simple sprites-on-a-background graphics, and less than 10 keys (or 8 + mouse) for input. That should be simple enough that you can actually complete it before you get totally bored with the project.

"are you more interested in finishing a game, or are you more interested in interesting technical puzzles."

Probably the latter.

"Do you run the risk of ending up with a mess when you're done?"

Yes, but this is entirely for my own amusement, really, and a project ending up as a big mess in the end didn't really deter Bethesda from publishing Daggerfall.

There's more to this than trying to teach myself to program in really obfuscated ways and just keeping myself amused, though. RPGs are sort of overblown in a lot of ways. Let's take HP. Your dude probably ends up with several hundred hitpoints by the end of the game. Why do you NEED that many? What you're really after is how close to dead he is.

In other words, you can have all of these fancy formulas for calculating how much damage your guy got, how much was deflected via armor, whatever -- but what we're really after is whether or not he's got a spear protruding from his leg.

A simple way of handling this might be to have have two booleans associated with any given body part -- let's say the leg, since I already brought that up -- and I could treat them like two bits, getting a binary value from 0 to 3, with 0 meaning the leg is fine, and 3 meaning the leg is somewhere else in the level at that moment. Except this is sort of cheating since I'm using booleans to represent integers and while I WILL let myself do that if absolutely necessary, I don't really want to. And this is a really uninteresting way of doing things, anyway.

A more interesting way of handling it: You have the body part structure, but you have boolean values representing particular states that legs is in:

bool injured;
bool bleeding;
bool impaled;
bool broken;
bool severed;

and these could mean different things. You can't really do anything about a severed leg. A broken leg could be splinted, and you can't move unless you do that. A bleeding leg could be bandaged, and you'll bleed out if it's not bandaged. Impaled is a more severe form of injured in this case, I guess. Two states could be watched at once -- bleeding and injured isn't so bad, but bleeding and impaled is gushing blood. You get the idea.

It sounds like you lose interest because you find a clear path. The same thing used to happen to me (although I think it took longer than a few days to lose interest). You're thirsty for challenge, you start something that you're not sure you can accomplish, you learn your way through the tight spots, then you eventually find the open road, and quit.

I think if you try a little harder to force yourself to give it a few days or weeks of thought before you dump your project in the trash, you'll eventually find renewed interest. Since I've started my current project, there have literally been months at a time that I've lost total interest. The best thing you can do is wait, and to seek out things that inspired you to make that game in the first place.

Quote:

Original post by MeshGearFox The constraint will be that unless absolutely necessary, I won't use any data types other than booleans, arrays of booleans, or structures comprised of nothing but booleans.

It's not much of a constraint; ints, floats, chars, pointers, and every other basic data type in existence are simply tightly packed arrays of booleans.

I suffered (and still do) from the exact same problem, until I just stopped looking at it as a "problem" and went along doing what I like. Nowadays, I don't have "projects" - I just fiddle with stuff I find interesting and challenging to program.

Naturally, I don't advise anyone who is even half-serious about this job to take this route. Just relaying personal experience.

I guess the good side is that you constantly improve, usually in several different languages and technologies as well, and that you end up with a lot of your own useful code which you can use anytime. But sticking to a project and just grinding it when necessary is a problem that you'll have to face sooner or later - and the later it is, the more difficult it will be to get in tune with the efficient "working habits" and get rid of the "fiddling habits".

Basic idea for a battle system hashed out. The following might be a bitter gibberish, so the basic idea is that the player and monsters have a finite number of body parts that can take a finite amount of damage, an attack either hits and does damage or misses and does not do damage, damage is an either-or scenario and not a numerical thing, obviously. The attackers goal is to try and increase their odds of getting a hit in, and the defenders goal is to try to decrease these odds. This is fairly passive so far.

I will ensue the gibberish now.

Attacking:

At the most basic level, an attack either hits or misses. If the player and enemy are unarmored and completely on even footing, this is essentially a coinflip – as opposed to a dice roll. Being an RPG, however, there are things you can do to improve your odds of landing a blow.

Player Character's Weapon-related Skills:

A player's skill level in a certain weapon skill class determines the number of attacks they can get in per round. There are two different ways of handling this: If the player is an expert with short, bladed weapons, he will get four attacks per round. One method of handling this allows the player to have blows connect up to four times per round. Another method allows only one attack per round, but essentially the player can keep attacking till they land a blow (or more precisely, land a blow that does damage).

The skill system still hasn't been fully developed. In its current incarnation, a spear would draw on skills relating to poled weapons and weapons with short blades.

Weapon Attributes:

A weapon's attributes also affect how likely you are to land a damaging blow. The pierce property, for instance, gives you an additional chance to ignore armor (more on this later).If a weapon has the accurate/balanced flag set, you get an additional attack opportunity during the first attack phase. Other weapon properties are dealt with in the damage phase.

Phases of Attack:

1 – Initial attack phase. Did any attacks connect?
2 – Victim's armor is checked. Does the victim have armor, and did it protect against the attack?
3 – Additional weapon properties are checked. Was the armor pierced or broken?
4 – Additional armor properties checked. Did the victim guard against a pierce anyway?
5 – Damage, if dealt, is calculated.
6 – Other side may attack.

How Damage and Health Work:

The player and monsters are comprised of body parts. Each body part can be healthy, injured, badly injured, punctured, or destroyed. The player's body parts are the head, torso, left leg, right leg, left arm, and right arm.

In normal instances, if a blow connects and does damage to a healthy body part, it is upgraded to injured status. If damaged again, the badly_injured flag is set and the injured flag is turned off. If it's attacked again at this point, a coin-flip occurs. If the result is 1, the part is destroyed. If 0, the injured flag is set again, so that both injured and badly_injured are set to 1. If the part is struck again at this stage, it will be destroyed.

Additionally, a body part may be punctured. This might have additional properties. So far, it's used to determine special damage states. One idea is that if a body part is punctured, a coin-flip is done each round to see if that part moves to a destroyed status.

On the player character, the head and torso are essential body parts. If either one is destroyed, the player immediately dies. If the head is punctured, the player dies. This also applies to enemies, although they'll have different critical parts.

Other destroyed parts can be restored with potions or scrolls, or by praying at shrines – again, you can only do this a limited number of times per level.

If the player is near death, they are in critical condition. Critical condition means that the next blow that connects and does damage will kill them. Critical condition is reached in several ways:

Every non-destroyed body part is badly injured or punctured.
Both of the legs have been destroyed.
Both of the arms have been destroyed.
For the enemy, if two body parts have been destroyed.

Weird situation: If the player were to lose an arm at the beginning of battle, but every other part was still heal, they'd need to get all of the remaining ones into a badly injured state before going critical. Since a badly injured body part can get destroyed easily, in the case of losing a body part early, you essentially get an extra hit before you die. This needs to be compensated for somehow.

Some special Critical Conditions can occur.

For the player, if one of a leg and one of an arm are destroyed, the next body part to get get destroyed will cause the player to die—not the next successful attack.
Torso puncture wounds might kill the player immediately. This is determined when they're done via coin-flip. If the torso is split up into an upper and lower torso, then the upper torso (chest) will become essential and this rule will be obsolete.

Damage Calculations:

If a blow connects, whether or not it does damage is based on whether or not armor is present (on you or the enemy). If a blow connects and armor is present, another coin-flip situation occurs to see if damage is incurred. If 1, the victim gets damaged in spite of their armor. If 0, the armor deflects it.

If a weapon has the pierce property on it, and the blow is deflected, the attacker gets an additional coin-flip. If 1, the attack succeeded in piercing the armor and damage is dealt. If 0, the blow is still deflected.

Special Attacks against Unarmored Parts:

A weapons attributes can cause special attacks to occur if they're used against an unarmored body part.

Piercing – If a weapon has the piercing attribute, if a blow connects and does damage, a coin-flip occurs. If 1, the punctured flag is set. If the part is already injured or worse, it is destroyed.
Heavy – If a blow connects and does damage, a coin-flip occurs. If 1, the badly damaged flag is set and another coin-flip occurs. If this is 1, the part is destroyed. If the part is already injured or worse, it is destroyed.