Messages

1

Programming / Re: pedantic object oriented question

« on: March 30, 2013, 07:05:19 PM »

I do:
Every tile on the map has a reference to the map, a reference to the creature inhabiting the tile and a reference to the item on the floor of the tile. Each creature references the tile it is on. You can get the map a creature is on through creature->tile->map.

So everything is accessible from everything directly. The only danger is things falling out of sync, but as long as you have methods like creature.moveto(tile) which guarantee everything is fixed and only go through those methods everything is fine.

2

Programming / Re: who has implemented a hex grid?

« on: March 01, 2013, 09:28:13 PM »

Careful you don't become hooked on ever more complex tile systems. I knew a guy who became facinated by strange coordinate systems and one day claimed he had discovered a tile system based on non-euclidian geometry. A week later he went totally mad, last time I saw him he was screaming something about a black goat in the woods.

3

Programming / Re: game loops and information screens

« on: February 28, 2013, 01:08:21 PM »

I like to compartmentalize, so that when I go bug hunting I know where to look.  What I do is each panel handles it's own painting and key events, and the main graphics loop only calls the active panel.

The engine class is global, so any part of the program can make stuff happen.  For example the inventory panel can tell the engine to put an item at the player's feet when he drops something from his backpack.

Exactly the same. Engine global variable feels dirty everytime I use it but it works. Avoids passing numerous parameters everywhere.

4

Programming / Re: game loops and information screens

« on: February 27, 2013, 09:11:55 PM »

I don't know if there's a more sensible way but I use the "one game loop with "if/then" statements to correctly implement events/graphics for whichever screen is active"

Only one input-accepting UI screen (inventory, character, item details) can be visible at once.

In the drawing part of the loop I first draw the map. If any UI screen is visible I draw that over the map.

In the keyboard event handling part of the loop, I check to see if a UI screen is visible. If one is then I redirect all keyboard events to the handler for that screen.

So each screen has it's own handler. Pretty much all handlers handle the escape key which makes the UI screen invisible and so keyboard control reverts back to the main handler.

5

Programming / Re: Single item per tile?

« on: February 21, 2013, 12:02:44 AM »

Thanks for all the interesting/useful comments. What I'll do from this feedback is reduce the item drops I was planning by making individual items more important, but fewer in number and see if this will allow single drop to work and if not..do something else.

Perhaps a chest icon could denote multiple items on a tile and the player would be expected to stand over the tile to see what's in it? Although I am wary of going too far into iconary (that's not a word...) as in this case there isn't really a literal chest on the tile, it's just some kind of image metaphor for multiple items. So a chest magically appearing might kind of break immersion or make the player think WTF?

Also I was wondering, with single item per tile it is probably best to not encourage the player to drop lots of items in a single place. Is this an argument against weight based inventory as typically to the player might need to dump eg 8 light items in order to pick up a heavy armor?

6

Programming / Re: Map storage compression techniques

« on: February 20, 2013, 11:26:29 PM »

This is pretty neat. That's a 25 million tile world compressed to 272kb, which is what about 0.01 bytes per tile.

based on that I ran some numbers (which are probably wrong) for fun.

100gb of disk space = 9,000,000,000,000 tiles (*)
400gb of disk space = a world the size of the moon at 1x1 meter per tile resolution
5.5 terabytes of disk space = a world the size of the Earth again at 1x1 meter resolution

Have you thought about breaking your map into chunks and virtualizing the data? That would help in almost all aspects of performance if you only loaded, saved, transmitted and held in memory the parts of the map around the player (or players).

Youtube video looks good. Reminds me of terraria, but I prefer your tile graphic style for a game like this.

(*) Even this is already too much. Even if the player could see a unique 80x40 portion of the 9 trillion tile map every second it would take them almost 90 years to see the whole map. And the Earth map isn't so large with 7 billion players. But with a handful of players it is waaay too big. Even minecraft servers I played on which were much smaller (4000x4000) the maps were too big for multiplayer player vs player, couldn't find people! Even in coop play just building stuff where people would cluster together, 99% of the map was just unused (and largely unseen) wilderness.

7

Programming / Re: Roguelike graphics project

« on: February 20, 2013, 10:35:11 PM »

I enjoyed looking at each of these tiles, I especially like the snake ring, I wish I had a ring like that in real life.

8

Programming / Single item per tile?

« on: February 17, 2013, 06:33:20 PM »

What are people's views on single item per tile vs multiple items per tile?

Many of the modern roguelikes I have played (eg Brogue, Infra Arcana and DoomRL) only allow one floor item per tile. I vaguely recall nethack from long ago allowed multiple items per tile.

I realize the advantage of single item per tile is that all items can be represented by a symbol or image on screen, but what about the problems with finding space to drop items? monster drops too. How many games still use multiple items per tile and how do they handle displaying that? I was thinking of just having an icon representing a pile of items (one or more items).

9

Programming / Re: Screenies of LOS :3

« on: February 17, 2013, 03:46:53 AM »

I agree with optimization to get the program running on slower machines. Maybe r^2 and for loop optimizations are necessary for that, but it would bug me to add them without knowing that they really were needed.

10

Programming / Re: keeping track of multiple enemies health?

« on: February 14, 2013, 09:25:07 PM »

From what I remember of C++ the problem is you can do this:

Code: [Select]

Globals.h
CMap map;

-----------------
Main.cpp
include "Globals.h"
void main()
{
   map.UsingMyMap();
}

But as soon as you add another source file and try to include Globals.h you get "CMap map is already defined" errors, because both source files are including a header which defines CMap map and you can only define it once.

What you can do is use the keyword extern in the header:

Code: [Select]

Globals.h
extern CMap map;


This is no longer declaring the variable it's saying the variable is declared elsewhere, ie external to the header file.

You then declare variable in a single source file:

Code: [Select]

Main.cpp
include "Globals.h"
CMap map;
void main()
{
   map.UsingMyMap();
}

You can then access the same global map variable from other source files by including Globals.h:

Code: [Select]

SourceFile2.cpp
include "Globals.h"

void func1()
{
   map.AlsoUsingMyMap();
}

Because by including globals.h, globals.h tells the source file that the CMap map variable exists and is defined somewhere and the compiler is happy with that.

11

Programming / Re: Screenies of LOS :3

« on: February 14, 2013, 09:03:39 PM »

The only thing I disagree with is pre-calculating r^2. I strongly disagree  . It's better to optimize after hitting performance problems than before, because it's hard to guess where the bottleneck will be (or even if there will be one). It might turn out r^2 doesn't need optimization. Then again maybe you know it will do, in which case sorry for butting in. But the lazy path of optimizing later not before has served me well so far

12

Programming / Re: Combat Systems

« on: February 14, 2013, 01:29:50 AM »

There's the survival tricks you learn from the game itself, eg in brogue learning that fire kills zombies real easy and also that you better have room to backtrack if you ignite one. Then there are the survival tricks you learn from laboriously diving into the hidden game mechanics much as you have done to figure out eg the optimal way of assigning enchanting objects, etc.

The perfect player would have to master both methods. And that means die-hard players who do challenges beyond just ascending are going to inevitably have to dive into the mechanics to get a necessary edge. But I think the more typical players (like me) don't want to have to (or can't) do that. That doesn't mean I want a game's mechanics fully transparent. It just means I want the game to give a large scope for improving by trying and dying, so much so that it overshadows the point of diving into and understanding detailed combat mechanics. So I am happy to remain in ignorance and not understand whether enchanting armor or weapon is better. I will work off the premise that both are roughly equal in terms of survival (even if they are not). All my survival skill will come from the interesting stuff I learn through dying and trying, and I think in a good game this should be sufficient to master the game.

Lets say 90% of survival tricks in a game can be obtained by just trying and dying and only 10% of survival tricks require detailed knowledge of the combat mechanics. I would think the game in that case should be tuned to masterable at 80-90%, or something like that. The game shouldn't be too hard that players are forced to obtain over 90% of the survival tricks which would demand they dive into mechanics to master it.

Specifically with enchantments and the question of whether to level up the armor or the weapon, I guess part of that problem is it's just leveling up equipment with numbers, boring numbers. 215% melee up from 120% vs higher armor count which increases defense by ?% Yawn. I can't be bothered to figure out which is the better choice, so I happily just guess what my character is most deficient in. I prefer the kind of choices where you choose a new skill from a set of separate distinct skills where there is more than just a math comparison (eg do I want the ability to summon allies or the ability to heal, there's no clear math comparison that can be made there...the player is forced to rely on interesting human decision..which is perfect)

"there are essentially 3 problems you have to solve to succeed- A solution for dealing with Revenants (immune to physical damage- not really a big problem but still pertinent), a solution for surviving Fire-breathing (from dragons and other deep-dwelling denizens), and a solution for horrors."

It's probably a bad strategy but I like going full on mage and enchanting a ring of wisdom, staffs and armor. So I can deal with all those monsters quite easily (except dragons which I just run away from...I didn't know there was a solution for surviving fire-breathing other than just burn). The killer problem monster for me is golems which just reflect my staff attacks although I am not great at the game so I might just not have discovered a way to kill them easily yet.

13

Programming / Re: Screenies of LOS :3

« on: February 14, 2013, 12:25:17 AM »

nice,

What you've done is calculate the player's field of view using line of sight algorithm to calculate whether each tile on the map is visible to the player. This is what I did at first, I prefer this because it is intuitive and works fine and like you said it's a nice piece of code you can reuse for aiming.

But just a heads up about something you might encounter (hopefully not) because you mentioned making the map larger. Unfortunately I found the performance was too bad with larger maps, because as the width and height of the map increases the time taken to calculate line of sight of every tile exponentially increases. Also there is additional hit if you want to calculate monster FOVs too.

You might have no problem depending on how big maps you intend and whether you intend to calculate monster FOVs each turn. But just in case you hit this wall, there are algorithms specifically for calculating field of view that are more efficient and can handle bigger maps because they reuse information and avoid checking tiles behind obstructions. Unfortunately those algorithms range from complicated to absurdly complicated to implement.

The one I used (because it seemed the simplest, performs almost the best compared to others and seems accurate enough...) is:
http://roguebasin.roguelikedevelopment.org/index.php?title=FOV_using_recursive_shadowcasting

Unfortunately it's a bit of a mind-**** and took me weeks to understand it on paper before I could event attempt to implement it. Then it took me weeks more of bug tracing because I kept screwing up. In hindsight it would have been better to just understand it and then use someone else's code...

Just something to bear in mind if you find your turn-calculation takes too long with a larger map.

Although perhaps a better option (rather than wasting weeks on a more complicated algorithm) is to limit the maximum view range of the player so you don't need to calculate the visibility of all tiles on the map. The map could be infinite if the player can only see 20 tiles radius. A trick to largely hide this would be to make the map generator never (or rarely) generate huge open areas where the player would notice the restriction. Or just use the convenient excuse that the player is carrying a light source and it can reach go so far.

I know at least two years back when I last played it, minecraft was using a similar trick. Hugely inefficient, the client fetches entire 16x16x256 tile chunks from the server, even though the vast majority of those tiles are typically underground and the player can't see them. So they didn't spend time making a complex algorithm to only send the visible 3D tiles (if that's even possible), they just send them all (an unfortunate consequence of this is that people can create undetectable client x-ray hacks...). Then on the client I believe they just draw every tile and let the graphics api/driver/card deal with occlusion. They limit the performance hit (on the server and client) by putting in a shorter horizon view distance...although it's so short you often see the horizon loading in the distance. This is something that's always bugged be about minecraft from a purity point of view (plus the x-raying). Possibly there is something technical I don't understand which forces them to it this way. But on the otherhand the game was somewhat popular so it shows a complex algorithm isn't always necessary and tweaking things like view distance can work.

14

Programming / Re: User Interface suggestions

« on: February 06, 2013, 10:04:33 PM »

Cool idea looks good. I second displaying the player stats though and also the stats of enemies, or at least the targeted enemy. I mean sheilds:weak hull:damaged doesn't tell me how much more damage the shields or hull can take in order to make decisions.

15

Challenges / Re: Early 7DRL Declaration

« on: February 02, 2013, 11:59:15 PM »

I stand corrected