Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Invilis]

I have coded my own game in console (obviously it has text graphics) but it has to clear the text every time something moves. How do I get it to be as smooth and nice as Dwarf Fortress?

[Bumber]

Is this the case with [PRINT_MODE:TEXT] (Linux/OS X only) in init.txt?

Most people (including myself) are actually playing with an OpenGL representation of text.

[Invilis]

So I should use OpenGL or SFML for my game?
I am using Windows BTW

[Toxicshadow]

Though this probably isnt the place for this kind of question, yes. Unless you're making a retro text based adventure, you shouldn't use a terminal for a game. Even then I wouldnt recommend it.

Look into some game engines and learn one of those. They handle the backend stuff for you and make development a bjillion times easier.

Also look into how games and computers in general work.

[mikekchar]

I have a completely different perspective.  If your game mechanics don't require graphics, don't make your job harder by adding a massive dependency for an external game engine.  Text is fine -- more than fine, really.

Now, it is completely reasonable to think "But most people want fancy graphics, so if I just use text nobody will like my game".  This is true from a certain perspective, but I've been writing code for a LONG time (just coming up to about 40 years since I wrote my first program).  Virtually nobody uses my code :-)  That's the way it is.  There are millions upon millions of projects on Github.  There are millions upon millions of projects that *aren't* on Github.   Massive run-away successes are virtually non-existent in comparison.

So the absolute number one person you must satisfy when writing your game is YOU.  You have to be OK with the idea that possibly nobody other than you will play your game.  Even more, writing games takes *lots* of time -- possibly all of your free time.  Choosing your development environment and libraries is a very personal thing and while I could tell you what I enjoy, it's kind of meaningless.  It's got to be something that helps you get off the couch and write code day after day after day (rather than watch TV or play DF).

Having said all that, if you are looking for libraries for doing console output for games, I would search google for terms like "writing rogue like games windows".  I could give you a few suggestions for Linux development, but I haven't done any Windows development for more than a decade so I'm a bit out of touch.

[Untrustedlife]

I have coded my own game in console (obviously it has text graphics) but it has to clear the text every time something moves. How do I get it to be as smooth and nice as Dwarf Fortress?

Dwarf fortress uses SDL
There are many libraries that use SDL, I suggest looking up libtcod if you want to have a game that uses Ascii I use libtcod and Sfml in my game. And it's totally silly to assume "no one will play my game if it is ascii" just make a good game put it out there and see what happens.

[Jairl]

I have coded my own game in console (obviously it has text graphics) but it has to clear the text every time something moves. How do I get it to be as smooth and nice as Dwarf Fortress?

Well... yeah, Dwarf Fortress uses some helper libs (SDL) for this.

But you also can 'print' a black character after setting the cursor position over the old area. you update what changes rather than updating the entire screen at once.

https://docs.microsoft.com/en-us/windows/console/console-functions
https://docs.microsoft.com/en-us/windows/console/setconsolecursorposition
https://docs.microsoft.com/en-us/windows/console/writeconsoleoutput


I would also add that writing this stuff yourself is infinitely more fun than using plug-in-play libraries. It really is fun to write your own game engine.

[lorb]

You can absolutely make a fine game in the console. Just don't expect to make something huge like dwarf fortress. Many linux distributions come with a game called moon-buggy that is console only.

Check out https://en.wikipedia.org/wiki/Curses_(programming_library)

[ShimmerFairy]

I have coded my own game in console (obviously it has text graphics) but it has to clear the text every time something moves. How do I get it to be as smooth and nice as Dwarf Fortress?

There are commands that you can send to the terminal to move the cursor around and change stuff without clearing the whole screen. BUT! You don't want to do this yourself. Look into a curses library which handles all that for you, such as ncurses, or for Windows, pdcurses.

Point is, you should use a curses library or curses-like library to handle all of the historical differences between different terminals. (These differences affect what you can do, and how to do it.)

[Ziusudra]

I second the recommendation for libtcod.

[bloop_bleep]

In ncurses and pdcurses you don't have to clear the screen every time you want to change it. Instead you designate what needs to be changed and then refresh the screen.

Though keep in mind ncurses and pdcurses are C libraries, so don't expect a comfy object-oriented interface if you're using C++.

[Jairl]

I still advise doing it yourself.

It REALLY is a very easy thing to do... and you'll learn so much more about programming by thinking through the process, instead of just downloading the first library to handle it that you can find.

[bloop_bleep]

I still advise doing it yourself.

It REALLY is a very easy thing to do... and you'll learn so much more about programming by thinking through the process, instead of just downloading the first library to handle it that you can find.

Don't reinvent the wheel. If you find a library that does what you want to do, use it. You're just wasting effort otherwise.
Besides, doing what you suggest would involve interacting with the terminal/OS directly at a very low level, making your program unportable and probably requiring special knowledge that I doubt the OP has.

[Jairl]

Don't reinvent the wheel. If you find a library that does what you want to do, use it. You're just wasting effort otherwise.

Oh? Now tell me the limitations of the implementation that your magical library has. Oh right... you don't even know how do to it yourself in the first place, let alone the problems you'll end up with in the future should you need to change libraries.


I am encouraging the OP to learn how to think, how to process a problem, how to read documentation (which is very easy).



Besides, there are a million odd "Rogue remakes".... why reinvent the wheel and make yet another rogue remake? It's wasted effort, right?

Besides, doing what you suggest would involve interacting with the terminal/OS directly at a very low level,

Uhh... making threads is "low level" now? Directly calling win32_threads or p_threads is hardly "low level" programming. This is how people program.

Sure, you could just download a very high level language like python, java, or even C# and not give a crap about how anything works, or if it works... but you should be choosing the language best suited for your task, not being restricted by your fear of doing things yourself.

making your program unportable and probably requiring special knowledge that I doubt the OP has.

"Portable code" is often misused in the same manner you just misused it.

To show you how badly you misused code portability, I'll challenge you to tell me that win32 software is not platform independent. WINE brings many windows libraries over to *NIX systems. They're imperfect libraries, but still libraries none the less.

There is no guarantee that the system you're targeting supports threads, for instance. std::thread is just an abstraction that calls the system level threading service. The use of abstractions, rather than their implementation, is what portable code envelopes. Even if it is as simple as a macro that changes to win_threads instead of p_threads.

The cost of abstraction is the same cost that WINE pays for attempting to translate direct x routines into opengl equivalents. Performance. DirectX is used very differently when compared to opengl, an engine designed around one or the other depends on their individual ways of doing things. You could do further abstraction and make it easy to change between the two of them via header files... but as always, that way of doing things has a performance hit. Since the abstraction gets compiled in you can get some benefits over wrapping around the calls.

[bloop_bleep]

Don't reinvent the wheel. If you find a library that does what you want to do, use it. You're just wasting effort otherwise.

Oh? Now tell me the limitations of the implementation that your magical library has. Oh right... you don't even know how do to it yourself in the first place, let alone the problems you'll end up with in the future should you need to change libraries.

I've used ncurses and pdcurses quite a few times in the past. Don't jump so quickly to conclusions.

I am encouraging the OP to learn how to think, how to process a problem, how to read documentation (which is very easy).



Besides, there are a million odd "Rogue remakes".... why reinvent the wheel and make yet another rogue remake? It's wasted effort, right?

Diving into direct interaction with the OS is less "thinking" and more "tedious unnecessary work." By your logic it's best to write everything in assembly because it makes you "think" more. There's enough to think about when writing a program in the first place; don't make it any harder on yourself.

ncurses & pdcurses are already pretty low-level -- seriously, this is 30-year old technology. There's no reason to go any deeper.

Besides, doing what you suggest would involve interacting with the terminal/OS directly at a very low level,

Uhh... making threads is "low level" now? Directly calling win32_threads or p_threads is hardly "low level" programming. This is how people program.

Again, I think you underestimate how low-level ncurses & pdcurses are. I suggest you at least look up what they even are before you continue this discussion.

making your program unportable and probably requiring special knowledge that I doubt the OP has.

"Portable code" is often misused in the same manner you just misused it.

To show you how badly you misused code portability, I'll challenge you to tell me that win32 software is not platform independent. WINE brings many windows libraries over to *NIX systems. They're imperfect libraries, but still libraries none the less.

There is no guarantee that the system you're targeting supports threads, for instance. std::thread is just an abstraction that calls the system level threading service. The use of abstractions, rather than their implementation, is what portable code envelopes. Even if it is as simple as a macro that changes to win_threads instead of p_threads.

The cost of abstraction is the same cost that WINE pays for attempting to translate direct x routines into opengl equivalents. Performance. DirectX is used very differently when compared to opengl, an engine designed around one or the other depends on their individual ways of doing things. You could do further abstraction and make it easy to change between the two of them via header files... but as always, that way of doing things has a performance hit. Since the abstraction gets compiled in you can get some benefits over wrapping around the calls.

First of all, using WINE is damaging to performance and can sometimes be buggy. Best not to rely on it.

Second of all, by "portable" I mean being able to port to another machine without changing much (or any) of the code.
For example, if you wrote a program with ncurses on Linux you can port it to Windows by simply changing the header include and relinking with pdcurses. Nothing else has to change. ncurses and pdcurses *are* the abstractions you describe -- they envelop the differing system calls and replace them with a single, common set of functions.

If you're using the OS utilities directly, you have to either use the slow, buggy WINE or have to replace every single instance of a system call to the old OS with the equivalent in the new OS. (Or if the equivalent doesn't exist, you have to write completely new code.) Basically, you yourself are doing the abstraction which existing libraries already provide.