To clear up what appears to be a common misconception, I'm almost positive that Kornel is removing console compatibility from Chaosforge games entirely. The objective of this discussion, then, is to figure out what parts of the console are important or critical enough to be implemented into the pseudo-console mode. So, going off of this:
Raw text mode is like running a roguelike from the bare code?
I understand that running it "pseudo-console" means it'll still look the same as playing it with only ASCII characters (ie classic style), and that graphical tilesets are "console mode" but what is the real difference?
Rather than why it is an issue for us on the player side, what is the advantage for you to make all future releases console-only? I'm curious now!
By "raw console mode", Kornel means that part of the output is designed to work specifically with a console or console emulator (modern Windows, for instance, has Command Prompt). However, now that the graphical interface of Chaosforge games is becoming more and more complete, it's obvious that there are a number of things consoles can't do that would be very useful. By removing console compatibility, there's no need to worry about those constraints, and the pseudo-console would run essentially as an ASCII tileset (with special modification functionality such as font size and RGB values). AliensRL's standard mode of execution is done in this way, if you want an example.
- Supports at a minimum display resolution of 800x600 pels (80x25 tiles) without any information loss.
- Have comparable running speeds on machines which do not have high end graphics cards.
- Have a means of altering the gamma/brightness of the game.
To be fair, the last two considerations should be in the graphical mode anyway. At the very least, I wouldn't be surprised if there are some inefficiencies in the current engine (that cause one of my CPU cores to churn away at maximum capacity 100% of the time). The first one SHOULD be doable as long as the tilesets can be non-square (graphical version is completely square ATM with the current tileset).
5- Fear that this is the first step in what will ultimately remove the console view in favour of the tileset (which I absolutely hate, btw. Not that it's not a great tileset, simply that unanimated grid-based sprites are no more convincing than letters, but have the potential to look far more tacky, and always do to me. )
The main reason Kornel brought this up was to ensure that there WOULD be a console view (albeit an emulated one) that meets the demands of hardcore console players. Unfortunately there some casualties regardless of the enhancements brought by the pseudo-console (like standardized remote access and use of console recorders) but we'll have to make do.
...but I for one find Console mode to be a more responsive than Graphical mode. No lag while I'm waiting for all the sprites to slide around.
Yeah, at the moment the time it takes to do just about anything on the game screen can throw off console users quite a lot (myself includes). It shouldn't be much of a problem to have options to remove movement and/or firing animations, which I think is the only real issue in this case.
Using the current posts, this seems to be what is desired for pseudo-console operation to be on par with a real console (that is also feasible with regards to its implementation):
- ASCII tilesets of variable, non-square sizes
- Ability to control color of ASCII tilesets (i.e., defining RGB values of color presets in addition to continued use of color.lua customization)
- Minimize processing intensity
The rest of the suggestions tend to depend on Kornel's own design choices IMO. 'Course I could be totally wrong! Kornel is, however, a graphical engine designer, so this direction seems awfully natural for his projects.
