Temple of The Roguelike Forums
Announcements => Traditional Roguelikes (Turn Based) => Topic started by: Bear on September 18, 2014, 02:26:35 AM
-
So: I put up a basic homepage/announcement page for neohack.
http://dillingers.com/blog/neohack/
It basically talks about the design goals and does some simple intro material.
In the future, all updates about Neohack will go there. When there's a release, it'll be available from there.
And yes, I'm now mentioning an actual timeframe for release. For, approximately, the first time.
-
Wow. The technical part is the biggest selling point for me. I'm shocked, in a good way. And it actually sounds like a system that can be sensibly moddable. Wow.
It's interesting what the time system is, and how everything is going to work together. You previously mentioned something about timers and event triggers, I'm looking forward to seeing it in action too.
Are you going to accept contributions from others, maybe with a repository on github, or you will be doing everything yourself? I'm just curious, because it can become a very important question in the future.
-
Timeframe looks very optimistic, but looking forward to it
-
Neohack’s Data-Directed architecture easily and without touching main game logic allows complex interactions and multiple-use items which are not possible in most roguelike games and achievable only through extensive case-by-case patching of exceptions into main game logic in other games. Also the code is well documented internally and comes with a “modders guide” which serves as an introduction to the code base and architecture. This affects the ability to modify, maintain, expand, and improve Neohack. From the perspective of players, this means that bugfixes, balancing changes, and new features should be routine and quickly releasable rather than rare and riddled with new bugs.
I would like to see a few examples of such interactions. Guess it is already implemented, not just planned?
-
Clever name.
I think you're on the right track with your approach to the console interface. I like the part about using two characters to represent tiles, but I would recommend using wide unicode ASCII characters to represent monsters and two part tiles only for piles of items and other inanimate objects/dungeon features. (Although I have to admit, the idea of using the second tile to represent a wielded item is interesting and something I hadn't thought of, I'm kind of sceptical of it aesthetically and from a usability perspective.)
(Further parenthetical gushing about two character tiles: You can do a hexagonal grid in a standard terminal with them. Not that anyone should do that, just saying it's possible.)
Re: Mouse support, I'm sure you know that curses supports mouse events from xterm and xterm-like terminals. I'd be interested to see how that works in a roguelike game. xterm mouse support has seemed clunky to me in those few cases I've used a curses application that used it, but I've never experimented with it seriously from the development side.
-
the idea of using the second tile to represent a wielded item is interesting and something I hadn't thought of, I'm kind of sceptical of it aesthetically and from a usability perspective.
Agree on that.
If only this kind of info could be revealed in a more pull-style way (rather than push-style aka "shove it down your throat") as a semi-transparent layer over the tile when mouse was hovering over it. Oh wait.
-
With a name like "neohack" I was almost expecting a cyberpunk game.
Sounds cool though. Is the two-tile system implemented yet? Do you have any screenshots to show how it'd look?
-
Are you going to accept contributions from others, maybe with a repository on github, or you will be doing everything yourself? I'm just curious, because it can become a very important question in the future.
Seconding this question, because with the modding supposedly being detailed and easy, I'd love to contribute!
-
the idea of using the second tile to represent a wielded item is interesting and something I hadn't thought of, I'm kind of sceptical of it aesthetically and from a usability perspective.
[...]
If only this kind of info could be revealed in a more pull-style way (rather than push-style aka "shove it down your throat") as a semi-transparent layer over the tile when mouse was hovering over it. Oh wait.
Mouse hovering can be detected in curses, with some effort. If I were doing this, I would have a side bar that has (short) descriptions of every monster and object on screen. Mousing or clicking on a monster/object would highlight it and the corresponding entry, perhaps scrolling the sidebar if necessary. Perhaps another click would expand the description in the sidebar.
The point is, the good part of your idea can be done in curses.
-
Mouse hovering can be detected in curses, with some effort. If I were doing this, I would have a side bar that has (short) descriptions of every monster and object on screen. Mousing or clicking on a monster/object would highlight it and the corresponding entry, perhaps scrolling the sidebar if necessary. Perhaps another click would expand the description in the sidebar.
The point is, the good part of your idea can be done in curses.
I'm not saying something like that can't be done, just saying that mouse and hover-popus are natural with real GUIs. Sidebar would work, but then you'd have to be moving your eyes back and forth - mouse cursor for targetting what you want info about, and sidebar.
Anyway, I'm ending my hijack, I guess more meaningful comments about interface can be had with actual footage/demos.
-
So does the OP have any screen shots and/or video of how this two character monster + wielded item business looks in realistic gameplay situations? (e.g. crowds of monsters, movement in crowds, etc.)
-
Certainly sounds spiffy and looking forward to what comes of it! 8)
-
Re: Mouse support, I'm sure you know that curses supports mouse events from xterm and xterm-like terminals. I'd be interested to see how that works in a roguelike game. xterm mouse support has seemed clunky to me in those few cases I've used a curses application that used it, but I've never experimented with it seriously from the development side.
Right. curses is essentially 3 things that ought to be separable but aren't really if you're using it. One is keyboard input, two is display output, and three is mouse input. Right now I'm using curses for keyboard input and display output, on the presumption that there are things that are "drop-in" replacements for those functions that ought to work fine (libtcod probably, though I haven't looked at it yet). I'm not nearly so sure about mouse input. If I use curses to process mouse input, the interface is just bizarre enough that I'm afraid it'll be hard to replace if I replace curses as the I/O library.
-
With a name like "neohack" I was almost expecting a cyberpunk game.
Sounds cool though. Is the two-tile system implemented yet? Do you have any screenshots to show how it'd look?
Two-tile system is implemented, but as yet no monsters wield weapons. :-/ So the major functionality of it is sitting there in code but not yet tested/debugged. I will be hacking inventory (and weapon wielding) this weekend.
-
Are you going to accept contributions from others, maybe with a repository on github, or you will be doing everything yourself? I'm just curious, because it can become a very important question in the future.
Seconding this question, because with the modding supposedly being detailed and easy, I'd love to contribute!
Yes, there's going to be a Github repository and I will be accepting contributions.
That said, I will be accepting contributions that actually work with game balance and fit in with my vision of what the game ought to be, not every contribution that someone thinks would be cool.
-
Neohack’s Data-Directed architecture easily and without touching main game logic allows complex interactions and multiple-use items which are not possible in most roguelike games and achievable only through extensive case-by-case patching of exceptions into main game logic in other games.
I would like to see a few examples of such interactions. Guess it is already implemented, not just planned?
Yes, it is implemented. When an "event" happens, it involves up to a half-dozen different "actors" in different roles. Each "actor" has a set of attributes, which may include "triggers" containing a pointer to executable code to be executed when that actor occupies that role in an event of that kind. As an example of an action with a nearly-maximal set of actors, when an arrow is fired, that's a 'fire_ranged_weapon' event. You have the archer in the "Instigator" and "Subject" roles, the bow in the "Agent" role, the arrow in the "Agency" role, and the target in the "Object" role.
The main game logic is sort of formless in its generality: it gets an event off the schedule, checks the involved actors for "before" triggers, executes them if they exist, performs the action itself, checks actors for "after" triggers, and executes them if they exist. Rinse, repeat until "end of game" action is processed and the schedule becomes empty. Any action or trigger can put more actions on the schedule, or reschedule/remove actions that haven't come up yet. "Before" actions can change parameters in the closure of the event that they're triggered by (for example modifying the damage in a damage event) before that event is actually executed. "After" triggers can do things that depend on the outcome of the action(for example setting an amount for 'vampiric regeneration' based on the amount of damage done).
As an example of how general this can be, someone puts on a pair of blink boots (a 'wear' action). The blink boots have a trigger A that gets called when they're the 'Object' of a 'wear' action. Trigger A sets a trigger B on the wearer. Trigger B gets called whenever the wearer is the 'Subject' of a 'walk' action, and subject to some conditions (still wearing the boots?) either schedules an immediate 'blink_teleport' after the 'walk' or (not wearing the boots?) removes trigger B from the wearer.
Whatever interaction or use you want to build into a given kind of 'new content' actor, you do that by defining trigger routines to be carried by the actor, and possibly new action routines as well. Then you define an actor-init event that creates an actor with those triggers, and a content-init event that registers the actor-init with one or more map creation tables so that the map creator will create actors of that kind with some probability. A 'sed' script in the makefile detects and creates a list of all the content-init events, and they get called during game initialization.
So a valid 'content' file is a file of C source code that contains a content-init definition and whatever stuff that function refers to. You drop it into the 'content' directory, run 'make', and the executable that gets built now contains your added content and understands all the ways that content is supposed to be treated specially in every event.
What did not happen was the need for any 'diff' applied against the main game logic in a way that might break any other content, or the need for any part of your content to be out there in the main game logic where a further diff from some other source might break it, or the need for some maintainer somewhere to figure out how to merge diffs or what order to apply them in. If you define content that doesn't literally and deliberately depend on other content, building the game with or without it is as simple as adding and removing files from the content directory before running 'make'.
-
Sounds great. I can't wait to see how this works.