76
Other Announcements / Re: A simple roguelike?
« on: October 01, 2009, 07:02:18 PM »
I think he means 'persistent within the game', and not the Angband style where the level is regenerated when you leave and come back.
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.
77
Other Announcements / Re: Scallywag: In the Lair of the Medusa---to buy?
« on: March 16, 2009, 03:09:06 PM »
Ooo.....tough call....
One on hand, there are tons of free, well-crafted rogues out there.
On the other, we really need to support these efforts monetarily. If the production values are decent, then they had to spend some money to get the product out the door.
But back on the other hand...it would take a really slick game to get $$ out of me what with a mortgage and a wife who sees this as a frivolous expenditure.
At the end of the day, I would wait for a review, or try and ask someone who has played it what they thought, which admittedly may be tough with low-profile games. I still refuse to pay for certain roguelike games currently out there (and I won't bash them by name, but some people probably know what I'm talking about), as it seems like almost an ethical consideration given the nature of the roguelike genre. For example, I like how the author or Legerdemain has marketted his game - free to play, but strategy for pay.
Tough call....
One on hand, there are tons of free, well-crafted rogues out there.
On the other, we really need to support these efforts monetarily. If the production values are decent, then they had to spend some money to get the product out the door.
But back on the other hand...it would take a really slick game to get $$ out of me what with a mortgage and a wife who sees this as a frivolous expenditure.
At the end of the day, I would wait for a review, or try and ask someone who has played it what they thought, which admittedly may be tough with low-profile games. I still refuse to pay for certain roguelike games currently out there (and I won't bash them by name, but some people probably know what I'm talking about), as it seems like almost an ethical consideration given the nature of the roguelike genre. For example, I like how the author or Legerdemain has marketted his game - free to play, but strategy for pay.
Tough call....
78
Programming / Re: Adventures of Da'lar
« on: October 20, 2008, 11:39:33 AM »
So, when do we get some code?!? Looks great!
79
Off-topic (Locked) / Re: Realtime Roguelike
« on: October 08, 2008, 02:22:13 PM »
I think it's a good idea, and have been toying with this a while. My roguelike is fairly simple to play (being designed so that 1 key press = 1 action - I HATE Angbands 5+ keypresses to cast and target a spell, even with macro support), and uses autotargetting, so just adding a timer to continously run the main loop seems to actually work. However, there are 2 (non-programming) gameplay issues that come up that probably need to be addressed in a non-3D (quasi/isometric/whatever) roguelike you make in real time. Well, really the problem has to do with the roguelike convention that you use a grid. Maybe someone has some thoughts on a possible workaround??
If you try real-time in a 2-D/grid-based rogue (meaning the granularity is lousy - there's no 'partially' between locations), the main problem seems to be player input. If you allow the player to act every time they press a key, their keypresses may be much faster than the monsters act/main-loop processes (unless your main loop is really fast, in which case the player gets massacred) - in essence, the player gets lots of free turns compared to the monsters, or vice versa. Conversely, you can have the players LAST input get acted on each game cycle, which in it's self leads to 2 problems -1) Multiple keypresses between turns get ignored, leading to unresponsive controls, or if you're fast, the ability to correct your key presses before the next main loop cycle, or 2) If you process the entire keypress buffer, you get long periods of real time where the character has to 'act-out' everything that was pressed, leading to the inability to react in real-time.
I must admit, I have't found a satisfactory way to deal with this issue. The best I can come up with is to put it as fast as I can, and try and 'tune' the monster speeds so that they are similar to the players.
Any thoughts on how you could make it work simply from a timing/input perspective??
If you try real-time in a 2-D/grid-based rogue (meaning the granularity is lousy - there's no 'partially' between locations), the main problem seems to be player input. If you allow the player to act every time they press a key, their keypresses may be much faster than the monsters act/main-loop processes (unless your main loop is really fast, in which case the player gets massacred) - in essence, the player gets lots of free turns compared to the monsters, or vice versa. Conversely, you can have the players LAST input get acted on each game cycle, which in it's self leads to 2 problems -1) Multiple keypresses between turns get ignored, leading to unresponsive controls, or if you're fast, the ability to correct your key presses before the next main loop cycle, or 2) If you process the entire keypress buffer, you get long periods of real time where the character has to 'act-out' everything that was pressed, leading to the inability to react in real-time.
I must admit, I have't found a satisfactory way to deal with this issue. The best I can come up with is to put it as fast as I can, and try and 'tune' the monster speeds so that they are similar to the players.
Any thoughts on how you could make it work simply from a timing/input perspective??
80
Programming / Re: Adventures of Da'lar
« on: October 08, 2008, 02:08:42 PM »
Your title screenshot looks pretty damn cool. I am looking for to playing a (good) multiplayer roguelike, so I will be following your development quite closely! If you can actually pull this off, I think you could have a game that ranks up with the big 4 rogues.
81
Other Announcements / Re: Need help find a rougelike game
« on: October 03, 2008, 12:22:13 PM »
Incursion is pretty cool. There are a few wonky design choices (I'm really not a big fan of the inventory decision to be 'holding' an object, and forced to swap it with whatever you are equipping), but other than than it is quite cool. Character customization is immensely deep, with a really good implementation of the D&D3 (maybe 3.5?) ruleset. A few thing were changed to make them work in a roguelike, but they were good changes.
I have to admit to not being very good at it - it seems quite hard to me, and I have ascended a few characters in Nethack. I definitely applaud the creator - he has done a great job, and deserves a lot of credit.
As Corremn mentioned, Crawl Stone Soup is good too. I find it a little bit dried than most rogues (well, anything is after being tainted by Nethacks goofy gameplay). The playstyle is a little like Angband, in that it's more aimed at combat than anything else, and it does this really well.
I have to admit to not being very good at it - it seems quite hard to me, and I have ascended a few characters in Nethack. I definitely applaud the creator - he has done a great job, and deserves a lot of credit.
As Corremn mentioned, Crawl Stone Soup is good too. I find it a little bit dried than most rogues (well, anything is after being tainted by Nethacks goofy gameplay). The playstyle is a little like Angband, in that it's more aimed at combat than anything else, and it does this really well.
82
Temple of the Roguelike / Re: Send your banners!
« on: July 30, 2008, 05:23:33 PM »
I would also like to submit banner, too, if still possible. I've attached it as a PNG. Pointing to:
http://lordsofdarkhall.weebly.com/
Thank you for the publicity. I have links to 2 of your pages on my front page as well (RogueTemple and Slashie.net).
http://lordsofdarkhall.weebly.com/
Thank you for the publicity. I have links to 2 of your pages on my front page as well (RogueTemple and Slashie.net).
83
Programming / Re: Need help to implement a Line-of-Sight algorithm for a roguelike in VB6
« on: July 30, 2008, 04:53:35 PM »
Oh, and if you are interested in what I came up with (keep in mind I'm an amateur too, so be gentle!!), this is a cut/paste of the entirety of my Line-of-sight code:
variables:
intCurrentX and intCurrentY are the players current coordinates
intCurrentVisualRange is the distance you can see (as a radius)
I have a function called (Passable(X1, Y1) as Boolean) which simple returns True/False based on whether you can see/move through the square or not, and I also wrote a little distance calculating function (Distance(X1, Y1, X2, Y2) as single).
I try to keep my code fairly readable, as being an amateur I often have to refigure my logic months later when I am changing something.
'LINE OF SIGHT
'first, show everything in the light radius (and later subtract out what can't be seen)
For intXCounter = (intCurrentX - intCurrentVisualRange) To (intCurrentX + intCurrentVisualRange)
For intYCounter = (intCurrentY - intCurrentVisualRange) To (intCurrentY + intCurrentVisualRange)
'make sure you don't calcualte off the edge of the map
If (intXCounter > 0) And (intXCounter < MAX_MAP_DIMENSION + 1) And (intYCounter > 0) And (intYCounter < MAX_MAP_DIMENSION + 1) Then
If Distance(intCurrentX, intCurrentY, intXCounter, intYCounter) < intCurrentVisualRange Then
With Tile(intCurrentLevel, intXCounter, intYCounter)
If .TileType <> STONE Then .Visible = True
End With
End If
End If
Next intYCounter
Next intXCounter
'next, blank out squares which are blocked by .Passable = false tiles
'the 8 tiles nearest the player are always visible, so don't change them
For intCounter = 1 To intCurrentVisualRange
For intSectionCounter = 0 To intCounter
If Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY + intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY + intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY + intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY + intSectionCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY + intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY + intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY + intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY + intSectionCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY - intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY - intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY - intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY - intSectionCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY - intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY - intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY - intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY - intSectionCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter + 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter + 1, intCurrentY + intCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter + 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter - 1, intCurrentY + intCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter - 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter + 1, intCurrentY - intCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter - 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter - 1, intCurrentY - intCounter - 1).Visible = False
End If
Next intSectionCounter
Next intCounter
And that's it. As you can see, I make everything in the view radius visible first, and then blank out blocked squares manually. For small view radii (under 10), it works great. Larger radii seem to produce some anomalies due to me forcing 45 degree checks on light from each square. (My code doesn't look at shallower angles and block vision if a tiny piece of a blocked square impedes vision.) It's a bit bulky and brute force, and not flexible at all, but it works. I wish I was good enough to come up with something small and efficient, but for my skill level I am happy.
variables:
intCurrentX and intCurrentY are the players current coordinates
intCurrentVisualRange is the distance you can see (as a radius)
I have a function called (Passable(X1, Y1) as Boolean) which simple returns True/False based on whether you can see/move through the square or not, and I also wrote a little distance calculating function (Distance(X1, Y1, X2, Y2) as single).
I try to keep my code fairly readable, as being an amateur I often have to refigure my logic months later when I am changing something.
'LINE OF SIGHT
'first, show everything in the light radius (and later subtract out what can't be seen)
For intXCounter = (intCurrentX - intCurrentVisualRange) To (intCurrentX + intCurrentVisualRange)
For intYCounter = (intCurrentY - intCurrentVisualRange) To (intCurrentY + intCurrentVisualRange)
'make sure you don't calcualte off the edge of the map
If (intXCounter > 0) And (intXCounter < MAX_MAP_DIMENSION + 1) And (intYCounter > 0) And (intYCounter < MAX_MAP_DIMENSION + 1) Then
If Distance(intCurrentX, intCurrentY, intXCounter, intYCounter) < intCurrentVisualRange Then
With Tile(intCurrentLevel, intXCounter, intYCounter)
If .TileType <> STONE Then .Visible = True
End With
End If
End If
Next intYCounter
Next intXCounter
'next, blank out squares which are blocked by .Passable = false tiles
'the 8 tiles nearest the player are always visible, so don't change them
For intCounter = 1 To intCurrentVisualRange
For intSectionCounter = 0 To intCounter
If Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY + intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY + intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY + intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY + intSectionCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY + intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY + intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY + intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY + intSectionCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY - intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intCounter, intCurrentY - intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY - intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intCounter + 1, intCurrentY - intSectionCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY - intSectionCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intCounter, intCurrentY - intSectionCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY - intSectionCounter).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intCounter - 1, intCurrentY - intSectionCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY + intCounter + 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter + 1, intCurrentY + intCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY + intCounter + 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter - 1, intCurrentY + intCounter + 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter, intCurrentY - intCounter - 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX + intSectionCounter + 1, intCurrentY - intCounter - 1).Visible = False
End If
If Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter).Passable = False Or Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter).Visible = False Then
If intSectionCounter <> intCounter Or intCounter = 1 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter, intCurrentY - intCounter - 1).Visible = False
If intSectionCounter > 0 Then Tile(intCurrentLevel, intCurrentX - intSectionCounter - 1, intCurrentY - intCounter - 1).Visible = False
End If
Next intSectionCounter
Next intCounter
And that's it. As you can see, I make everything in the view radius visible first, and then blank out blocked squares manually. For small view radii (under 10), it works great. Larger radii seem to produce some anomalies due to me forcing 45 degree checks on light from each square. (My code doesn't look at shallower angles and block vision if a tiny piece of a blocked square impedes vision.) It's a bit bulky and brute force, and not flexible at all, but it works. I wish I was good enough to come up with something small and efficient, but for my skill level I am happy.
84
Programming / Re: Need help to implement a Line-of-Sight algorithm for a roguelike in VB6
« on: July 30, 2008, 04:34:25 PM »
I'm programming my roguelike in VB as well, and struggled with an effective LOS algorithm as you are. I eventually came to 2 conclusions that had a huge impact on program performance:
Conclusion 1) The algorithm - I beat myself to death on how to implement this for a long time. I browsed a bunch of sites that descrbed how they implemented it, including the files at roguebasin and dungeondweller, and pleaded (pled?? /shrug) for help at rgrd,. After several false starts, I initially settled on a rather elegant (at least to me) piece of code with calculated line of sight in a spiral out from the player. However.... this tended to actually NOT be the fastest way to do it, and it had the side effect of calculating some squares rather questionably at long distances. So, I tried other methods, including ray casting, and a weird flood-fill one. In the end, I chose a brute force method, which, while laughable looking at it in the code, actually improved my performance considerably at the cost of having to use bulkier (but faster) code.
What I did was simply divide the players field of view up into 8 octants (or 4 quarters if you're so inclined), and hard-code the view algorithm in that little piece of the pie for each square. Checking LOS on the other octants was simply a matter of flipping the sign on one of the coordinates. And it ended up working wonderfully. I was quite pleased with it.
I am far from an expert programmer (I even stress the definition of intermediate), but if I have learned 1 thing, it's that having an elegant, optimized algorithm is not always the best way to do something. I started this program wanting it to be compact, beautiful code, with no chunks of if-then blocks repeating when a single algorithm would work. Sometimes, brute force code can produce a better result - brute force code ensures you get exactly what you want, whereas an algortihm saves you coding work, but may not work exactly as you like in all cases.
Conclusion 2) I don't know how 'realistic' you want your code to be, but I made one other decision that DRASTICALLY affected performance. ONLY calculate LOS for the player, unless you are trying to create a pretty advanced AI for your monsters. Let's face it...the old saying 'If I can't see you, then you can't see me' holds very true for a game which is represented in a rather coarse, non-granular grid format. If I can't see that goblin behind a piller, then he can't see me either, so there is absolutely NO need to recalculate LOS on that monster.
I did actually start calculating LOS on every single creature in the game on every turn that passed. Performance was abyssmal. I reduced it only to 'active/awake' creature. Performance improved, but was still pretty bad. In addition, I ran into problems with creatures simply not responding when you came into sight. Tried to work around it with an altered algorithm which only calculated LOS on creatures within a certain distance of the player (yet another calculation). This was more realistic, but I ended up with monsters which 'went to sleep' when they left range.
In the end, I simply calculate 1 LOS for the player, and MAYBE 1 for each of the players pets/allies. It exponentially improves performance, and ranged combat works absolutely fine.
Your mileage will vary on these ideas, and I am probably regurgitating what every good programmer on this site already knows (and there seem to be a lot of good programmers here), but they are 2 of the bigger problems I faced and eventually overcame. If you are going for absolute realism (well, as realistic as a fantasy/sci-fi game can be), then my ideas are pretty much useless to you.
Sorry so long winded. I'm on lunch break and reading some forums for some ideas myself, and thought I'd drop a thing or 2 I've learned during my programming crash-course!
Brigand
Conclusion 1) The algorithm - I beat myself to death on how to implement this for a long time. I browsed a bunch of sites that descrbed how they implemented it, including the files at roguebasin and dungeondweller, and pleaded (pled?? /shrug) for help at rgrd,. After several false starts, I initially settled on a rather elegant (at least to me) piece of code with calculated line of sight in a spiral out from the player. However.... this tended to actually NOT be the fastest way to do it, and it had the side effect of calculating some squares rather questionably at long distances. So, I tried other methods, including ray casting, and a weird flood-fill one. In the end, I chose a brute force method, which, while laughable looking at it in the code, actually improved my performance considerably at the cost of having to use bulkier (but faster) code.
What I did was simply divide the players field of view up into 8 octants (or 4 quarters if you're so inclined), and hard-code the view algorithm in that little piece of the pie for each square. Checking LOS on the other octants was simply a matter of flipping the sign on one of the coordinates. And it ended up working wonderfully. I was quite pleased with it.
I am far from an expert programmer (I even stress the definition of intermediate), but if I have learned 1 thing, it's that having an elegant, optimized algorithm is not always the best way to do something. I started this program wanting it to be compact, beautiful code, with no chunks of if-then blocks repeating when a single algorithm would work. Sometimes, brute force code can produce a better result - brute force code ensures you get exactly what you want, whereas an algortihm saves you coding work, but may not work exactly as you like in all cases.
Conclusion 2) I don't know how 'realistic' you want your code to be, but I made one other decision that DRASTICALLY affected performance. ONLY calculate LOS for the player, unless you are trying to create a pretty advanced AI for your monsters. Let's face it...the old saying 'If I can't see you, then you can't see me' holds very true for a game which is represented in a rather coarse, non-granular grid format. If I can't see that goblin behind a piller, then he can't see me either, so there is absolutely NO need to recalculate LOS on that monster.
I did actually start calculating LOS on every single creature in the game on every turn that passed. Performance was abyssmal. I reduced it only to 'active/awake' creature. Performance improved, but was still pretty bad. In addition, I ran into problems with creatures simply not responding when you came into sight. Tried to work around it with an altered algorithm which only calculated LOS on creatures within a certain distance of the player (yet another calculation). This was more realistic, but I ended up with monsters which 'went to sleep' when they left range.
In the end, I simply calculate 1 LOS for the player, and MAYBE 1 for each of the players pets/allies. It exponentially improves performance, and ranged combat works absolutely fine.
Your mileage will vary on these ideas, and I am probably regurgitating what every good programmer on this site already knows (and there seem to be a lot of good programmers here), but they are 2 of the bigger problems I faced and eventually overcame. If you are going for absolute realism (well, as realistic as a fantasy/sci-fi game can be), then my ideas are pretty much useless to you.
Sorry so long winded. I'm on lunch break and reading some forums for some ideas myself, and thought I'd drop a thing or 2 I've learned during my programming crash-course!
Brigand
85
Early Dev / Re: Mage Guild
« on: July 28, 2008, 06:37:48 PM »
Pretty cool little game! I haven't gotten very far, but it has been fun experimenting with the different commands/items. Interesting dungeon generation algorithm, too. Would be curious to see the code.
86
Programming / Re: Testing request, cryptrover 1.1 release candidate.
« on: July 28, 2008, 06:29:26 PM »
The non-music and sound version must still have a reference to the SDL.dll; no dice on running it. I'm at work, so I can't really try out the other version. I'll give it a spin later when I get home.
87
Programming / Re: Testing request, cryptrover 1.1 release candidate.
« on: July 28, 2008, 02:43:59 AM »
Will be happy to give it a try if you'll make a binary - don't have the resources to compile it myself.
88
Traditional Roguelikes (Turn-based) / Re: Lords of Darkhall
« on: July 08, 2008, 08:26:18 PM »
redacted
89
Traditional Roguelikes (Turn-based) / Re: Lords of Darkhall
« on: November 28, 2007, 01:49:39 PM »
That's really strange; I did a little research last night and found that the error is indeed a VB6 DLL error. Somehow something on your system must have gotten renamed, or moved. This is a short version of what I found:
"f you get the error 'Runtime error 50003. Unexpected error' after trying to run the new version, you will need to upgrade the file tabctl32.ocx. This file normally resides in your Windows\System directory. Search your computer for this file and download the file to the directory where the file exists replacing the current file. "
It may or may not be specifically tabctl32.ocx(dll); more likely it's Comctl32.ocx or Comdlg32.ocx, as I am pretty sure I use those in my program.
Hope this helps!
"f you get the error 'Runtime error 50003. Unexpected error' after trying to run the new version, you will need to upgrade the file tabctl32.ocx. This file normally resides in your Windows\System directory. Search your computer for this file and download the file to the directory where the file exists replacing the current file. "
It may or may not be specifically tabctl32.ocx(dll); more likely it's Comctl32.ocx or Comdlg32.ocx, as I am pretty sure I use those in my program.
Hope this helps!
90
Traditional Roguelikes (Turn-based) / Re: Lords of Darkhall
« on: November 27, 2007, 08:05:51 PM »All is good, but message "Run-time error '50003': Unexpected error" pops up right after the splash screen, and then program shuts down.
Hmmm....never seen this before....What OS are you using?? Anything older than Windows 2000 (maybe 98) might need a download of the common VB dlls (like the common dialog box); most of this stuff is included automatically in Windows these days. I'll put up a standard SetUp.exe program that also installs these automatically if they aren't included (they are very small, and easily deletable if you don't want them on your system.)