Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[Sereg]

Edit:

4 APR 2020 - Version [a.2.0]:
 [Change]
  -Text screens no longer attempt to redraw themselves unless a meaningful change has taken place.
  -User profile now remembers last session's display settings (e.g. fullscreen and graphical modes)
  -Player now moves before all monsters.
  -Messages now display with the player message on top, and only attempt to display since last player action.
  -Message overflow indicates that more messages are available, which appear as before in Message Recall.
  -Floor bosses may no longer spawn on floor 1 of the Dark Grove.
  -Improved player HP and Soul at all levels.
 [New]
  -Library now supports basic upgrades.
  -Text items may now be found in the dungeon and researched in the player estate(with required upgrade).
  -Languages added and tracked across games.

Hello again everyone,

After quite a long time, I've finally got a new roguelike game ready for play testing. This is the third project I've started since Viridian Abyss, and the first since then to reach a state where I felt ready to release it to a wider audience than just myself(the other two had a lot of good features but not the overall quality I was working towards, and much of their content and code ended up in the current project).

I've developed a completely new display scheme from the one I used in VA, and I'm interested to see how well that ends up working on other computers, resolutions, monitors, and graphical environments than the ones I have immediately available for testing.

The game itself takes place in the same world as Viridian Abyss, although the time setting is significantly earlier - for those of you who played VA and remember the nations of Atlantis and Lemuria, this setting takes place in the very distant past of those nations - which were themselves very ancient history in the setting of Viridian Abyss.

My goal from a storytelling perspective is to expand on the world and lore I started to reveal in VA, while my goal from a game development perspective is to improve on the experience of VA. As far as that goes, the engine execution, event flow, display layout, etc., of the new project are already superior to what I had in VA. There's currently a *lot* less content - I only have a rudimentary implementation of items, and the dungeon itself is smaller and probably much easier to complete than the one in VA. However, the potential for expansion is far greater because the underlying systems are much better, and I have a lot of content I want to add in future releases, including some of the stuff from VA that's missing in the current release, such as languages and magic, a post mortem autopsy system, and more interesting dungeon generation.

As before, I welcome any feedback on any aspect of the game, whether it be gameplay, design, storytelling, or any other feature you feel could be improved.  Prospective alpha testers can find the zipped folder here. It contains a graphics folder(which currently only serves the purpose of supplying the icon for windowed mode - my display scheme does support tile based graphics, and my implementation requires paths for such tiles, but I don't make use of them at this time), a document folder containing a manual text file(which is currently empty, although all currently available commands can be found in the ingame help menu, accessible via '?') and a changelog text file(which is also currently empty, since this is the first release), and the executable jar, which as before requires an installed Java Runtime Environment to run.

I do have error logging implemented, and in the event of a fatal crash, a debug log *should* be written inside the main directory. If this happens, please send me the log at the provided e-mail address. If it does not happen, I'd also like to know about it, as well as all the information about what you were doing and the state of the game when the crash occurred as you're able to gather.

Thanks for reading, thanks again to those of you who play tested Viridian Abyss for me, and thanks in advance to any who will help me out that way with this new project.

[mihey1993]

Was awaiting this with a bated breath, Sereg:P

And the first two things :
1) text is too small for big screen, and no ability to make it ... well more readable. At least, it was until i discovered that simply enlarging window does nothing, only fullscreen mode dose. also, if you enlarge window, your hud all ends up somewhere in one corner, while map is in center:D

2)if you try ctrl and scroll on the text screen, you get a funny effect:D
3)when you attack something, the log is like in viridian abyss made funny, so it shows your action, while whatever your enemy did is below and greyed out, making it a little confusing as to why my health is lowering
4) i gained no experience, so far, at least i guess it is due to the unfinished state. meeting a bear with nothing but starting weapon and armor was not...very survivable tho:D

[Sereg]

Thanks for the feedback. I'll address it as I can:

1) The GUI I built, while in my opinion a significant improvement over the old one, is still pretty simplistic - I only support two tile sizes, 16x16 and 32x32(text and graphical tiles have different widths - text width is narrower for better readability, but it's constant and to scale). I don't have any capability to support resizing the window, so fullscreen(or changing your monitor resolution - this will shrink the available display area but each individual tile will appear larger) is your best option for correcting that.

2) This is because the screen is refreshing itself when you provide input. It might be better to skip the update when the input doesn't change anything - I'll take another look at the way I handle input, but that should be pretty simple to get rid of.

3) I've done that deliberately - I have it set up now so that the most recent message reflects the results of the last action the player took. Previous messages are available for review by checking the message recall. I originally had the player message first, and messages generated by enemy actions would appear last, and I found that to be more confusing. It's also worth noting that multiple enemies can generate messages for each action by the player, and the order of those depends on the rate of actor energy generation, not the effect they've had on the player(it might be possible to collect and deliberately order them this way, but it would require a lot of additional manipulation and even then might not be any more clear). I think I'll hold off on any immediate changes on this one and wait for more feedback to see if I can get a better sense of the general opinion on this.

I will point out that you can adjust message verbosity, filtering how much information you receive for each interaction. Combat tends to offer a lot of information, which can spam out the on-screen message window, but at lower verbosity settings, only the more important details will come through with each message, and this might help you get a better picture of the entire last round of combat.

4) Experience is awarded only when you leave a floor - the manual should have better information on the details of this with the current release, but the general idea is that if you move down to the next floor, you're awarded a small percentage of what you've earned in the dungeon so far(and the rest is saved for when you leave the dungeon itself), while if you exit by the entry staircase, you gain about 40% of your earned rewards and forfeit the rest, and if you leave by the exit staircase, you gain full rewards.

Note that gaining levels doesn't do all that much for you just yet(although it does have an effect even now), nor are the enemies balanced, since I am holding off on that until I have more features implemented. Bears are definitely a high threat right now(and there are worse things you might find if you are unlucky enough, or visit the deeper floors!), but once you can find better gear and change your equipment setup, as well as being able to use consumable items like the healing items from VA, they should become less of a challenge.


Thanks for checking it out. Let me know if you're not satisfied with any of my explanations, and of course if you find any other issues that seem noteworthy.

I'm working on adding additional content for the a.2.0 update right now, and I'll throw the screen refresh fix in there(as I don't currently have a separate release branch - I'll be sure to maintain one for releases going forward, though). Edit: This was very quick to handle and will be in the next release. Thanks for pointing it out.

[mihey1993]

Well ,since you asked - the game is a bit... chugging on each action. It feels much less fluid than VA was, or most roguelikes really, like it spends a lot of time calculating the move.
As with VA - i d like to see what i died from, not just the screen YOU DIED:D all of a sudden.
I also would like it if i could have the game memorize what setting i used last - i really do not like tiles graphics in general, so i d prefer to have always console view in start

[Sereg]

Do you mind posting your computer specs? I've been developing on a reasonably decent gaming laptop, so it's possible that I'm being inefficient in ways that haven't impacted my own testing yet. As a roguelike, I definitely want it to be playable on almost any computer.

Is there anything specific you're doing when it slows down like that? Combat, movement, level transitions? I know that saving and loading can take a bit longer, but I haven't noticed any particular slowdowns in normal gameplay.

As far as the death screen, that's just a placeholder for now. It will definitely be much more informative in future releases, complete with autopsy files like VA, as well as high scores and other useful features.

Edit: At your edit, I can certainly make the user profile remember display settings - this will be live in the next release as well.

[mihey1993]

It chugs on every movement action - it visibly takes it at least a second to process for some odd reason.
The problem seems to be with processor - even when the game is idle, it eats in 15-17 percent of my processor power:D
I got i5 6500 - 3.2 ghz.
it also slows down on exiting, and saving, as you also felt it;3

For now, since there is no such thing as use for exp level except full heal,and no equipment options, this is as far as i can test it i think?:D
as meeting a bear means certain death.

For combat - it is.... clunkier than i d want. since you have energy system , where for each action of mine enemy may get in two -three of his, and not necessarily after my own, i tend to suddenly find myself on square where enemy was since i countered him instead of hitting, and thus got moved. this is..jarring in experience.

[Sereg]

A second on every move? o_O  even when there are no monsters in sight of the player? The combat handler is pretty complex and has a lot going on(although even that shouldn't result in the sorts of delays you're seeing), but ordinary movement shouldn't have any reason to delay that long... that's very concerning, especially given your processor.

You're probably right as far as the extent of testing for now - the game doesn't have enough content to be very replayable yet, so at this point I'm mostly looking for observations like what you've made, things I've overlooked or otherwise failed to notice or worry about in my own testing(since that's usually focused on whatever feature I've just added, and I mentally skip everything else until I get to what I'm specifically looking for). I definitely appreciate your feedback so far.

The combat might need some review - you're right that the counterattack system can cause enemies to die somewhat unexpectedly, which can be jarring - especially with the slowdowns you seem to be experiencing. I do want to preserve that aspect of it, and I think it will be less jarring against more powerful enemies(who won't die instantly like the little spiders in the forest). It might require some adjustment - maybe counterattacks should be prevented from doing lethal damage, for example. I'll bear that in mind and remain open to making changes.

I will note that no enemy should be getting two to three actions against you - it's possible with the way the system works, but none of the enemies I've added so far have the ability to use it that way. I think the unexpected moves are entirely due to the counterattack system, not the energy system.

[mihey1993]

It got a visible delay on every move i try to make so that one is consistent - and as i said, for some reason java on your game eats a lot more than i d expect in idle mode where all that happens is few tiles changing their looks.

Energy system is all fine and good, many games use it, but maybe you could try ADOM approach? so whenever you make actions, monsters make action only after yours is completed.

and yes, problem is with energy and counterattack together making me move somewhere x3 however, i could have spider attack me before i move off the space i was in which also makes it seem like it attacked from a tile away:3

[Sereg]

Yeah, that's definitely unexpected - as you say, when the game is idling, the only thing that's happening is the GUI is on a loop refreshing the display, and that doesn't take up all that much processing power(unless Java is automatically tasking that to my GPU instead of my CPU - what sort of graphics card do you have?).

I initially had the player queued as the first actor to execute, but this resulted in the message obscurity I mentioned in my first reply - that is, the message directly generated by the player's action was not the one that appeared most recently. Now I have the player executing last, so the message corresponding to your action is on top. It'll work either way in the engine, and I'll keep it open and see what other feedback I receive - I'll definitely keep yours in mind.

The attack from a tile away is not really related to that - you'll queue an action, but the spider will reach the energy it needs to act first, request a decision from its AI(which will choose to attack the player since it is adjacent at that point), and make the attack, after which the player actor will reach the energy required for the action you chose with your keyboard input and move away. This actually wouldn't change even if I had the player at the first position in the engine's actor queue, because each actor generates a small amount of energy each game turn, and the engine simulates these game turns until the player has enough energy to act. Part of this simulation includes handling actions by non player actors who gain enough energy to act before the player does. The only real consequence would be to bury the message directly produced by the player's input, which I personally don't like(but again, will remain receptive to input on).

To actually ensure that the player acted first in all situations, I'd need a totally different engine concept - which isn't necessarily off the table, but it's something I'd be quite hesitant to do at this point.

[mihey1993]

i have geforce 1060 6GB - which would easily handle the load if it was going on it :3
As for energy and actors, hear me out.
Situation 1 - enemy and you got near one another. either your enemy has enough energy to get close and attack, or just get close.
then, you may have secret energy counter behind the scenes making player's move be the most important, and everything else is decided after it. so you decide to move. then, if enemy has enough energy, it moves after you, and then checks if remaining energy is enough for attack. not during your move, but after it had to chase you down.

in energy

start of the turn - example both just entered a world. for me player, i move once every 100 energy units, enemy once every 75.
so, first move we both go a tile. second and third too. on forth, i go once, and enemy goes twice, correct? so, in your current way, if we end up near one another and enemy got more energy than 0, it will always attack me before i leave my tile. while instead, it should follow me, and then eventually gain enough spared energy to move and attack:3

[Sereg]

Yeah, it doesn't look to me like either your CPU or GPU should be causing the problem.

Your energy example works as intended provided the player executes first. However, when the player moves first, that means other actors move afterwards, which means that the messages their actions generate appear after any messages generated by the player's action.

The question, then, is which approach is least jarring, and that seems to be where our opinions differ.

[mihey1993]

To be fair, from pure gameplay perspective, when it is your turn, u kinda expect that if enemy dies in it, it wont hit you before , ya know :D
Current message flow makes sure that whatever enemy comes aknocking, you can almost certainly expect that even if it takes one strike to put em down, they will get a bite in.

 in any case, i want to see what you will do with next update:D hope tormuse finds some time to try it too!

[Sereg]

So, I think I've found a solution that addresses both of our concerns.

I've reconfigured message flow to display in reverse order to the in-game message display, and re-ordered the action queue so that the player moves first.

This way the message resulting from the player action still appears at the top of the in-game display each term, but in its proper order in the message recall, and enemies are prevented from making in-between moves like the one you described. Unfortunately, I won't be able to push that out for testing until the next release, which I don't have ready quite yet. I'll try to get it finished up and posted soon, and after that I'll maintain a release branch for hotfixing bugs and correcting other minor issues, so I don't have to delay getting them out to testers.

Thanks again for your input.

[mihey1993]

No problem!
A minor thing you might want to add is always showing a message for where the stairs lead (whether it stairs or room entrance). It would help one understand where he goes without going there.

[Sereg]

All stairs(including the room entrances) do currently display a descriptive message on walk over, as well as on targeting with the 'l'ook command... is there something more specific, or different, that you're expecting?