Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 06 Feb 2012
Offline Last Active Dec 26 2013 02:44 AM

Topics I've Started

Map "areas"

31 August 2013 - 06:32 PM



Suppose one has a 2D grid map for a game, and one wants to define special "areas" on the map, which could be bounded by a rectangle, ball, or polygon, and to which could be associated an effect or a name or something. I suppose one could store a list of these along with the level map, but what's the most efficient way then to find, given the player's position, which area(s) the player is in? How is this usually handled in games? Is the check performed every time the player moves?

Programming origin of (bug? feature?) in old game ("Duke Nukem 3D")

17 August 2013 - 10:59 PM



(I'm posting this here because to me it seems game-programming related, but if you think it should be elsewhere, you can move it)

I saw this on Wikipedia:





No-clipping can conflict with other elements of the game. For instance, in Duke Nukem 3D, and the Commander Keen series, having no-clip and walking outside the level area causes death, and if the player has god mode activated the game will be left in an infinite loop or crash due to the way god mode was implemented. In most source ports for Duke Nukem 3D, this problem is corrected and it instead behaves more like Doom.



I'm curious about this. Now, Duke Nukem 3D's source code has apparently been released under free license (GPL), so I suppose one could dig through it and/or run experiments, though I don't feel like doing it right now. What would cause this phenomenon (namely that going out of the level in "noclip" mode kills you), from a programming point of view? As it doesn't seem at first obvious that this kind of thing would occur.

Game loop question: how to solve this problem?

29 May 2013 - 05:56 PM



I was looking at this:




in the context of making a "rogue-like" game. Namely, I was wondering whether this could be used to handle stuff like the inventory menus and so forth (using different "game states" for menu mode and playing mode). But then I ran into a snag: if you have a loop like this:






where in the "main" state, each round of the loop would represent one turn (wait for input, do the command for that turn, repeat).


But then I notice a snag: if it changes to the "menu" state to get, say, an item to drop, and then changes back to the main state, the loop will try to execute a full input-included cycle, instead of immediately running the logic for the turn in which the item was dropped. So how does one avoid that?

Rendering system for a "rogue-like" game.

18 January 2013 - 02:30 AM



I was wondering about this. For those of you who don't know, "rogue-like" games are a kind of game that feature randomly-generated levels and other content, are a kind of RPG, are turn-based, feature "permanent death" (no save games, or saves only work as indefinite game pauses and not reversion steps), and usually have simple graphics, sometimes even just "text-based graphics" (using symbols like "#" for walls). Now, I was wondering: how would one go about making the "rendering" system for such a game, so as to be able to support both text-based graphics and also being abstracted right so as to relatively easily drop in a render system to render tile-based graphics? Note that these two may use both hugely different low-level libraries and APIs (e.g. terminal output for text mode, SDL or similar for tile mode), and also the data that need rendering are different (you render text characters in text mode, sprites in tile mode).


What would you suggest? I was using C++ to write the program. It also needs the ability to put up a "dialog box" (perhaps drawn in with text characters, or with simple graphics in graphical mode) that can have options/lists, e.g. the stuff you're carrying in your pack, magic spells, etc. .


What's the best way to implement a level map like this?

27 February 2012 - 06:08 PM


I've got another little dilemma for you. I'm wondering what the best way is to implement this kind of level map for a game in C++ is. The map is supposed to be a regular 2D grid of. What I have is something similar to this:

enum TileType { // not an enum in the current code though but should be changed to one

class LevelTile {
		  TileType tileType;
		  ... (various flags and settings in here) ...

class LevelMap {
		  std::vector< std::vector< LevelTile > > mapTiles;

The trick part is representing the different types of tiles. Here, I have the tiles referred to by a type-field. But then we need a bunch of switch statements to give different tile behaviors based on different types of tiles. Would it be better to use multiple types of LevelTile (i.e. derived classes)? But then comes the questions of:

1. we need to then store an array of pointers,

2. we need to allocate on the heap with new (and that takes more time, doesn't it, than just updating a type field) if we want to change a tile

3. when changing a tile, we need to be able to preserve its flags, which means we need some kind of "copyFlags()" function or something in LevelTile that would need to be called when doing such a change and so would complicate setting one tile to that of another type, or have conversion code for each kind of tile

Though these may not be insurmountable problems (e.g. in issue 3, we could have some kind of "mutateTile()" function in LevelMap that wraps up that calling of copyFlags() etc.). But I'd like to be clear as to which way is the "preferred" way of doing this: multiple types of Tile or type-field.