Author Topic: Console Grid Size  (Read 11601 times)

Brokenkingpin

  • Newcomer
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Console Grid Size
« on: October 01, 2014, 03:07:47 PM »
I am making a console roguelike, and I was just wondering what the standard console size should be? I have seen 80x25, but that seems a little small for today's screens.

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #1 on: October 01, 2014, 03:31:51 PM »
I agree.  Right now my console is open to 133 columns x 66 lines.  I usually use a smaller font in the console with the same size window, so it's usually larger, something like 150 x 80.  Even DOS Boxes running no graphics had a  120x50 mode if you had a Hercules monitor card and selected hi-res using the 'mode' command.  Unfortunately that hi-res mode on Hercules monitor cards was black-and-white only.... 

If my opinion matters to you, I'm writing a game to run on the console, but I'm assuming that the console is a terminal emulator, not a hardware terminal.  So it has additional capabilities like changing sizes dynamically.  Accordingly, I'm handling these events whenever the user grabs the corner and drags changing the console size, by just redrawing the game at the new size.  I have it set up to ignore keyboard input (except 'Q'uit) and just draw an error message complaining that the screen is "too small to play" if the console gets smaller than 50x15 though.

Writing the code to decide which screen areas to devote to various screen regions (map, messages area, status area, etc) to fit the new monitor size, and scaling each area as allowed/required to fit the monitor's new height/width ratio in character cells, was interesting. 

mushroom patch

  • Rogueliker
  • ***
  • Posts: 554
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #2 on: October 01, 2014, 06:11:03 PM »
Agreed. I'd assume you're on a terminal emulator, use as much space as the user gives you, and adjust (via a SIGWINCH handler or windows analogue) for resizes as appropriate.

Kevin Granade

  • Rogueliker
  • ***
  • Posts: 83
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #3 on: October 03, 2014, 02:06:18 AM »
If you don't want to dynamically resize*, pick a resolution you want to support, pick a reasonable font size, and see how many rows and columns will fit.

*If you don't, be prepared for players to complain about wasted space and that it won't fit.  Also be aware that you REALLY don't want to write your game fixed size and retrofit resizing into it later, it's really no fun.

reaver

  • Rogueliker
  • ***
  • Posts: 207
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #4 on: October 03, 2014, 06:37:27 AM »
In my opinion, do the following:
- Implement a system that allows you to do an automatic fitting (doesn't have to be perfect) AND accept explicit UI configurations
- Do your research to find the most common console resolutions that you want to support, and create explicit UI configurations that look great on them.

There's no one-size-fits-all solution (dynamically resizing AND looking great), it's just a programmers' wet dream. Optimize for the most expected use case, and have ok solutions for anybody who wants to use an uncommon resolution. This should get you going much faster than supporting any possible resolution, and it's much more flexible than just choosing a single one, as the others pointed out already.
« Last Edit: October 03, 2014, 06:45:27 AM by reaver »

Bear

  • Rogueliker
  • ***
  • Posts: 308
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #5 on: October 03, 2014, 05:42:06 PM »
While there may be no one thing that looks great on all consoles, I will point out that the simpler your layout is the more consistent it will appear when the user changes console size.

I have a fully implemented solution if you want C code that works with ncurses, but it is complicated.

It uses 'layouts' which partition the screen into regions kind of like HTML tables with spanning cells.  Each region is associated with a drawing routine and minimum/maximum x and y sizes.  There's a layout manager that keeps track of as many layouts as you want, so you can decide which layout to use based on the xsize and ysize of the display, or whatever other criteria.  Whether character information goes in a column on the left edge instead of in a row at the bottom can depend on aspect ratio, or whether you even allot regions for a map key or a mini-map can depend on the size of the display, or you may give the player a UI option to choose between 'nethackish' or 'angbandian' or 'alphamanly' layouts.

The minimums are treated as absolute; if the screen is too small to meet all the region minimums, resizing fails.  From there, resizing adds rows or columns of cells one at a time.  It decides what table row/column to add a character row/column to, by sorting the regions in order of "tightness" (ie, what percentage of their desired maximums they have been allotted already) and going down the list  iteratively eliminating table rows/columns from consideration unless they are spanned by the "tightest" region not already considered.  Eventually, usually after considering just one or two or three regions, it narrows it down to a single table row/column to add the new row/column of character cells to.  Rinse, repeat, until you reach the xsize and ysize of the display.

The UI draws the layout when the game is getting input from the user, by calling the draw routine for the active layout, which in turn calls the draw routine for each region.  The drawing routines get as arguments the coordinates they're responsible for filling in, plus a small bundle of arguments from the UI. 

The drawing routines I've got depend heavily on an interface provided by a display manager. Displays are a different idea from layouts.  Displays and draw routines would be totally different with a graphical display at pixel resolution, while the layout code wouldn't change at all.  The integers it uses for the size of its table rows and columns would just refer to pixel coordinates instead of character cells.  Anyway, the display manager I've implemented is for character displays and depend on ncurses.

The interface provided by the Display manager could be exactly the same for a tiled display as it is for the ncurses display, and should work without changing the draw routines. I wrote the display manager with the plan that it should be the *only* file containing code that needs to change if switching from ncurses to tiles.

In fact the display manager and layout manager are pretty object-oriented; function pointers are just the C representation of an object method. 

So the UI knows about the layout interface.  The layout code essentially knows nothing about the display it's managing except that it has function pointers to draw routines. It  knows it can give them coordinates as arguments and it passes through arguments to them from the UI.  The draw routines know about the interface provided by the display in terms of areas to "say" text in and grids of rows and columns to "draw" tiles in.  In fact the tiles are characters with ncurses attributes just like the strings, but the display routines don't know that; they just have a tile number that represents a tile and they tell the display to put that tile at a given location in the region. 

So anyway...  if you want to deal with C code that uses function pointers etc, I have code written and  documented and although some of it is kinda messy, I will cheerfully share it.


Brokenkingpin

  • Newcomer
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: Console Grid Size
« Reply #6 on: October 06, 2014, 02:32:04 PM »
Thanks for all the input guys!

I am writing my game in C#, so the C code will not help at that level, but I understand the concepts well enough.

Krice

  • (Banned)
  • Rogueliker
  • ***
  • Posts: 2316
  • Karma: +0/-2
    • View Profile
    • Email
Re: Console Grid Size
« Reply #7 on: October 06, 2014, 08:56:12 PM »
I have seen 80x25, but that seems a little small for today's screens.

Not if the font is big. I think the design should be from game design perspective (what is useful in the gameplay), because we no longer have 80x25 console as the only hardware screen mode.