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.


Topics - penguin_buddha

Pages: [1]
1
Programming / Leveling/Experience
« on: October 10, 2013, 03:18:56 PM »
So I'm comparing alternatives for how to have the player increase in power as they play my game. I wanted to get your opinions/preferences on some of the different options:

Experience Gain/Leveling:
  • No Experience: No leveling system, players only get more powerful through equipment and simply getting better at the game
  • Experience from Kills: Players gain experience whenever they kill a monster. Experience can be spent to improve stats and buy abilities. Could give rise to players feeling the need to fight everything rather than flee/hide.
  • Experience from Descending: Players gain experience whenever they descend to the next floor. Promotes players just running through floors, though they'd miss out on loot.

Starting Stats:
  • Static: Every game the player starts with the same stats. More balanced gameplay.
  • Point Buy: The player starts with an amount of experience to spend to increase their stats.
  • Random: The player's stats are randomized. Could cause large swings in game difficulty from game to game.
  • Archtypes: The player chooses a starting class/archetype and their starting stats are based off that

2
Programming / Effect Architecture
« on: August 23, 2013, 03:17:27 PM »
I've been working on a roguelike game for a few months now and I've gotten to the hardest part yet, effects! I'm talking about everything from an effect that represents fire by continuously damaging an object to an effect that summons a creature, to an effect that modifies the stats of an object. So obviously there are a lot of potential effects. The question is how to go about implementing effects in an object oriented manner.

My current approach is to have an Effect class that is really broad. It contains multiple hashmaps that can contain game objects, simple values, locations, and other effects. Most instances of the class won't utilize all of these hashmaps. Each effect also has a list of types. These define how the game interprets the effect.

Examples Types: damage, healing, armorModifier, summon, etc.

For example, when an agent suffers damage the game will look for effects on that agent of the type "armorModifier". If an effect with that type exists on the agent, the game knows there should be a key/value pair in one of the hashmaps that tells how much armor should be added/subtracted. This would be for a passive effect, however many effects are active. Such effects have an activate() method that is called. The Effect class then acts based on the types of the effect. So if its a damage effect it will look for a key/value pair for how much damage, what targets to damage, what damage type it is and so on.

So if it wasn't complex enough for you already, there are also effects that really only modify other effects. For example, the activateOverTime type of effect just activates another effect at a certain frequency. The onHit type of effect applies a new effect to whatever an Agent attacks.

Here are some examples of effects and what types they would have:

  • Fireball: damage, aoeBurst
  • Vampirism: damage, healing
  • Alien Parasite: damage, activateOverTime, onTargetDeath (would create the Summon Parasite effect)
  • Summon Parasite: summon


So, I'd like your input on how to best implement this system. My current method can work, but its getting more and more complicated. I've considered creating a child class for each "type" of effect, though that would be a lot of child classes.

Thanks for any help,
Nathan

3
Early Dev / Escape into Black
« on: May 10, 2013, 05:35:24 PM »
Hey guys, I've decided to stop just lurking and post about my current project, Escape into Black. Escape into Black (EIB) is going to be my first RL and I plan on reusing its engine for my future, more ambitious, projects.


Escape into Black


Overview: Escape into Black has a simple story. You are a citizen of a mountaintop city who was framed for murder. You were judged guilty and given a choice, a clean death or the Pit. The Pit is a large hole in the ground near the center of the city which drops into a large series of catacombs that are said to spread all the way to the base of the mountain. Legend says that there is an exit from the catacombs, though it has never been confirmed.  Most don't even survive the drop into the cavern floor, but you decided to try your luck. You stand on the edge of the large hole, looking down at the corpse littered cavern floor nearly 50 feet below. You feel the steel tip of a guardsman's pike pressing against your back, forcing you closer to the edge...

Completed Features:
  • randomly generated caves (modification of BSP)
  • field of view using shadow casting
  • inventory system
  • loading from XML files
  • A* pathfinding for AI
  • looking and targeting
  • melee, ranged, and thrown weapons
  • action-delay based turn system

Planned Features:
  • monster dens
  • rivers flowing through the map
  • stealth
  • additional skills (currently only have combat related skills)
  • crafting
  • injuries (currently just have simple hp system)
  • hunger/thirst/exhaustion
  • experience
  • character creation

Ill add to the to-do list as I go. The game isn't playable yet but here are some screenshots of its current state. Note I'm using squidlib for my graphics.







Let me know what you think!

4
Programming / Lighting Issues
« on: September 24, 2012, 03:32:01 PM »
I've successfully set up the FOV and Lighting for my game but there is one thing wrong. As it currently works, a wall tile can be considered "lit" because it is within the LOS and radius of a light source. This is fine, except that the wall tile is considered lit even when being viewed from the opposite side. For example:

. . . . .. . . . Wall . . .. . . .. . . . .
PC . . . . . . Wall . .. . . . . Light
. . . . . . . .. Wall . . .. . . . . .. . .

In such a scenario the player would see the walls as lit up, even though they are getting light from the opposite direction. Any ideas on how to prevent this? My current method of FOV is with a shadowcasting algorithm.

5
Programming / SquidLib: Getting keyboard input
« on: September 13, 2012, 04:22:49 PM »
I've been looking at Squidlib and i'm interested. My only question is whether the library has any build in methods to get keyboard input. As far as I can see, it doesn't. I'm curious how Eben gets input for his games...

6
Programming / libjcsi keyboard input
« on: September 12, 2012, 05:25:26 PM »
I've been having trouble with libjcsi. I'm getting keyboard input via the inkey() method:

CharKey key = csi.inkey()

From this you can get the inputted character's code (key.code). The problem is many keys are giving the same code 116 rather than the code their supposed to. For example, CharKey.PLUS is 55, but the key.code i get when using either plus on the keyboard is 116. Any ideas on what my issue is? Many other keys return the same thing, 116.

7
Programming / libjcsi window size
« on: September 05, 2012, 03:21:53 PM »
Can someone familiar with the libjcsi library answer a simple question? What are the bounds on which I can draw without throwing errors? The window seems to be 25 X 80, but only throws errors when the 80 is exceeded. It seems to let me draw off the screen in the other direction as far as I want.

Anyone know what the true screen size is and whether its changeable?

8
Programming / Filling Irregular Shaped Rooms
« on: August 31, 2012, 06:46:49 PM »
Hey guys, I've been working on my first roguelike over the past couple of days and I've hit a snag in map generation. I'm using a hybrid of these two algorithms.

http://roguebasin.roguelikedevelopment.org/index.php/Basic_BSP_Dungeon_generation
http://roguebasin.roguelikedevelopment.org/index.php/Irregular_Shaped_Rooms

So I'm currently trying to fill the rooms creating using the Irregular Shape method. It describes a method to do so but it seems like there are times when that method would fail. For example...

# = wall
O = open space

#########
###O#####
##O#O####
#O###OOO#
#O#####O#
#O####O##
##O#O#O##
###OXO###
#########

Would fill the area marked "X", when it shouldn't. Any ideas on how what could work?

Pages: [1]