Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jhxmt]

Hmm, actually, you're right, that does look a lot cleaner.  I think initially I started off with the VisMap idea purely because I thought, "Hey, it'll be really simple to reference and really simple to set up."

In hindsight, yes, juggling two different arrays which effectively refer to the same thing is rather, uh, counterintuitive!    I may unpick it and start again - this will probably also help solve the "@s in space" problem (which, as Soadreqm suggested, I believe is due to the fact that I screwed up on my entity creations and managed to make all the Tiles refer to the same entity).

Ah well, I almost got there, hopefully I'll learn to avoid needlessly elaborate solutions for next time! 

[Kerbobotat]

Im hitting the same kind of stumbling block as you jhxmt. Trying to wrap my head around the 'scrolling window on a big map' idea.


Is it just as simple as; take the players x,y position on BigMap, and draw every tile/object from BigMap that lies within the window to the screen, rinse and repeat every time the position changes?

What happens if the player nears the edge of the map, so that the furthest edge of the display window falls outside the tiles of the map? Been stumping me for a while.

[jhxmt]

What happens if the player nears the edge of the map, so that the furthest edge of the display window falls outside the tiles of the map? Been stumping me for a while.

Yeah, been thinking that one through myself.  I've come up with a few potential solutions:
1) Just stop the map moving, so the scrolling stops and the player just runs towards the edge of the map.  Bit of a pain, as you'd probably have to rewrite whatever function you're using to render the display.
2) Just make your map bigger than the area the player can move in.  If your player gets within thirty or so tiles of the edge (i.e. before the edge comes onto your display), prevent them from moving any further.  Not exactly elegant, but works.
3) Wrap the map.  If the left hand edge of the map comes onto your display, fill the remainder with the squares from the right hand edge.  Might work if you want a wrappable world.
4) Load another map and start feeding in tiles from that map.  This is like the wrappable world idea, except you're using a different map rather than the same one.  I think this is how a lot of larger-world roguelikes take care of this problem, as it means you can load and unload maps from memory as the player gets nearer to/further from them.

I think initially I'm going to go with inelegant option 2, and work on 3 or 4 later on once I've got the scrolling itself sorted out.  In the meantime, I'm starting off with a big map and dumping my player in the middle of it, so I can move around a fair few tiles before I hit the edge. 

[Urist McScoopbeard]

How do you guys handle loading map data (presumably tile-based)?

as it is now, I have it stored in a textfile where as such:

0.0.0
0.1.0
0.0.0

etc. etc.

I take a string tokenizer with a . delimiter and seperate each value into it's position in a 2-d array, which determines the look of each tile.

I guess that's inefficient, but I'd like load/save information to readily accessible and modifiable, how are you guys doing it?

[Abalieno]

Implemented a sort of mini-map into libtcod, by using 8x8 font building up a 16x16 tilemap Both coexisting together.
The small map fits the screen, while the big one is scrolling properly.
Coding-wise: I simply draw the whole map on a offscreen console. And then only blit onscreen the correct portion. I just need to change the origin of the portion by using the coordinates of the player and make sure it doesn't go below 0 or maximum.

Spoiler (click to show/hide)

[Girlinhat]

For the player-chasing camera... The trick is to offset your view.  First realize that you start from the upper left corner, and you go the width and length of the screen.

For instance, here's the object.draw function that's used in the rendering:

Code: [Select]

    def draw(self):
        libtcod.console_put_char(con,25-player.x+self.x, 25-player.y+self.y,self.char,0)
        libtcod.console_set_char_foreground(con,25-player.x+self.x, 25-player.y+self.y,self.color)That's in Python, but the basic idea translates into different syntax.  This is the tile it will print itself to: [25-player.x+self.x , 25-player.y+self.y].  That gives a screen width and height of 51, because the player is at the center, and it goes 25 to either side and +1 for the center.  So if the player is, for instance, at location 5,5 and the item is at 6,6 then the item will draw itself at 25 - 5 + 6 = 26.  Similarly, if the player were at, say, 10,11 and the item were at 12,25, then...
25 - 10 + 12 = 27
25 - 11 + 25 = 39
On a 51x51 screen, that fits nicely.
So, in other words:
((Screen Size - 1) / 2) - player's position + tile's position

This isn't fantastic, because it will still try to draw tiles that are outside the view range, but whatever.  It works well enough for figuring out how to make it work.

[BlindKitty]

So, here comes a little 'teaser' form my game (Forgotten Maze, however title is so lame ). Right now I have a little time to work on it, but it is certainly going forward. The screenshot contains following images:
Left upper corner: Farewell Sheep, which is a 'goodbye' image after playing.
Right upper: Battle menu, which contains actions you can take, shows output of the last turn and your (and enemy's) Hit Points.
Left lower: Test version of main menu - all four options work now.
Right lower: equipment selection screen. It is evolving to become a shop window right now (with a little setback in form of Visual Studio updating).

Spoiler (click to show/hide)

[Dutchling]

You misspelled campaign >.<

I like the multi-material weapons. And that sheep :v.

[BlindKitty]

I misspelled it again? >.< I'm non-native English user and while for the most part I have little problem with language, I notoriously misspell this word. Probably because it ends with -ign, which kinda looks like -ing suffix for continuous verbs. Thanks for spotting it! I will certainly repair it soon.

As of multi-material items, I want to make it big. I've got a list of ~40 metal, like 50 wood types, and I'm going to have at least dozen different leathers - and even more gems. And some dyes, but thats a different matter. For now, every item has two materials, but when I will be done migrating to more potent database format (right now I'm using single .csv file for all the game data) it will open possibilities for more complicated ideas, like a sword with outer blade of hard and brittle metal, inner part of the blade of lighter and more flexible metal, wood on hilt - and gem encrusted at this.

Sheep, yeah. Sheep are good.

[alexandertnt]

How do you guys handle loading map data (presumably tile-based)?

as it is now, I have it stored in a textfile where as such:

0.0.0
0.1.0
0.0.0

etc. etc.

I take a string tokenizer with a . delimiter and seperate each value into it's position in a 2-d array, which determines the look of each tile.

I guess that's inefficient, but I'd like load/save information to readily accessible and modifiable, how are you guys doing it?

My current project in Python (which is not tile based, and uses Pygame) uses the Pickle library to serialize all the game objects out to text files. Most Object Orientated languages have the ability to serialize objects (except, as far as I am aware C++).

All of my game objects are stored within a map class (representing a level). I just pickle it in/out to a file.

Although this is most likely less efficient then the way you are doing it. It is, however increadibly flexable. It lets me add more stuff to my game (expanding game objects etc) which will just magically save and load.

[Levi]

I'm using pickle as well for saving and load, although I actually convert my data objects(map, item lists, monster lists, other things) into a few big Dict objects and then Pickle-save them.  Its not quite as easy, but I was paranoid about save-games breaking between code edits at the time, so I wanted to explicitly state what gets saved/loaded.

---Brainstorming---
I was sick for most of last week so I haven't gotten a lot of work done on my game(Also been playing too much Civ 5 and Dishonored ).  Now I'm going to do some brainstorming.

I was working on the AI code for a monster to go to the barracks to sleep, and then go back to his post when he wakes up.  As I was writing it I realized that I'm going to need a more robust system to help the AI get pathfinding info when a monster wants to go somewhere.  Right now I need to do this:

1)  Find all the barracks rooms from list of rooms.
2)  Does each barracks have a bed in it?
3)  Can I path to the beds?
4)  Choose the barracks/bed with the shortest path.
5)  Done.

My digging monsters do much the same thing.

1)  Find a list of walls marked dig AND have an open space next to them.
2)  Sort by shortest distance.
3)  Keep checking them for a valid path until we find one.
4)  Done

And my monsters that are checking to attack someone:
1)  Check list of monsters for ones that are in eyesight of this one and are an enemy.
2)  Sort by closest
3)  Pathfind to that location.

I can see myself spending a significant amount of time when writing AI just doing this "Find blah if blah exists and pathfind to it".  How to avoid?  MOAR INFRASTRUCTURE!

I have a bad habit of writing far too much infrastructure and not enough actual game, but whatever.     My plan is to create a PathFinder class to ease the load on the AI sections.  It needs to make it relatively easy for the AI to get a pathfinding target.

Code: [Select]

#Pseudo code structure

class PathFinder:
 
  def get_path(monster, target): #finds a path to a particular object.
    #Target can be a [x,y] coordinate, a monster, a construction(bed), a zone(room) or an item. 
    #code...
    return path
 
  def find_path(monster, type, target, zone=nil):  #finds a path to a generic object.  Like "barracks" or "goblin".
    #type must be one of "zone", "construction", "monster", "item"
    #target is the more specific type, such as "bed", "goblin", "weapon"
    #zone is optional.  It restricts to a particular room type, such as "barracks", "guard post".
    #code...
    return path

  def get_dig_path(monster):  #specialized code for digging, because its a bit more complicated.
    #code...
    return path

I think this is a fairly general and sensible way of doing things, and will let me write more complicated AI code a bit faster.  Also if I have to optimize later, I only will need to optimize this new PathFinder class, instead of every AI routine I write.   

[Abalieno]

Implemented isometric walls

[Levi]

That is pretty cool.   Is that still done with fonts?

[Abalieno]

It's quite simple. All ASCII char sets have that one character with one half white and the other black. As well horizontally or vertically, and then the small square on each corner.

So it's just about drawing the block with foreground of one color and background as another.

For placing it correctly I just put an "if". It simply checks the position just south. If it's a floor, or unblocked, then you draw the half block, otherwise you draw the full block.

For the full isometric, I check for the position south, for the position west (for the vertical blocks), for both west and south (for the lower corner), and for the angle free if both other are blocked (for the upper corner).

[Levi]

Oh, haha I see.  Clever.