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 - Rabiat

Pages: 1 [2] 3 4 ... 6
16

The sun's UV radiation damages the light receptors of the retina, so if you'd look right at the sun long enough, yes, you'd go permanently blind. Usually the damage is only temporary, because the pupils contract involuntarily, and it would take enormous willpower to not look away before permanent damage is done.

It's somewhat safer to look straight at a sunrise or sunset because the light passes through the atmosphere diagonally instead of vertically, so much more light is filtered.

If your desire to go permanently blind is genuine, but you lack the necessary willpower for prolonged exposure, using a telescope at noon would do the trick almost instantly. And the odds of survival are substantial. ;)

17
Traditional Roguelikes (Turn Based) / Re: DoomRL 0.9.9.2 released
« on: February 15, 2011, 09:04:02 AM »
by the way, months ago, a graphical release was in discussion on your board (with screenshots if i recall correctly). Is this still planned?

In the 0.9.9.2. announcement the graphics version is mentioned just below the fold, so it appears to be in active development, or perhaps even in alpha. There will be graphics in the 1.0(.0.0) release for sure, but we'll have to be patient. DoomRL suffers from severe asymptotic versioning syndrome. ;)

18
Programming / Re: Realistic Zombie Apocalypse ANSII Shooter
« on: February 08, 2011, 09:33:25 AM »
If we're going to blast hordes of zombies with bombs and chainguns, count me in. I'd like mine to leave corpses and chunks, please. And resurrect on occasion.

Minor gripes:
  • There's no such thing as ANSII. The screens definitely aren't ASCII, or even standard ANSI. They're in ANSI modified to look like pictures.
  • I'm wondering what could possibly be realistic about an ANSI zombie shooter. A zombie invasion is hardly a realistic theme. Also, the map doesn't look the least bit realistic. Given the representation limitations of a character-based grid, I'd ditch the idea of realism, and focus on gameplay/fun and strategy instead. You could add doors, and stairs to different floors, for example.

Major gripes:
  • I'm not saying you can't compare this game to a roguelike, but the game seems to lack two elements that I like about roguelikes: randomness and field of view. I dropped ZZT ages ago because it couldn't generate random maps and there was no way to have a wall block the player's view; I'm not sure if newer versions of ZZT/Megazeux support this.
  • You'd get more/better feedback if people would be able to play the game. Release a barebones version quickly, and post a link. Also show it to the Megazeux community, I expect they won't give you as much grief about randomness or FOV as can be expected from roguelikers.

19
Traditional Roguelikes (Turn-based) / Re: Frozen Depths: cool! :-)
« on: January 27, 2011, 09:38:54 AM »
Yeah you gotta be careful with those altars, and if you see a pool of water with an item at the bottom, for the love of God don't jump into it!

You can safely get the item, if you're prepared.

Edit:

When I first entered the level, level 4 or 5 I think, it gave me a message about it being warm on the level.  The entire time, I stayed at warm and didn't take any warming food or extra clothes. I did have a cursed linnen hat on though. I spent most of my time exploring the level, and making sacrifices to the goddess in hope of getting my cursed hat off of me. It wasn't until I decided to leave the level that within just a few turns, I went from warm, to hot, to boiling, to dead.

The same thing just happened to me, more or less. I was on a warm level (DL16), a hand-crafted one with lots of traps. I was already warm, and walked through sludge, which slowed me down. While slowed, I blundered into a lava trap, and temperature went to hot. I stepped out of the lava (still slowed), immediately onto a paralysis trap. While paralyzed, I went to boiling, to dead. All this happened within two moves (spanning multiple turns because of paralysis). It makes sense, but a warm level with a lava trap, combined with slowing and paralysis, pretty much spells 'instakill' even if you're stark naked and cooler than Fonzie. ;)

20
Traditional Roguelikes (Turn-based) / Re: Frozen Depths: cool! :-)
« on: January 25, 2011, 09:03:36 AM »
When I first entered the level, level 4 or 5 I think, it gave me a message about it being warm on the level.  The entire time, I stayed at warm and didn't take any warming food or extra clothes. I did have a cursed linnen hat on though. I spent most of my time exploring the level, and making sacrifices to the goddess in hope of getting my cursed hat off of me. It wasn't until I decided to leave the level that within just a few turns, I went from warm, to hot, to boiling, to dead.

I don't think cursed items have anything to do with temperature. You just can't take them off, and they deteriorate more quickly. My guess is that the warm level is what caused it, although I haven't seen this happen within a few turns.

Quote
I put a crude bronze breast plate that I had crafted on the alter. I didn't notice any difference between before or after I put the armor on the alter.

Did you actually 'u'se the altar? Simply dropping a piece of armor on the altar doesn't work. You should see a message like 'the runes on the altar disappear' if you used it correctly. Also, did you wear the armor after putting it on the altar? There may be no apparent change to an item until you equip it.

(It isn't always obvious how to use dungeon features. I sometimes make the mistake to pray '_' at a shrine in stead of 'u'sing it, for example.)

[Edit: I just ran into one of these things, and it's called a 'stand covered in fresh blood', not an altar. When used, the description says 'The engravings have disappeared', not runes. Also, it made my main weapon 'harmless'.  >:(]

21
Traditional Roguelikes (Turn-based) / Re: Frozen Depths: cool! :-)
« on: January 24, 2011, 11:02:16 PM »
Anyone know what's up with all of a sudden getting hot and dying from boiling for seemingly no reason. That's what happened on the last game I played. I was doing reasonably well too.
Most levels are cold, but some levels are warm, causing your temperature to rise for no apparent reason. Did you check the @ screen to see if temperature was rising? (Simply waiting by a camp fire causes your temperature to rise quickly as well, but in that case the reason should be obvious.)

Quote
Also, anyone know what the blood stained alter that you place armor or weapons on does? Or the shrine that makes a red flash appear next to your equipment?
It vorpalises a weapon or a piece of armor. Come to think of it, if this got you a 'heat draining' weapon, it makes you absorb heat from killed monsters. You'd have to do an awful lot of killing to boil that way, though. ;)

22
Programming / Re: Celebration / Issue with loot
« on: November 08, 2010, 07:11:19 AM »
Actually, as they say, premature optimization is the root of all evil. Optimizing usage of time and space is useful only when it turns out that the game runs too slowly (which is very unlikely, unless one has huge maps, some specialized AI, or really does not care), or for educational purposes.
While I agree with you on the subject of premature optimization, I don't see how it applies to the point I made earlier, or my examples. I wasn't proposing an optimization, I was addressing what I perceive to be a flawed design decision. (I'm not just addressing Shaggy when saying that, it's actually very common.)

Quote
For now, use something which makes sense and is easy to program.
If we were dealing with a language in which we'd have to write our own linked lists, hash tables, etc., I'd agree with you. But in this case, we're dealing with .NET, which provides all these things, and makes them as easy to use as more fundamental programming concepts.

Redundancy, as you're suggesting, has its own challenges, especially when debugging two versions of the same data that are somehow inconsistent.

That's what I was thinking, because in the future if I get other errors with the lists I'll have more trouble debugging them on mine own due to not being familiar with them.
I don't mean to be disrespectful, and please don't think I'm trying to convince you to use something you're not familiar with, but your familiarity with Lists and Dictionaries is not necessarily a measure for their actual complexity. My personal experience is that they make coding and debugging easier, not harder.

This does imply, however, that I've derailed your thread towards a subject you feel uncomfortable with. I didn't intend to do that, so I'll stop bothering you with the framework evangelism for now. ;)

23
Programming / Re: Celebration / Issue with loot
« on: November 07, 2010, 09:14:07 AM »
You could be right about the 2D dictionary. I've seen several sparsely populated dictionaries up to six dimensions with millions of objects work surprisingly quickly, so I'm (subjectively) convinced the time cost won't be a problem. But I'm not as sure about the memory overhead.

If someone's really interested, we could run alternative implementations through a profiler to compare memory usage and performance. If we're going into that much detail, I'd like to try a Dictionary(Of MapCoordinate, List(Of Item)), where MapCoordinate is a Structure containing X and Y. But I'm not suggesting we should. ;)

My original point, however, was that we shouldn't allocate space for items if we're not going to use it. The same goes for allocating lists of items we're not using. There are usually many cells that simply can't hold items (like walls, or water), and it's wasteful to define an item container for such cells. That's why, in my opinion, a loot list (or a NPC list, for that matter) should be separated from the map itself.

24
Programming / Re: Celebration / Issue with loot
« on: November 06, 2010, 11:44:44 AM »
So from what I understand, lists are basically arrays, but somehow better? Because right now lootmap is a 3 dimensional array of the class item, which to me seems like it should be the same as a 3 dimensional list(of item), but apparently is not.

Lists are basically arrays, and they're not necessarily better, but they're dynamic. Arrays are very useful for handling fixed numbers of objects, but cumbersome for varying numbers of objects. It makes sense to implement a level map as a 2D array of tiles, because map dimensions are (usually) fixed. It may also make sense to implement the player's inventory as an array of items, for example if each inventory position is an item slot with a letter assigned to it, but you'll have to take into account that inventory positions may be empty (i.e. contain a NOITEM).

Implementing a loot map as a 3D array, even though it's logical, hardly makes sense.

The map's dimensions (80x25 for example) determine two dimensions of the loot map. The third dimension represents the maximum number of items per tile (let's say 3). If you define the loot map as a 3D array, it allocates 6000 item slots in memory. How many of these are going to be occupied by items? If you scatter 60 objects across the map, they only occupy 1% of the space that's allocated for them. On the other hand, if you want to drop more than three items in one map location, you can't. So a 3D array is a big waste of space in the first two dimensions, and too restricted in the third.

If the loot list is defined as a List(Of Item), the list grows as needed, so it doesn't waste space, and there's no need for NOITEM objects. The only problem is that you can't use map coordinates to find the loot at a given location. It's possible to create a 3D list - a List(Of List(Of List(Of Item))) - but many of the lists in the first two dimensions would be empty. A solution for the first two dimensions would be to use a Dictionary(Of TKey, TValue). A Dictionary is essentially a hash list, which uses keys in stead of indices. This way you can use the X and Y coordinates of map locations as hash keys for the loot list.

To make it more practical, encapsulate it in a LootList class:

Code: [Select]
Class LootList
    Inherits Object

    Private items As Dictionary(Of Integer, Dictionary(Of Integer, List(Of Item)))

    Public Sub New
        items = New Dictionary(Of Integer, Dictionary(Of Integer, List(Of Item)))
    End Sub

    ' Returns a list of items at map location (x, y), or Nothing if no items are there.
    Public Function GetItems(ByVal x As Integer, ByVal y As Integer) As List(Of Item)
        If items(x) Is Nothing Then
            Return Nothing
        Else
            Return items(x)(y)
        End If
    End

    ' Returns a single item at map location (x, y), or Nothing if no item is there.
    Public Function GetItem(ByVal x As Integer, ByVal y As Integer, ByVal z as Integer) As Item
        If items(x) Is Nothing Then
            Return Nothing
        Else If items(x)(y) Is Nothing Then
            Return Nothing
        Else If z < 0 OrElse z >= items(x)(y).Count Then
            Return Nothing
        Else
            Return items(x)(y)(z)
        End If
    End

    ' Puts an item on the loot map at location (x, y).
    Public Sub PutItem(ByVal x As Integer, ByVal y As Integer, ByVal item As Item)
        If items(x) Is Nothing Then items(x) = New Dictionary(Of Integer, List(Of Item))
        If items(x)(y) Is Nothing Then items(x)(y) = New List(Of Item)
        items(x)(y).Add(item)
    End Sub

    ' Removes an item from the map at location (x, y).
    Public Sub RemoveItem(ByVal x As Integer, ByVal y As Integer, ByVal z As Integer)
        If items(x) IsNot Nothing _
        AndAlso items(x)(y) IsNot Nothing _
        AndAlso z >= 0 AndAlso z < items(x)(y).Count Then
            Return items(x)(y).RemoveAt(z)
            If items(x)(y).Count = 0 Then items(x).Remove(y)
            If items(x).Count = 0 Then items.Remove(x)
        End If
    End Sub

End Class

No more NOITEMs, and a lot less looping. :)

25
Programming / Re: Celebration / Issue with loot
« on: November 04, 2010, 10:08:02 AM »
So what exactly does that do? I've seen it in a lot of projects, but never used it for a simple lack of knowledge.
Option Explicit requires explicit declaration of variables. Using a variable 'x' without a previous declaration 'Dim x' gives a compile time error. If you leave the option off, the compiler will silently assume that x is a newly declared variable whenever you use it (even if 'x' was a typo, and you meant to refer to an existing variable 'y', for example).

Option Strict prevents narrowing conversions (if you assign an Integer value to a variable of type Byte, it'll give a compile time error). If you leave this off, the conversion will take place, causing implicit data loss if the Integer value is greater than 255. If you turn it on, you'll have to remove unwanted implicit conversions, or write explicit conversions using CInt, CByte, CType, etc..

Option Infer allows the compiler to guess a variable's type from a value declaration. It makes 'Dim x = 3' a valid statement, and makes the compiler assume that x is an Integer (even if you meant it to be something else). If you turn it off, you'll have to state the type of every variable at declaration ('Dim x As Integer = 3').

Having Explicit On, Strict On, and Infer Off prevents potential declaration, conversion and type casting bugs before they can take place at run time.

Quote
Another thing I've seen around, but lack the knowledge of how to use.
List(of T) is a collection of any object type. If you define a loot list and an inventory list, you could more or less write the GetItem routine like this:

Code: [Select]
Public Class Item
    Inherits Object

    Public Property Name As String
    '(...)
End Class

Public Class InventoryList
    Inherits List(Of Item)
End Class

Public Class LootList
    Inherits List(Of Item)
End Class

Public Class Player
    Inherits Object

    Private inventory As InventoryList

    Public Sub New
       inventory = New InventoryList
       inventory.Capacity = 26
       '(...)
    End

    Public Sub GetItem(ByRef loot As LootList, ByVal i As Integer)
        If i < 0 OrElse i >= loot.Count Then
           Console.Write("Loot has no item at position " & i.ToString)
        Else If inventory.Count = inventory.Capacity Then
           Console.Write("No free inventory space")
        Else
            dim itemTaken As Item
            itemTaken = loot(i)
            inventory.Add(itemTaken)
            loot.RemoveAt(i)
            Console.Write("Picked up a " & itemTaken.Name)
        End If
    End Sub
End Class


Quote
I tried doing things like Is Nothing, or = NOITEM [My empty item], but it pulls up an error, and the way I'm doing now works fine for the time being at least
'Nothing' is assigned differently than it's tested. Assignment is 'x = Nothing' and test is 'If x Is Nothing'. It's a stupid language feature. The NOITEM thing you did isn't bad at all, but I think it's unnecessary if you use some kind of List object. If you stick to using NOITEM, then assign it to the LootMap in empty locations, and change
Code: [Select]
If Not LootMap(Player.Left, Player.Top, intloop).Name = "Nothing" Thento
Code: [Select]
If Not LootMap(Player.Left, Player.Top, intloop) = NOITEM Then

Quote
So you think I should make a seperate sub or function just to write that they picked up an item? I think putting it in with the sub that handles picking up items makes perfect sense
I think you should write a separate sub, but that's because I'd define some kind of MessageDisplay class to handle all messages. I could explain why I think that's a wise design decision, but unfortunately don't have time to do so right now. Writing messages when something happens makes sense, but it may become somewhat more difficult to maintain as the source code expands. (For example, consider having to change each Console.Write statement when you decide you want the messages to be displayed in a different color.)

Quote
Thanks! I've used vb6 a lot, but that's pretty outdated. And I haven't programmed period in a while either, so I figured starting a basic roguelike and improving on it as I go would be a good way to oil the gears, if you will.
VB.NET is quite different from VB6. It's more solidly object oriented, and of course it uses the .NET library. If you're not familiar with .NET, I'd suggest you read up on it. It's huge, both in its capabilities and its complexity, so it takes some time to find your way around, but after that it makes life a lot easier. ;)

26
Programming / Re: Celebration / Issue with loot
« on: November 03, 2010, 10:53:17 AM »
Shaggy:

I'm assuming you're using VB.NET. Some advice:

  • It's good practice to enable Option Strict, enable Option Explicit, and disable Option Infer. It's a chore to explicitly declare and initialize all variables, but it'll prevent a slew of hard to detect runtime bugs.
  • Like Übermann, I'd encourage you to use descriptive variable names and abide to coding conventions. In .NET, stick to lowerCamelCasing for variables and UpperCamelCasing for classes and methods; it's what everyone does.
  • .NET has terrific support for variable size collections, such as List(of T) or Dictionary(of TKey, TValue). If you use these, there's no need to check for absence of items from a loot list, or inventory slots with nothing in them.
  • If you have reason to ignore the previous point, just don't pull stunts like If Inventory(i).Description = "Empty space." or LootMap(...).Name = "Nothing". If you change the description/name of the 'empty' item, these tests will fail. It's safer to assign Nothing to an empty slot, and test for Inventory(i) Is Nothing or LootMap(...) Is Nothing. It's best not to have empty slots at all, though.
  • It's usually a good idea to separate 'model' code from 'view' code, i.e. separate the code that actually moves an item from the floor to the inventory, from the code that displays a message. In any case, don't display a message saying the player has picked up an item before the item is actually moved. If somehow the item can't be moved after all, the message is confusing.
Other than that I think .NET is a good choice for developing a roguelike. It'll help you create a game, in stead of winding up with the classic Yet Another Incredibly Abstracted Roguelike Library Only I Will Ever Use. ;)

27
Programming / Re: Looking for an ASCII artist...
« on: October 27, 2010, 02:09:46 PM »
You're not generating the ASCII art in run time, are you? ;)

All you need to do is draw your logo as a picture, then use a generator (once) to create the ASCII art.

After that, assign the result to a string constant in your code and display it from within your program.

If you want color, the easiest way is to use two string constants (one for the ASCII characters, and one for the color code of each character), and modify your display method to set the color before writing each char.

28
Programming / Re: need help with theory for nodes and adjacency lists
« on: June 07, 2010, 05:29:30 PM »
No problem. Good luck, and let us know if you got it to work.

Sorry about the formatting, it's just that these things are a nightmare to do in clear text.

Code: [Select]
S-a-b-d
   -c-e
   -d-b
     -T
 -c-a-b
     -d
   -e

Zoom it:

Code: [Select]
S-+-a-+-b---d
  |   |
  |   +-c---e
  |   |
  |   +-d-+-b
  |       |
  |       +-T
  |
  +-c-+-a-+-b
      |   |
      |   +-d
      |
      +-e

Kick and flip it:

Code: [Select]
      _____S______
      /            \
  ___a___           c
 /   |   \         / \
b   c     d       a   e
|   |    / \     / \
d   e   b   T   b   d

Doing this manually for a complete Angband level is left as an exercise for the reader. ;)

29
Programming / Re: need help with theory for nodes and adjacency lists
« on: June 07, 2010, 02:29:18 PM »
I don't think I understand your example. Just to be sure, I'd like to say that there is a difference between the map structure itself and the search space for pathfinding. The map structure can be a 2D array, a linked list, or anything which lets you determine adjacent locations. Building it should be fairly easy.

Once you have the map structure, you can construct a search space, which could be a tree. It's not necessary to put wall tiles in the search tree, since it's impossible for a character to move there. In your example, you would only need to build a tree containing [1,1] and [1,2], which isn't very clarifying.

Here's another example. I've marked the source (S) and target (T) locations, and all other 'floor' locations with letters, to avoid having to write coordinate pairs.

Code: [Select]
#####
#Sab#
#c#d#
#e#T#
#####

Allowing diagonal moves, an exhaustive BFS tree from S to T would be:

Code: [Select]
S-a-S*
   -b-a*
     -d-a*
       -b*
       -T
   -c-S*
     -a*
     -e-c*
   -d-a*
     -b-a*
       -d*
     -T
 -c-S*
   -a-S*
     -b-a*
       -d-a*
         -b*
         -T
     -c*
     -d-a*
       -b-a*
         -d*
       -T
   -e-c*

I.e. from S, you can move to a and c; from a, you can move to S, b, c, or d; from c, you can move to S, a, or e; and so on. Nodes marked with an asterisk are loops, i.e. the leaf node is equal to one of its superior nodes. You don't have to add these to the search tree. Omitting the loops leaves you with:

Code: [Select]
S-a-b-d-T
   -c-e
   -d-b
     -T
 -c-a-b-d-T
     -d-b
       -T
   -e

There's also no need to build the tree exhaustively. You can stop building the tree if T was added as a leaf node in the last iteration. In this case the depth of the tree is equal to the length of the path, so all shortest paths must be known. In this case, T is added after the fourth iteration:

Code: [Select]
S-a-b-d
   -c-e
   -d-b
     -T <--
 -c-a-b
     -d
   -e

In this example, there's just one shortest path:

Code: [Select]
S-a-d-T

I'm still not sure if this is what you're looking for, but I hope it helps.

30
Programming / Re: need help with theory for nodes and adjacency lists
« on: June 07, 2010, 10:10:33 AM »
Hi Conal,

You're trying to implement BFS for pathfinding on a 2D map, right?

It's probably easier to use a general N-ary tree in stead of a binary tree for search space, since a node (=location) can have up to eight child nodes (=neighbouring locations). To build the tree, add the source location as the root node, then add its neighbours as child nodes. For each leaf node, add its neighbours as child nodes, skipping nodes that already appear as a superior node (these represent loops). Keep adding tiers to the tree until the last tier contains at least one leaf representing the target location ('target node'). Any path from the root node to any target node is a shortest path. Pick a random target node, and backtrace to the root node to get the path.

If that's what you're trying to do, and if I'm not making some stupid mistake. ;)

Pages: 1 [2] 3 4 ... 6