Messages

1

Design / Re: View Styles

« on: February 06, 2015, 04:22:42 PM »

The vertical dimension is what constrains your player's FoV.  Modeling the player character's FoV gives you an odd number of required rows and the exact same number of required columns.  Centering the player on the display with 80x24 and a max FoV of 11 leaves one line at the bottom (or top) and 28 columns on each side (+1 extra column).  It may not be traditional, but the player doesn't actually need any larger map view. 

For better appearance, you could restrict the FoV to a maximum of 10 cells, giving you a border separating the map from the text.  Also since the FoV is circular, you have triangular areas at the four corners where you could display some form of information.  It is a bit harder to code since you need to scroll and it will require more bandwidth over remote connections.  Really though I don't believe either is a barrier today. 

Excellent ideas!  And definitely true.  I hadn't thought about a square view!  Yep, definitely non-traditional, but doable

Restricting it to 10 cells is ok too, but like you said the scrolling would be an issue.  Not necessarily for the code's sake, but for the player's sake.  Not able able to automatically see everything that your player can see is an issue of usability and ease of view.

Great ideas, thanks Omnivore

2

Design / Re: View Styles

« on: February 06, 2015, 12:35:43 PM »

Very true Krice, thank you   Planning is everything, and putting non-required data into lists under special pop-up menus would help that.  I have been thinking about the -more- for a while, and I have two thoughts on it:

1) A much shorter version of it, but that it can display up to 10 messages at once, verticaly.  Thus, "Orc Attacks" would be great, but "Orc swings his battle axe and hits you squarely on the chest" does not.  This of course is limiting, but it does at least display data quickly and without having to re-reference previous messages with ^P or something.

2) A single line devoted to full sentences.  This won't take up too much space, and it allows for whatever sentence you would like, up to 80 characters.  When you need to move on to the next message, that previous one could be summarized into the shorter one's, because you don't need to know EVERYTHING about it 10 turns later.  Of course, a ^P would be helpful in this case of course. 

And yes, I could go to a larger format for sure, or perhaps have it as the player's option.  The more options the better I say.  Another feature to implement!

Thank you Krice, very much

3

Design / Re: View Styles

« on: February 04, 2015, 10:25:16 PM »

Then I suppose that's about it then.   Thank you everyone, I think I have my answers now.

4

Design / Re: View Styles

« on: February 04, 2015, 07:28:39 PM »

Keep in mind that the reason you are having problems figuring out how to layout your menus and map view is due to the fact that you are constraining yourself to a small terminal size, so the responses about terminal size aren't totally unrelated since the obvious solution to the problem is to drop that constraint.

Thank you Jlund, your comments on hiding less important information was good.  Thank you

Perhaps I'm limiting myself, but can anyone think of a smaller font size than 80x24?  Every time I pull up a gnome-terminal, it defaults to 80x24.  The largest fonts available, without additional downloads, for my TTY monitor is 80x24.  That's what I play on, that's what I use, that's what I will continue to develop for.  As I see that size will always work on xterm or someone's larger monitors, I have nothing to worry about, compatibility wise.

Mushroom Patch, I do like large fonts.  And I am named from Pokemon, correct.

5

Design / Re: View Styles

« on: February 04, 2015, 06:06:35 PM »

My linux tty is about 172x54... unless you're running a raspberry pi on an old CRT TV, there's no way you need a 80x24 terminal format. Is your computer a Dreamcast or sth?

Alright, I must be near and far sighted also.  

So here I am trying to get ideas on how people like their map and menu styles, and I am immediately attacked for my preference of a large fonted 80x24 terminal.  Who cares about the darn size of my terminal besides me? 

I just wanted ideas that others thought were easier and more approachable, but I found two members of the community that were not easy nor approachable.

Forgive me for asking, I'll just program along with whatever I feel is correct, and get yelled at for it later.  Fine job, thanks

If you actually have conceptual ideas behind better looking menus and map viewing, go ahead and post because I'll be listening.  If you want to yell about terminal sizes from the 80's, start another thread please.

6

Design / Re: View Styles

« on: February 04, 2015, 02:20:38 PM »

The first question is why would you be restricting yourself to a 80x24 window in 2015. I mean, it's fine to choose such size, but only given that you're good with all the consequences it brings. Look at The Ground Gives Way for example, it uses a 92x38 window and its interface manages to look good and work well, but I'm fairly sure the developer didn't think "Hmm, 92x38 window is precisely what I need" before making the game, but instead added various UI elements, stretching the window so that they may fit.
And as for map view, it's more of a gameplay design than UI design question.

Well, there are three reasons I choose the classic 80x24:

1) It will STILL run in TTY Linux.  Believe it or not, some people actually care about that sort of thing (as in, me).  I can start up a game of Rogue or Nethack no problems, and it's SUPER fast, with no delay at all that gnome-terminal or xterm sometimes brings.  Plus, it's fullscreen.

2) Others still need it.  I once played a 7DRL that used something like 84x26, and almost all players commented on not being able to even run it.  It shows you the environment most people play in is actually limited.

3) It's classic.  As mentioned before, the older games use this, and do very well.  Even though I have already transferred it over to a more graphical interface in X, the window size at 80x24 is still quite acceptable to my tastes.  Having both options gives the player exactly what they want, all of the time.

Just because it's possible, doesn't mean I SHOULD automatically do it.  As you say The Ground Gives Way uses a different size, all well and fine.  I am not excluding the use of newer technology.  I am personally just wanting to stay within the limits that literally ALL players can use.

*** As a side note, I once downloaded Angband for my Linuxbox.  Started up the program in TTY, and got some REALLY horrible results.  Couldn't figure out why for the longest time, until I tried to run it in X.  Sure enough, it's purely graphical now, and only uses the ASCII characters for posterity's sake.  So I stopped all that business, ran: sudo apt-get install nethack, and the world was much better. ***

Lastly, you are right about the map view being a gameplay design issue.  Thus, why I was asking for opinions

Thank you Rot

7

Design / View Styles

« on: February 04, 2015, 12:45:15 AM »

I'd like to know what you all think about particular styles of viewing I see often in roguelikes:

Map View

1) 80x24 tiles on the screen, and 80x20 or so of them are devoted to the 'static' world.  The map doesn't move with the player.  Instead the player moves within the static map.  It is an older style, and you can find secrets easier in this way because of a large blank section on your screen.  Rogue and Nethack use this.

2) Something less than 80x24 for viewing a map that moves instead of the player actually moving.  In this regard, your @ is stationary relative to the screen, while the map moves in reverse style.  Secrets are much harder to find because you never know if you are at the center of the current map or not.  Likewise, maps can be much larger than just 80x21 or so.  Crawl uses this.

Menu View

1) Some amount of stats at the bottom of the screen, taking up entire horizontal lines.  Easier to read out lots of information at once, and maximizes map view, but many different stats listed tend to mush together.

2) Stats are displayed on the left or right side of the monitor, map on the other side.  With a shorter vertical column, many stats can be displayed at once, and does not feel cluttered.  Problems arise though when length of display stats do not fit.  Full sentences are not possible.

Dialogue View

1) One or more horizontal lines, sometimes at the top of the screen, sometimes at the bottom.  Full sentences, and multiple sentences are completely ok, but multiple lines are either broken up with required 'carriage returns', or blocking the map view, or just the line buffer is quickly emptied.

2) Short 'sentences' squeezed into a requisite space on the left or right, beside the menu stats.  Full sentences could take up the entire buffer, but short messages are easily displayed.

What are your thoughts on these systems?  Which are better?  Which are easier to read from?  Are there any alternatives to any of these particular readouts?

I am asking this because I am currently developing a roguelike myself.  I have the map view as 60x24 on the left side of the screen, and a menu as 20x24 on the right side of the screen.  I have no room for horizontal dialogue right now, unless blocking the map view, which I find as a small problem.  So I am just seeing what you all thought about this particular situation   Thank you for any responses

8

Design / Re: Going beyond hack and slash

« on: February 03, 2015, 01:22:13 AM »

You can look at all the existing RPGs and roguelikes out there and even wider out into FPS and see that for all the worthwhile ones like Oblivion, Dragon Age, Baldur's Gate, etc etc combat is the crux.  It gives the meaning, the focus and is generally a shallow and achievable core mechanic.  And it is doable because it has been seen to be done.  Someone can just clone it and do minor iteration on it, and it is conceivable in their mind how to create it from scratch.  Conversely, there are no equivalent non-combat reliant games to clone and iterate.  Making a game from scratch is a tremendous investment of time and energy, but coming up with a new genre that is a superset rather than a subset of the combat-reliant standard, I argue is inconceivable to most.  If someone made it, and it was done well, it would be a breath of fresh air and in demand.

I agree.  Combat in video games, in general, is pretty much the status quo.  But, of course, this does not mean that it is unmeaningful or not fun.  As stated above, there are many games, SO many games, that are combat based.  Roguelikes are video games, and fall into the same types of combat schemes as any other video game genre. 

I likewise agree with the fact that making a non-combat game, and a well made one at that, would be hard to do. (Simulations and Sports games don't count here, as I assume we are talking about games where you play the role of a single character.)  It is exactly right that there are no good 'clones' to work from in this department.  Ever thought of what a non-combat game would look like?  It would probably still contain a 'combat' system, just without the bloodshed. 

Games in general are something to do, that is: fun, interactive, and hopefully involving some skill (plus or minus depending).  Try to name something besides combat that fills those three requirements and can easily be relegated to a computer.  And what you might see as fun, certainly some others do not.  Apparently, something that nearly all humans can agree on, that has everything you ever wanted, but you could not ever really do in reality, is COMBAT.

Of course, if there was a non-combat video game, particularly something RPGish, that was indeed well done, I would be VERY interested in playing it.  In the least to just learn the darn mechanics and clone it!   To outright say that a roguelike MUST have combat is just not right, but it would indeed be very hard to accomplish. 

Does anyone have any ideas on how to implement a non-combat roguelike?  Perhaps choosing correct rebuttals at an opponent's verbal sword?  I am sure one of you has more creativity in this area than me   Don't let anyone try to tear down your ideas.  The only way to see if they would work or not is to just make the game yourself, present it to the community, and see what happens.  I, at least, would be willing to give it a try

And overall, let us be supportive of others.  I know some of you might not like this statement, but in all seriousness, we are in the same boat here, and we might as well support one another in our endeavours.  It can only strengthen us as a whole.  Thank you all  

9

Design / Re: Going beyond hack and slash

« on: January 30, 2015, 04:16:51 AM »

If you want to go beyond hack and slash in any game, first you need players who *want* to do something else.

I agree with this, and it shows that there are people out there looking for it, as Elig created this thread

The thought of non-combat based roguelikes has been in my thoughts for a while now.  Particularly non-violence in roguelikes.  It seems odd, but hey, it might be possible   But then as someone stated, a lot of people think Dwarf Fortress is not a roguelike, and that is certainly going away from combat (oriented). 

But, as Elig had initially stated, this thread is about enhanced role playing in roguelikes, not necessarily doing away with combat entirely.  Nethack indeed is a unique example!  And a true emulation of DnD 2nd Ed would be fantastic as well!  What better genre is there in order for someone to really *become* their character.  When that so loved character could die at any moment.  When that character experiences new events and happenings all the time.  When the players are not limited to just what they see, but also now what they imagine!

It's not just about throwing gems at unicorns, it's about *being able* to throw gems at unicorns.  The game must have unicorns, gems, and throwing mechanics.  They also must have these three things come together specifically for that task.  And there are two ways to accomplish this.  Either, "The Dev Teams Thinks of Everything" motto as in Nethack, or a generalized mechanics system that allows for these very specific reactions on a broad scale, but perhaps not as... unique.  Regardless, unless mechanics change over time, the players will eventually find out these interesting events, and it will no longer be new to them.  As the creator, it is your task to at least make sure the player has fun while learning these specifics.

With the incredible amount of roguelikes that are being created, and the relative ease as which any one of us could put one together in say... 7 days, allows for us to experiment with different styles, types, and to take a few risks.  I am hoping to be able to enter into the 2015 7DRL Challenge, and have been contemplating a non-combat system for it.  Hopefully I am able to compete.   It would be a small experiment for us all.

Elig, and anyone else, if you wished to email me with any ideas on enhancing role-playing in roguelikes (or any games for that matter), I would greatly appreciate it.  Or just post your own thoughts here for everyone to see   Expanding our horizons, but remembering both tradition and engagement, should be a goal for us all.

Thank you to all that have posted

10

Challenges / Re: 7DRL Challenge for 2015?

« on: January 27, 2015, 06:54:46 PM »

Excellent, thank you for the reply Slash, very good news

11

Design / Re: a new world engine?

« on: January 27, 2015, 06:52:20 PM »

Is there anyone out there who would be interested in this sort of thing?  Maybe I'm just odd.

You are not odd.  I have done this many times on my own, trying to create worlds for my games to work from.  I'm not exceptionally good at Perlin Noise or anything, but a few fancy algorithms definitely can do some neat tricks

Have you ever played, or just started up, Dwarf Fortress?  What you are describing sounds similar in design.  Create the world, make a history, weather and all!

Would this project be for ASCII / tile based games in particular?  Or are you viewing this as a more 3D or 'floating point' based system?  Tile based stuff looks well enough with tile based games, but making a tile-based world for a 'floating point' based game make it looks silly a lot of times (from my personal experience).

What programming languages do you use in particular?  What graphics libraries?   C++ and OpenGL, by chance?  I wouldn't mind sending you some code of what I've done in the past, though a lot of times you will not be impressed at all.

The use of this type of program / tool would be handy for those who wish to have something like this, but those people might be few and far between (especially looking at the above responses).  I myself had thoughts to make huge games, massive and deep.  But I find that games are best when they are games.  When they are fun   And I can't seem to make fun things from crazy algorithms anymore.  

Anyways, thanks for asking, you can email me and we can talk more if you like

12

Challenges / 7DRL Challenge for 2015?

« on: January 27, 2015, 06:08:28 PM »

I'm completely new to this site and RogueBasin, and I've been trying to find when the next 7DRL Challenge will be in 2015.  I noticed that they are generally in the March timeframe, but does anyone know anything more about when that will be at this time?  I also just sent my email address off to the mailing list from the 2014 Challenge, hoping that will help some. 

Also, I saw on RogueBasin that the use of previous code is... dependent on the developer.  Kindof vague.  Is there some harder set guidelines at all?  Or just a new theme is required?  Or some concrete number of lines of code can be transferred over?

Just wondering since I'm the newbie   Thank you everyone