Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Brigand

Pages: [1] 2 3 ... 7
Design / Supported movement keys?
« on: November 01, 2016, 03:14:16 PM »
Currently my controls are set up to allow movement via the mouse, cursor keys, numpad....and QWEASDZXC square.

Imho, the numpad is ideal, but I realize people may play on a laptop without a numpad. The cursor keys are always present, but don't provide easy diagonal movement without a modifying keypress. My mouse implementation allows players to move to a designated position stepwise or continuously...but you are required to move your hand off the keyboard to the mouse.

Given the above, there really seems to be no ideal, always present option for movement. Therefore I have included the QWEASDZXC square as I mentioned, but this robs me of 9 keys (27 with modifiers) I could use for other functions.

So my question is, given this isn't a FPS, is the inclusion of the left-hand movement block a must, just a nice extra, or something no one would ever use? Would removal of this feature be enough to turn people away from playing a game?

I am considering user-defined keys, but that's a low priority...I can't see a realistic need to allow the player to remap the 'inventory' key, for example, although I do allow skills (and maybe direct access items) to user defined hotkeys.

Design / minimum resolution these day?
« on: August 16, 2016, 03:27:23 PM »
So I have essentially completed a new roguelike engine which has the ability to set to any resolution you want - even something really weird like 2000 tall by 800 wide or some other strange BS - and it will render and respond to mouse click correctly regardless of what you set. And while I don't want to set an upper limit on this resolution (although maybe I should?), I DO want to set a lower limit to avoid things like unreadable fonts/clipped text/etc. This is because I don't want to just stretch sprites and text - if a player has a lot of screen real estate why not let them see more of the map, as long as the game plays the same on every resolution? Higher resolution = more map seen. Offscreen enemies that are in sight range are handled a little like TOME does, with a minimap, and jumping the visiual area to the target area when using a skill.

Right now I have a lower limit of 800x600; 15 years ago people had monitors that were 640x480... but does anyone realistically play on monitors this small anymore?

I'm curious if anyone has an opinion on the minimum supported resolution a roguelike game should support? It will definitely inform some immediate design decision in my engine, and I don't want to exclude a sizable percentage of players because of an arbitrary limit that I picked out of a hat.

Design / Re: Damage reduction algorithm - looking for advice
« on: October 08, 2014, 02:10:49 PM »
These are some great ideas - thank you guys. I have ended up settling on something pretty simple:

damage reduction = armor / (armor + modifier)

where the modifier is just an arbitrary number which produces results that work well for the armor levels in question - the bigger the number, the less effect each point of armor has. This is a slightly modified version of what Bear was talking about. It provides a bounded number from 0 to 1 (simple ratio), and lets me explicitly adjust the effect of each point of armor. Why I just didn't consider this from the start, I have no idea, considering I was headed down a much more complicated path using logs and parabolas adjusted to an arbitrary range.

I am considering combining this formula with what Paul Jeffries was talking about as far as discrete armor slots being hit, but if I do, I will need to consider what the effect on the game is if your hand gets hit, as opposed to an arm or leg. This would require a good bit of refactoring, and a lot of thought before I implement it.

I may also modify this damage reduction to not be guaranteed, but a random value bounded by the calculated damage reduction - again, play testing will bear out any good ideas.

Bottom line, thanks everyone - very constructive responses.

Design / Re: Damage reduction algorithm - looking for advice
« on: October 01, 2014, 10:31:52 PM »
Sure.  Start the user with something like a damage resistance of 5, just standing there naked.  That means whatever damage he gets, divide it by 5 before applying it.   Then just add to the damage divisor per armor class.  If he has 5 armor, he's taking half the damage he otherwise would.  If he has 10 armor, he's taking a third of the damage he otherwise would.  If he has 15 armor, he's taking a quarter of the damage he normally would.  And so on.  If you wanna be nice, you can add a rule that the same number (or half of it) is also subtracted from whatever damage remains, meaning that a well armored character is actually immune to weak attacks. 

Divisors are reasonably self-scaling.  Each point of armor with this system is then worth less than the previous one.

Oooooh, I like that, thank you. That's worth some play testing.

Design / Re: Damage reduction algorithm - looking for advice
« on: October 01, 2014, 08:30:53 PM »
I have not looked at Crawl's implementation - I will download their source tonight and take a look, but do you know in broad terms how they do it?

Design / Damage reduction algorithm - looking for advice
« on: October 01, 2014, 07:41:00 PM »
In a nutshell, I am looking for a way to have unbounded integer values representing armor mean something without having damage get ridiculously high for attackers simply for them to actually damage the player - any advice?

More detailed description: My game has a value representing armor as an integer. There are around 6 armor slot and a potential shield, so the absolute lowest value a player can have with a full set of the worst armor is 7. As armor quality improves, this value gets higher...and higher...and higher. I can reduce it somewhat by saying a "better" piece of armor has other positive values, such as lower weight or lower evasion penalty, but these are marginal improvements. Ultimately, unless I have just 3 classes of armor (for example), I end up with armor values 30, 40,...etc....

(Just a note: armor in my game is purely damage reduction - there is a separate evade stat that is negatively impacted by armor, but only affects a hit landing, not how much damage it does.)

Well, you say, just make higher level creatures do more damage increasing at a rate somewhat relative to the expected armor at said level. This is fine...IF you are wearing lots of armor. If I increase damage to give creatures a chance to do damage to a heavily armored character (I don't want the player to be 100% invulnerable), then this makes low-armor characters die ridiculously easy.

I have tried several approaches, but none are satisfactory:

1) Armor reduces damage by its flat value, or a percentage of its value (still results in a linear growth in damage to keep up with increasing armor).

2) Armor reduces damage by a relative percentage (damage is reduced by something like damage/armor, which obviously is a problem with damage > armor, resulting in multiple case-specific damage calculations...ugh).

3) The CURRENT choice is a hybrid - armor reduces damage on a 1 to 1 basis, up to half of the incoming damage. I have toyed with it reducing the remaining damage by a random amount up to total armor.

4) I supposed I could change armor value to a single precision number, but it's still a linear growth progression, and ugly in terms of player presentation (Of course I can present it as other than a fractional number, but the point still stands about linear growth.)

5) A poly function might work for damage reduction, but what kind? Parabolic or logarithmic seems the natural fit, as the value of armor decreases the more you have, but where to place the limits?

Playtesting has shown none of these approaches to be exactly what I want.

Does anyone have a suggestion for such a problem? I only have 2 requirements 1) I don't want an arbitrary armor limit imposed, because it limits the differentiation of armor pieces (or at least makes the differences almost superficial.) 2) I don't want to simply increase damage to create a creature capable of hitting a high armor character,  due to the existence of low armor characters, and their resulting 1 hit deaths.

Any advice from anyone who has balanced a roguelike around a similar idea?

Early Dev / Re: Captive
« on: October 01, 2014, 02:19:18 PM »
Pretty cool, the graphics are quite nice. Just got destroyed by a yak looking thing. Looking forward to seeing how this turns out.

Wow, first time I've seen this - the traps are really cool - is it in real-time?

Trying to download but the executable link appears to be broken.

Other Announcements / Re: Roguelike Radio podcast
« on: September 23, 2014, 12:31:43 AM »
Yeah, that exactly how far back I can see. Maybe Apple has instituted a limit on number of podcasts in the feed, or how long they are retained - this doesn't appear to be the only podacst cut off after going so far back.

Other Announcements / Re: Roguelike Radio podcast
« on: September 22, 2014, 09:18:49 PM »
Ok, ty, it's probably iTunes/my itunes.

Other Announcements / Re: Roguelike Radio podcast
« on: September 22, 2014, 07:54:43 PM »
Is there a feed with the old Roguelike Radio podcasts available somewhere? I notice the one I subscribed to through iTunes only goes back to around episode 50. I suppose I could go to the website and pull them out of the embedded player in the blog posts - just wondering.

Programming / Re: Writer needs Coder
« on: September 22, 2014, 07:37:18 PM »

Date Registered: September 14, 2014, 05:05:16 am
Last Active: September 14, 2014, 08:58:22 am

I think he long since fled. We may just be pissing in the wind.

Programming / Re: Writer needs Coder
« on: September 22, 2014, 07:36:01 PM »
  double post removal

Programming / Re: Writer needs Coder
« on: September 22, 2014, 07:27:34 PM »
It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use. 

I started with a lot of pointer based dynamically allocated structures of the type Brigand evidently prefers - but discovered that most of the central elements of the game (actors and events and the schedule and the map) need to have many references to each other, in places that depend on the semantics of individual subtypes of those classes - so deallocating anything WITHOUT leaving references to it somewhere is very difficult and gets more difficult the more different kinds of things you have.  You wind up having to walk virtually the full game's data structure deleting references every time you want to delete anything.  Otherwise, you wind up with dynamically allocated data containing references to deallocated things.  If your references happen to be pointers, that's bad for two reasons, because there are two different kinds of bugs it can cause when you try to refer to the object the stale pointer points at.  First, you can crash, which is bad, but you can also wind up referring to  things allocated after the things the original pointers pointed at were deallocated, which is worse.  Also, pointers were an extra headache for save-and-restore functionality, because you had to swizzle all the pointers to get a restored game where the pointers mean the same thing as the pointers in the saved game did. 

So I eventually abstracted dynamic allocation, using a manager class for each data type.  Now when I say New_Actor(), the manager for actors decides where it's going to keep the new actor and returns a reftype.  The manager handles allocation, and keeps a pointer (the ONLY pointer to that actor to live in a dynamically-allocated data type) in a hash table keyed by the reftype value.  A reftype value, unlike a pointer value, is never reused, so I don't have to worry about aliasing.  I can deallocate on command, without worrying about crashes caused by following stale pointers.  When something hands the manager a stale reftype, it returns a null value without crashing, which can be checked for and handled at the call site.  Finally reftypes mean the same thing in a restored game that they meant in the saved game with no need for pointer swizzling; the new pointer value, whatever it is, is keyed by the same reftype value inside the actor manager, so the rest of the code, which handles data structures that contain only reftypes, never pointers, need never worry about it.

There's no "maximum number of actors," nor "vast amounts of wasted space", both because the data managers do dynamically resize the hash tables at need.  This also takes care of "compacting the array", and does not require walking data structures changing reftypes stored in game data to  refer to new array locations when it happens.   The complexity cost is an O(1) hash table lookup whenever a routine needs to acquire an actual pointer to data, and that has not been a noticeable burden. 

Anyway, the rules are simple. In any dynamically allocated data, you store reftypes rather than pointers.  When you actually need a pointer, you use the reftype to look it up.  Any time you use a reftype to look up a pointer, you check to see whether the pointer is NULL.  If it is,  that datum no longer exists.

And, um, underneath it all....  the data manager classes use hash tables which are implemented in terms of arrays.  Which are what GM uses....  and what annoys Brigand.

One man's drink is another man's poison?

What your saying may be true, but the conversation stops for me at "need to have many references to each other". As you say, as soon as you start placing pointers everywhere, you end up with memory leaks - you get circular references that don't get garbage collected but you cant reference, stale references that are pointing at some object that is now out of scope - the object continues to exist because "something" is pointing at it, or the most fun bug to track down, the null pointer reference (which is admittedly hard to debug in dynamically allocated system, so that it a point for doing it with arrays).
deallocating anything WITHOUT leaving references to it somewhere is very difficult and gets more difficult the more different kinds of things you have

I keep it simple - items/inventory instances point at/are pointed at by an actor or a SINGLE map manager (for items laying on the ground) and that's it - the destructor for the actor simply points the item objects back at the map manager (the items fall to the ground) which also makes it easy to determine what gets displayed. Actors are in an action queue, eliminating the need for a schedule, and that's it. The only cross pointers you get are actors targeting other actors. The first thing I do in the destructor is pass the 2 lists a single time, and set the pointers that refer to the dying object to null before the object goes out of scope - it takes literally 1 line of code in a do/while loop, and eliminates the need for a manager class as well as null pointer references.

Yes, I do have to peel off the objects when I save and then write them out manually, but that all occurs in one easily maintainable spot (and what other way would you do it anyways?). Each object has a unique id that sets the pointers back up when I load the game. Its an easy way to do it that I think the OP can grok as he is learning a language. (swizzling as you say)

Maybe I'm unrealistically biased, but I just like super encapsulation with a one-way pointer system; I definitely have produced spaghetti before, going overboard with pointers, but its something everyone does as they are learning. (I should add I usually avoid 2-way pointer structures for the very reasons you described; eg, doubly linked lists)

My entire argument is based on simplicity of coding; of course doing it the way you described produces in a more robust system that results in more stable memory use and eliminates null pointers/run time reference errors, but I don't think this is a beginner task. (After all, GML is supposed to be newbie friendly with its drag and drop IDE.) I don't even know if it's possible to do it this way in GML, but I could be mistaken.

Either way it goes, I think the real take away from all this conversation is that the OP quit reading this thread a long time ago (either scared off, or went elsewhere when told to do it themselves.)

Programming / Re: Writer needs Coder
« on: September 22, 2014, 03:01:36 PM »
I'd almost forgotten about a lot of that stuff, I've not coded outside of GM in at least a decade, besides going through code looking for errors for people.

Nothing wrong with that - in spite of its limitations, I like it a lot too. If they added true OOP support, as far as my hobby stuff goes, I probably would just use it exclusively too.

Pages: [1] 2 3 ... 7