How difficult would it be for me to make a roguelike?
closed account (Ly59GNh0)
We recently had an assignment at school to create a Diablo clone in the console window with text only. I had lots of fun with it and now have an urge to try my hands at making a roguelike.
The problem is that I have yet to learn how to program for anything other than the console.
So my question is simply how difficult it is to learn how to create something using ASCII graphics. Do I need to use that standard 2D library or is it done in some other way? I have no idea where to start, really.
The problem is that I have yet to learn how to program for anything other than the console.
So my question is simply how difficult it is to learn how to create something using ASCII graphics. Do I need to use that standard 2D library or is it done in some other way? I have no idea where to start, really.
How exactly did you create a Diablo clone in the console window with text only?
Creating a real roguelike will require something other than the standard C++ console capabilities, likely the native OS console functions, or nCurses if you're working on a unix based OS like Linux.
Many of the existing roguelikes make the source-code freely available, so you are free to look at those sources and see how they implemented stuff. Most are written in C, no C++.
Creating a real roguelike will require something other than the standard C++ console capabilities, likely the native OS console functions, or nCurses if you're working on a unix based OS like Linux.
Many of the existing roguelikes make the source-code freely available, so you are free to look at those sources and see how they implemented stuff. Most are written in C, no C++.
closed account (Ly59GNh0)
Basically the Diablo clone is supposed to eventually evolve into a game with all the features of an AAA-RPG-title, only without graphics.
What has been done so far is just rooms, doors, chests, items and monsters. You enter a room, you get a list of items in the room, how many chests there are and if there are monsters inside.
Obviously it's extremely basic, but it still feels as if just layering ASCII-graphics wouldn't be too difficult, if only I had any idea where to start and what new tools I'd have to learn.
What has been done so far is just rooms, doors, chests, items and monsters. You enter a room, you get a list of items in the room, how many chests there are and if there are monsters inside.
Obviously it's extremely basic, but it still feels as if just layering ASCII-graphics wouldn't be too difficult, if only I had any idea where to start and what new tools I'd have to learn.
^Heh, sounds like a MUD.
With just ASCII art I don't think you would need a 2D graphics lib, those are mainly for stuff like say FF1, not ASCII stuff.
If you want to refresh the screen a lot (e.g. printing a lot of stuff and just shove the old map off the screen), then you probably won't need a lot of special tools, but if you want to overwrite stuff (e.g. just the player or a specific (x,y)) then you would need something like ncurses.
With just ASCII art I don't think you would need a 2D graphics lib, those are mainly for stuff like say FF1, not ASCII stuff.
If you want to refresh the screen a lot (e.g. printing a lot of stuff and just shove the old map off the screen), then you probably won't need a lot of special tools, but if you want to overwrite stuff (e.g. just the player or a specific (x,y)) then you would need something like ncurses.
| Obviously it's extremely basic, but it still feels as if just layering ASCII-graphics wouldn't be too difficult, if only I had any idea where to start and what new tools I'd have to learn. |
The transition to 2D ASCII graphics adds a number of complications from a MUD-like that you should be aware of. Aside from the display requirements themselves (which would be easier using the ncurses library, but that isn't available on Windows platforms), you will also have to account for collision detection (players and monsters can't walk through walls, or each other, unless they're ethereal in nature), proximity detection (players/monsters can't melee opponents that aren't next to them, players have to be next to doors, boxes, levers to interact with them), visibility/line of sight (players/monsters can't see through walls or around corners, unless they have special/magical abilities), and monster AI gets more complicated.
closed account (Ly59GNh0)
I'm well aware of most those issues, but except for LoS, I'm fairly certain I could figure them out.
So I'm guessing it's really not as simple as "start learning how to use library X" then? <_<
So I'm guessing it's really not as simple as "start learning how to use library X" then? <_<
closed account (Ly59GNh0)
Sure, but I really have absolutely no idea where to start since I've only been working with the standard console stuff so far. A push in the right direction would be lovely.
If you're on a platform that ncurses supports, that would be the ideal place to start.
If you're on Windows, not so ideal. Look up WriteConsoleOutput() on MSDN for the Windows function to use. You'll have to take care of all the buffer management yourself, as this function just takes as input a buffer to update the console display to. Well, you can also specify what portion of the input buffer and what portion of the Console display to update, but it would still be up to you to keep track of what would and wouldn't need to be updated. Starting out, I'd just focus on getting full console updates working.
To complicate matters though, WriteConsoleOutput does not play well with cin/cout either, so you'll have to rely on other Windows calls to handle input as well. Look up _getch() as a starting point there. GetKeyboardState() is another option, especially if you want non-blocking input, but that's a bit more complicated to work with, so probably not the best place to start.
Also, google for some existing roguelike (there are a whole bunch out there), and find one that provides source code. Explore the available sourcecode for those existing games for ideas on how to implement all those capabilities in your own.
If you're on Windows, not so ideal. Look up WriteConsoleOutput() on MSDN for the Windows function to use. You'll have to take care of all the buffer management yourself, as this function just takes as input a buffer to update the console display to. Well, you can also specify what portion of the input buffer and what portion of the Console display to update, but it would still be up to you to keep track of what would and wouldn't need to be updated. Starting out, I'd just focus on getting full console updates working.
To complicate matters though, WriteConsoleOutput does not play well with cin/cout either, so you'll have to rely on other Windows calls to handle input as well. Look up _getch() as a starting point there. GetKeyboardState() is another option, especially if you want non-blocking input, but that's a bit more complicated to work with, so probably not the best place to start.
Also, google for some existing roguelike (there are a whole bunch out there), and find one that provides source code. Explore the available sourcecode for those existing games for ideas on how to implement all those capabilities in your own.
Who needs ncurses when you have PDcurses?
Besides, you can always compile ncurses with Cygwin or MinGW.
Besides, you can always compile ncurses with Cygwin or MinGW.
Well there you go. Ignore everything I said about working with Windows functions and use PDcurses.
My $0.02: Skip the ASCII art and move straight to SDL (http://www.libsdl.org/) no matter what platform you're on :-)
Topic archived. No new replies allowed.