next »

[MeshGearFox]

I've been kicking this idea around for awhile, but never made it because I didn't know how to program. Then last week I entered a strange mood and now I have a bunch of stuff done, somehow.

The original idea was to make a game using nothing but bool variables, because that would be HILARIOUS. That doesn't really seem easy to do though because after awhile you'd pretty much be programming in binary but it did give me some cool ideas.

One of the things I dislike about RPGs is the overabundance of stats. They mostly break down into completely meaningless sets of numbers that grow at completely meaningless rates. And so, keeping this in mind and working with the idea about making a game using nothing but booleans, I came up with the core idea for the game: all stats in the game must be expressible in strictly is/is not or has/has not etc.. relationships.

For example, you don't have hitpoints. Hitpoints are numbers and are therefor not allowed. Instead, you are either "healthy" or "not healthy," and "alive" or "dead." These are determined by other states represented in binary terms. Unfortunately I don't have any particularly concrete gameplay mechanics for this yet. One idea involves having body body parts that can be destroyed for various effects.

Similarly, equipment chains are fairly shallow. There are only a few weapons, all of which do the same amount of damage -- they just differ in properties. Likewise, there aren't different kinds of armor, really. Going from the body part example, a body part is either armored or unarmored, and that's that.

In terms of combat, since any effective attack is equally effective as any other effective attack, the idea is to have combat and equipment based around not on doing more damage but on increasing your likelyhood of doing damage.

Anyway, right now I'm mostly working on the engine stuff. So far I have:
* Movement.
* Tiling.
* Loading object data and instancing objects from it.
* Event scripting.
* Text output.

Not really sure what other engine level stuff I need. I'm going to start building up interactions right now and go from there.

Language: C++, using SDL as a graphics API and Lua for scripting.

And here's some cute little monster sprites (I'll tone down the brightness sometime)



November 24, 2009

Event Handler

Reconfigured the event handler to store return values on a stack. I'll PROBABLY need that later.

Began integrating Lua. So far I have a hook function for Lua to add events via lua scripts. I need to rename the event code, maybe. Strictly speaking, the Lua functions are events. The things getting added to the eventQueue are more like actions. I don't think it really matters, though. I could just name the event identifiers with a prefix indicating what exactly they are.

Instancing System

I need to re-engineer the instancing system to work as such:
The GameObject class will now be referred to as an Instance class.
The Instance class contains the following members:
* Int iID; // The specific ID for the instance.
* Int iActive; // Whether or not the instance should update/draw.
* Int iDeletion; // Whether or not the instance needs to be deleted.
* Int drawOrder; // What “layer”/order the instance is drawn in.
* Int xpos, ypos; // The current position of the instance.
* Int lastx, lasty; // The previous position of the instance.
* GameData* instanceData; // The data associated with the instance.
The Instance class contains the following methods:
* Int ID(); // Return iID.
* Int active(); // Return iActive.
* Int deletion(); // Return iDeletion.
* Void coordinates(int&, int&); // Sets the Instance object's current coordinates to the args.
* Void moveback(); // Reset the Instance object to its last position.
* Void setpos(int, int); // Set the coordinates of the Instance object to the args.
* Int update(); // Calls instanceData's update method, which takes a pointer to the containing Instance.
* Int draw(); // Draws the Instance's sprite at its position. Does NOT call a method in instanceData.


Checklist (To-do):

• Major: Add code to allow new GameObjects to take a string indicating their scriptfile and a string indicating their “stat” file in their constructor.
• Major: Add a function that allows one object/function to execute a function from another object's script.
• Minor: Work on naming conventions, especially in regards to that agent/object distinction I wanted.
• Minor: Keep making event functions till I run into issues. I need to start defining interactions and things.

[s0]

The idea sounds hilarious, but is using only bool variables that much different from using stats? You're merely taking one number-based system and replace it with another.

Anway, this reminds me of my very first game written in BASIC when I was 13, using only if (and its associates), goto and print.  :D

[MeshGearFox]

Well, I'm not strictly using boolean values.

is using only bool variables that much different from using stats? You're merely taking one number-based system and replace it with another.

That's actually a major problem I'm trying to address. For instance, in the example I gave involving damagable body parts, you could say that a bodypart is just an ersatz hitpoint. NOT want I want. So I might alleviate this issue by flagging certain body parts as critical--that is, if they get hit it instantly kills whatever entity they belong to, be it the player or some enemy.

Alternatively I could make ANY hit an instakill, and then place more emphasis and fighting with items and avoiding direct combat.

[george]

I think certain body parts could be destroyed without an instakill though. Would be fun to lose hands, feet, eyes...?

[st33d]

I personally use obscene quantities of booleans, but shoved into a few integers:

http://www.somacon.com/p125.php

Sounds like a fun project, I wish it well.

[JMickle]

yeah this seems like a cool idea, i'm sure that even if you don't stick STRICTLY to your boolean plan, it'll still some out as a fun game

[HarrisonJK]

I had an idea very similar to this where the hero would only get traits, no stats.

For example by watching a wrestling match he could get WRESTLING FANATIC, which would make him slightly better at fighting.

By saving a puppy from a well, he could get BRAVE, which would help him fight ghosts, and to save the puppy you would have to be AGILE, learned by playing on the monkey-bars, or playing basketball. ARMED AND DANGEROUS comes from finding a weapon, and INJURED or DEAD comes from losing a fight.

There would be no random battles in this game, just a series of traits to acquire until you find one of the endings, which would consist of a poster like screen saying KING OF THE JUNGLE or ADVENTURER EXTRAORDINAIRE or whatever, depending on what ending you found.

I guess I'm saying I like your game.

[MeshGearFox]

Okay. Was on vacation for a few days, hence the lack of updates.

As far as gameplay goes, I decided that everything would be defined in terms of its behavior, instead of, like, stats. This is sort of a natural decision given that stats had already been gotten rid of because of the whole... boolean-ness of how game objects work. What this means is that every object has a set of state flags (not so much properties, per say, as these are all temporary characteristics that can freely change) and a script (currently in Lua) which defines its interactions.

From a programming standpoint I did some neat things with how map objects are handled. Basically I wrote an Instance class which isn't anything but an abstract interface for a seperate GameData class. The Instance stores a list of all events that afflict the current map object, as well as its position information. But all the behavioral stuff is defined in a separate GameData object. This is convenient for me since it means I can essentially change the GameData thing a lot without doing anything to the Instance class, which is pretty set in stone by this point.

Also did some work hashing out how the event system should work. That's not a huge rewrite. Mostly just a fleshing out.

I'm also going with the all hits are instakill idea, because I can do some interesting things with out. I haven't really fleshed out WHAT these interesting things are, yet, but... I will!

[droqen]

This sounds awesome. I love the concept and I hope it goes far.

Instakill on hit = This makes me think of Warhammer which I've never played, only heard about. On every attack made, will there be a %chance of survival versus instant death? Or will it simply be death if someone gets the jump on you?

Colour me interested either way.

[mcc]

Instakill on hit = This makes me think of Warhammer which I've never played, only heard about. On every attack made, will there be a %chance of survival versus instant death? Or will it simply be death if someone gets the jump on you?

Sounds a lot like Bokosuka Wars! But wouldn't the %chance of survival basically be like another stat, which you'd have to store in a non-bool variable?

[MeshGearFox]

"But wouldn't the %chance of survival basically be like another stat, which you'd have to store in a non-bool variable?"

Exactly. This is sort of tricky and I'm trying to think AROUND this issue because it's, er, tricky.

I have a major gripe with RPGs as a whole, and that's weapon obsolescence. Like, where every weapon essentially behaves the same way, just with slightly different stats and you basically buy new equipment every new town, anyway? Yeah, I don't like that.

So my idea is, instead, to have weapons with unique properties that guarantee you get the first hit in certain circumstances. Naprimer!

* Spear - Once per turn, if the player is wielding a spear and the enemy attacks first, the enemy is killed. What this means, in a practical sense, is that if you have a spear and can lure a mob of enemies into a narrow hallway, you can kill them by just letting them throw themselves at you. On the other hand, if they surround you, you pretty much die fast. This places an emphasis on positioning.

* Various single-use disposable phase guns - You can shoot things from a distance, once. You can't necessarily AIM them though. They shoot in one direction, or in a particular pattern. A few can be aimed. Some have special affects, like taming enemies.

* Halbred - Could be invoked to wipe out a row of enemies in front of you. However, doing so leaves you vulnerable for the rest of the turn.

Stuff like that. The only one really set in stone is the spear. I REALLY like the idea behind that.

Anyway, as far as progress goes, I rewrote the loader functions. They're a little cleaner now. The next task is to rewrite the eventHandler stuff which is sort of the main core of the program and probably can't be done till I have stuff designed, first. I'm planning on writing the Lua scripts as I'd like them to appear, then write the EventHandler stuff from them.

[droqen]

mcc: I was thinking more along the lines of a little formula that creates a % chance simply based on various bool variables. There would be no notion of such a thing in the weapons' stats themselves (so like a "heavy" armour variable would increase survival chance by 30%, unless the weapon has the "piercing" bool)

MGF:

That sounds awesome D:

This is sound a lot like a roguelike to me now, though.

Not the first impression I got from your first post, and although it doesn't sound bad, it doesn't sound much like it's going to be showing people how an RPG (in the sense you've been talking about) can be made with bools.


And a question, will the weapons also have a % chance to kill in regular circumstances -
in the sense that there's something like a 50% base chance modified by bool combinations?

[st33d]

Fun fact:

The pokemon trading card game resolves all need for dice with coin flips. Some attack damage for example being a result of multiple coin flips as opposed to damage dice.

I'm ashamed to know this and no I don't play that damned game anymore 

[shrimp]

This is a very interesting project - I had an idea (well, based on various discussions and existing games) for a trait-based RPG, similar to what has been proposed already in this thread. It might still come about, although I probably won't be a total purist. It seems to be a better emulation of fairy tales and legends - you don't have 18 strength vs 19 strength, you have "tough monster" versus "cunning thief".

Bit off topic, but regarding coin flips - Armageddon Empires effectively does this: Attacker has STR 6 so tosses 6 coins (ok, dice with 3 "winning" sides) and defender has STR 4 so tosses 4. If attacker gets more heads, they win. I'm intending to borrow this system in future as it has some nice properties. Each side always has some chance of winning, and the way the percentage chance changes as the stats change is rather nice. I might dig out my excel sheet if anyone's interested.

[Alex May]

You should do this for GAMMA 4 - make the input system Boolean as well.

[Seth]

I think this is a great idea.  I've actually been thinking about a stealth/ based roguelike based on these sorts of concepts.  Like, you would have a variety of weapons that served functional purposes rather than damage--for example a dagger is used to open bleeding wounds where a club is used to knock an enemy unconscious.  In the dungeon, every single enemy would be more powerful than you, so that it would be literally impossible for you win in a fair fight.  Dispatching enemies would be centered around "alert" states.  It'd be simple to kill a sleeping enemy, or one who is staring at the wall, for example.  Otherwise, you would have to use tactics to get enemies 'distracted' so they have trouble defending themselves.  For the lesser enemies it might be as simple as throwing sand in their eyes.  Others you might have to poison so that they enter a drunk-like state (or you could just get them drunk!).  I'm not sure how it would work for tougher enemies without it turning into "do x amount of things to them before you can kill them," because, then it's basically hitpoints with one extra step.

[MeshGearFox]

Did some thought experiments and figured out a simpler way to do the Event Handling stuff.

So I'm trying to figure out how to collision/LOS/locative stuff.

Right now I'm planning on having some "coordinator" classes. Ideally Instances only know about their state (and related data such as position, last position, events affected against them, and possibly the position they're moving too).

So, I want to offload all of the collision and LOS detection. For collision, I have a CollisionMap class which objects can register to to be considered for collision detection. Then, registered objects can update their position on the map and test to see if they're colliding with anything. Fairly simple and seems to work well.

I was thinking about trying to do something similar for LOS/FOV although I'm not sure that's the right idea or not. Basically every Instance registers to the FOV map and can update its position on it like with the collision map. Test uses some FOV calculation to see what's visible around a given object. If it's calculating off the player, it sets some flags to indicate which objects to draw and not to draw. If it's not calculating off the player, it triggers a InFOV event for every object in the Instances FOV and then it'll handle them via the lua scripts (where I'll need to do some AI stuff to make sure the Instances target the appropriate object instead of, say, going after a random piece of detritus when something is trying to kill them). (Additionally I should probably have the actual FOV checks done within lua so that I can, say, make floor tiles not check their FOV, although I'm sure it would be amusing to make a level where the floor tiles got up and started chasing the player).

[MeshGearFox]

So, fun with a major code rewrite! Basically I had to change how I was storing and loading objects, in addition to changing what said objects even were. The loading stuff seems to work, now (though I'm not entirely sure why, for various reasons). However in the process I broke the draw code and SDL crashes on exist now. Oh well.

[MeshGearFox]

TEN DAYS LATER.

Current engine.

http://www.mediafire.com/?zzzztztzwmr

I have:

* Scripting framework in place.
* Text output stuff (need to find a better way to handle some of it).
* Collision detection.
* Basically all the other stuff I had before, it's just on a better foundation now.

[Triplefox]

Cool stuff. How far do you plan to take the engine before you start on content/game features? I find that I have to work in cycles of "game" and "engine," and it becomes too easy to ignore "game" for too long and build up faulty assumptions.