Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 70 71 [72]

Author Topic: The Roguelike Development Megathread  (Read 238806 times)

Adragis

  • Bay Watcher
  • Edgelady Supreme
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1065 on: December 22, 2016, 02:44:12 pm »


That's just the bit of the code that places monsters, just to show how defining them works.
Logged
thincake

Skyrunner

  • Bay Watcher
  • ?!?!
    • View Profile
    • Portfolio
Re: The Roguelike Development Megathread
« Reply #1066 on: December 22, 2016, 04:09:19 pm »


That's just the bit of the code that places monsters, just to show how defining them works.

You'd definitely want to put all the info like HP range, defense range, power, xp etc into a lookup table to make it look less messy.
Logged

bay12 lower boards IRC:irc.darkmyst.org @ #bay12lb
"Oh, they never lie. They dissemble, evade, prevaricate, confoud, confuse, distract, obscure, subtly misrepresent and willfully misunderstand with what often appears to be a positively gleeful relish ... but they never lie" -- Look To Windward

RoguelikeRazuka

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1067 on: December 19, 2017, 04:29:55 pm »

Finally, after having played roguelikes for more than 3 years I (naively) consider myself competent enough to start making my own roguelike game, and currently I can't decide whether I should use C++ or Python (C# is also fine) to code that thing (I have a fair bit of programming experience with both languages, even if I don't know something it shouldn't be much of a problem to get better at either as I work on the roguelike of my dream). What I basically need is an OO language and a library/framework/game engine offering convenient tools for representing game objects as text characters, but it would also be great to have the possibility to transition to tiles with as little effort as possible, so I don't think it's a good idea to use libraries like libtcod with limited 2D sprite graphics support (to my knowledge) or even libraries like curses designed to perform manipulations with text characters in a console window.

So, what would you suggest?


PS I'm sorry for necroing in advance, but since this thread hasn't been closed by this point, I think it's allright to post here.
« Last Edit: December 21, 2017, 04:10:06 am by RoguelikeRazuka »
Logged

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1068 on: December 20, 2017, 05:18:17 pm »

Have you thought of just making it in a game engine like Unity or Unreal Engine 4? Unity "kind of" uses a c# derivative, while UE has a fairly quick back-end for compiled code.

Mostly because there's quite a few "starter kits" available on their respective stores for making roguelikes, so they may give you the jump-start you need to get the project actually going. They may also be a bit too generic for your liking, or make you feel like you're learning "that" framework, rather than actual pure coding though. It may make it harder to grab code snippets from around the place to insert into your project too (although, you'll really know what they're doing by the time you've got the code going in either engine).

Unfortunately I can't say if any of them are any good, but getting something started is one of the biggest hurdles, and this may ease that process.

(don't worry about necroing. It's what we do, and this is the right thread for your questions, so necro away :) )
« Last Edit: December 20, 2017, 05:21:42 pm by sambojin »
Logged
It's a game. Have fun.

EnigmaticHat

  • Bay Watcher
  • I vibrate, I die, I vibrate again
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1069 on: December 21, 2017, 01:22:36 am »

From experience: don't use python.  Python code runs slower than C# by a lot.  Roguelikes involve a lot of processor intensive stuff.  Level generation, pathfinding, line of sight.  With proper optimization you certainly could write a roguelike in Python, but you might miss that extra speed a lot.  Never know what you might try to do down the line.

Edit: I don't have an opinion on platform.  Unity is good in general but I don't know if its the easiest way to make simple 2D graphics.  I made a fake console for roguelikes (as in, it would print text to the screen, but it was just drawing sprites) in... I think, Monodevelop?  Whatever it was its pretty much obsolete because everyone moved on to Unity and Unreal Engine.
« Last Edit: December 21, 2017, 01:27:04 am by EnigmaticHat »
Logged
"T-take this non-euclidean geometry, h-humanity-baka. I m-made it, but not because I l-li-l-like you or anything! I just felt s-sorry for you, b-baka."
You misspelled seance.  Are possessing Draignean?  Are you actually a ghost in the shell? You have to tell us if you are, that's the rule

RoguelikeRazuka

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1070 on: December 21, 2017, 04:24:48 am »

No, I don't want Unity or UE4 -- they seem a bit overkill-ish for my goals (for I don't aim at producing serious shit intended for sale at the moment). I was thinking about using libraries like SDL or SFML or maybe a 2D engine like oxygene, but maybe there are better options, especially if I'm not using C++.
« Last Edit: December 21, 2017, 04:42:36 am by RoguelikeRazuka »
Logged

Mephisto

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1071 on: December 21, 2017, 07:56:22 am »

From experience: don't use python.  Python code runs slower than C# by a lot.  Roguelikes involve a lot of processor intensive stuff.  Level generation, pathfinding, line of sight.  With proper optimization you certainly could write a roguelike in Python, but you might miss that extra speed a lot.  Never know what you might try to do down the line.

Also speaking from experience, it really doesn't matter. This guy has admitted that "my code is rarely very elegant (since I don’t come from a Computer Science background)" and he doesn't appear to be having any of those problems.
Logged

FallacyofUrist

  • Bay Watcher
  • Blatant furry. Also a hypnotist.
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1072 on: December 21, 2017, 09:59:54 am »

I've been interested in producing a roguelike for a long while, and there's something I want to know...

How do pathfinding algorithms work? And sight algorithms? This is driving me batty. Mad as a hatter. Whatever.
Logged
Generic Arms Race.

Would you like to play a game of Mafia? The subforum is always open to new players.

Sergius

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1073 on: December 21, 2017, 10:09:13 am »

Pathfinding is usually some variation of A*, which is a type of search algorithm. Probably Googling it will turn up something better than my limited knowledge of it.

Here's a cool site about line-of-sight algorithms and explanation: https://www.redblobgames.com/articles/visibility/

EDIT: Same site with some pathfinding: https://www.redblobgames.com/pathfinding/a-star/introduction.html
« Last Edit: December 21, 2017, 10:11:06 am by Sergius »
Logged

Retropunch

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1074 on: December 21, 2017, 12:15:49 pm »

I've been interested in producing a roguelike for a long while, and there's something I want to know...

How do pathfinding algorithms work? And sight algorithms? This is driving me batty. Mad as a hatter. Whatever.

Have you gone through the roguebasin Python/C# + libtcod tutorial? That has some stuff on pathfinding - it doesn't go into the technicalities in depth, but it's the best way to get a RL up and working quickly
Logged
With enough work and polish, it could have been a forgettable flash game on Kongregate.

EnigmaticHat

  • Bay Watcher
  • I vibrate, I die, I vibrate again
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1075 on: December 21, 2017, 02:37:51 pm »

I've been interested in producing a roguelike for a long while, and there's something I want to know...

How do pathfinding algorithms work? And sight algorithms? This is driving me batty. Mad as a hatter. Whatever.
Line of sight you do via rays, AKA a continuous line along which you check every point until it hits something.  At the end of level generation mark every tile unexplored.  Then every time you want to recalculate line of sight, mark every tile as unseen and send out rays in every direction.  Every time a ray crosses over a tile, mark it as seen AND explored.  If that ray hits a LoS blocker, like a wall, end the ray (although still mark the wall as visible).  You don't need to calculate LoS to creatures, you just need to calculate it to the tiles the creatures are standing on.

Alternately, you could go with a simpler route.  Either make everything on-camera visible and lock camera movement, or divide your level up into rooms and let the player see everything in any room they're standing in.  Honestly tho LoS is simple enough that you shouldn't need to cheat like that.

I'd highly recommend only calculating LoS for the player.  Assume any creature the player can see can see them, and any creature out of sight can't see the player.  It lines up with how most players will intuitively think LoS works, and its soooo much more efficient than checking each creature's LoS.

A* pathfinding is a bit harder than LoS.  For the first time you implement I'd honestly recommend just following a guide word for word and learning that way.  That should be easier than trying to understand the entire process before you start. 
Logged
"T-take this non-euclidean geometry, h-humanity-baka. I m-made it, but not because I l-li-l-like you or anything! I just felt s-sorry for you, b-baka."
You misspelled seance.  Are possessing Draignean?  Are you actually a ghost in the shell? You have to tell us if you are, that's the rule

Retropunch

  • Bay Watcher
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1076 on: December 24, 2017, 09:39:17 am »


I'd highly recommend only calculating LoS for the player.  Assume any creature the player can see can see them, and any creature out of sight can't see the player.  It lines up with how most players will intuitively think LoS works, and its soooo much more efficient than checking each creature's LoS.

A* pathfinding is a bit harder than LoS.  For the first time you implement I'd honestly recommend just following a guide word for word and learning that way.  That should be easier than trying to understand the entire process before you start.

Definitely agree with both of these - unless you're building some sort of mechanic around it, ALWAYS assume that all LoS is based on the player. It gets confusing and feels unfair if creatures can see you and you can't see them. I tried to do this in an early RL I did a quick mock up of and it just didn't work.

Definitely use a library for A* and just follow the libtcod tutorial on it - it's not worth doing anything more until you need it.
Logged
With enough work and polish, it could have been a forgettable flash game on Kongregate.

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1077 on: December 24, 2017, 03:35:41 pm »

Two way LoS can work in some cases. In DoomRL it turned from an exploit, to an essential part of gameplay, with character traits on levelling to exploit it even more.

If you do want a less CPU intensive style, but with some depth to it still, just add ranges for different environments/creature types. Say the player has 15 squares of vision during daytime and an enemy only has 10, the player will see the creature at 12 squares, but the creature's attack AI won't be triggered until you get within ten of it. Swap them around for nighttime.

Basically you do normal one-way LoS out to about 20 squares, but with all objects having a seen/not seen Boolean tag that gets altered by the player's actual vision distance. Tiles only get updated in UI if seen=true, even though it's actually calculating tiles out to a further range for AI checking. Creatures just get tagged as seeing/unseeing you to trigger various behaviors, depending on distance to player and their vision stat in that environment, with LoS=true/false based off the player's "extended" vision of 20. You can make it more complicated if you'd like....

Not the greatest explanation, but it adds quite a bit of complexity to vision, and can add all kinds of peculiar quirks to different enemies, and even player races. Living/robotic, day/night, particularly good against certain enemies, etc, and it gives you another layer of itemization to play with as well. Not bad for a couple of tags or values added to each enemy, jumped off the core one-way vision system.

I'm mainly just saying that one-way player-centric LoS calcs don't necessarily mean simple or without significant gameplay or design options to it.
« Last Edit: December 24, 2017, 03:50:14 pm by sambojin »
Logged
It's a game. Have fun.

EnigmaticHat

  • Bay Watcher
  • I vibrate, I die, I vibrate again
    • View Profile
Re: The Roguelike Development Megathread
« Reply #1078 on: December 24, 2017, 07:38:04 pm »

There’s only one reason you would need to understand how A* works: if you want to change the heuristic.  That’s the guide the computer uses to guess which tiles are closest to the objective.  You can do things like set a trap’s pathing cost to 600 times a standard tile.  Thus the computer won’t even try to make a path over the trap unless its the only way through.
Logged
"T-take this non-euclidean geometry, h-humanity-baka. I m-made it, but not because I l-li-l-like you or anything! I just felt s-sorry for you, b-baka."
You misspelled seance.  Are possessing Draignean?  Are you actually a ghost in the shell? You have to tell us if you are, that's the rule
Pages: 1 ... 70 71 [72]