Lemma Soft Forums

Hi
I'm implementing a dungeon crawler and combat engine for my game red eyes in the darkness: The tainted blood
Original ideas thread about the game

As I have finished the first version of the dungeon crawler I would need people to test it out and give me feedback (thus a alpha test).
What I would like:
*Feedback on bugs
*Feedback on what feels good and what feels bad there and what is missing
*Feedback on planed features if anything feels missing or isn't good
*Also feedback on layout and design
*Feedbaack on any spelling errors (or gramatical errors)
*Feedback on loading times and lags
*....

Then a bit about what the crawler engine is about (features), and what I have planed and not planed to be part of the demo.
As it stands I'll upgrade the engine as the alpha testing phase continues and update it accordingly on this thread.
Current version: 0.31

Features:
*Move through a forest and increase/decrease enemy alertness (in this case wolves mostly).
*Fog can be turned on or off (by the program not the player)
*Combat ends when the enemies reach <=0 hp.
*Combat random enemies

Planed but not in now:
*Movement options: wait and rest (bandage wounds if bandages are in the inventory). Both decrease enemy alertness.
*More skills, more types of enemies
*Levelup system and xp / treasure gain from enemies
*Events (they are possible but currently didnt create any)
*Using bars instead of numbers to represent hp, mana and love status (question: Switchable via option in the option menu better?)
*Sprites for the enemies (I don't want to use placeholders so no enemy sprites shown till I have them from my sprite artist)
*Pic shown in the status display of: Group, enemy, love interests
*Better minimap (graphics instead of symbols and also other position...directly under the lover interests)
*Current ingame time and date to be shown on the screen and it changes as the player moves around
*Optional: Nighttime graphics
*Using keyboard to click on options instead of only the mouse as option.
*Sound effects
*Minimap using graphics instead of text for representation
*Effects of range (thus no melee attack in more than 0 feet dstance to the enemy)

Not planed:
*Music (music exists already but I don't think it is necessary at this stage of testing to use it)

---------------------------------------------------

Movement:
Screenshot
You move around by clicking on the arrows. With left/right/back changing direction only.
To the upper left the status of the group is shown.
Upper right the affection rating of all love interests. ??? means that you dont know the name of this love interest so far.
Bottom right a minimap with current direction is shown. (. = free, x= obstacle)

On the top right corner a small square is shown. This has 4 values: Green, yellow, orange, red and represents the alertness rating
of enemies in the area...thus how likely random encounters are.

Combat:
As combat begins enemies appear within a distance that is defined by the environment (in the fogged woods between 0 and 20 yards from you).
At the start of combat a random initiative order is defined (the higher your dex the more likely you will get to act first).
During combat you can choose different commands to use and if more than 1 enemy is present and you attack you will have to choose
which enemy to attack.
Screenshot
Left fro the affectionlist a list of all enemies is shown.


Download links:
Here(Only windows platform) Versioni 0.33
EDIT: This was a link to the old file (thus deleted. New file see posts below)

Change log:
v0.33:
*Eliminated "memory leak" (was an infinite loop) when the party looses a fight.
V0.32:
*Keybinding for movement "8","4","6","2","7","9"
*Added a turnleft and move ahead and turnright and move ahead button
*Added 2 new skills: Kick and headbutt. Kick does more damage than punch but is not as accurate. Headbutt does the least damage but can stun an enemy.
Both kick and headbutt reduce the own defense for 1-2 rounds (headbutt longer than kick).
*Added a few test sound effects
*Hit probability has increased
*Alertness level is reset after each combat (although if combat takes very long it will be higher than otherwise)
*Made some minor spelling checks
*

V0.31:
-Rebalanced battles so that wolves are now easier
-Corrected display of mob names when they were fleeing
-Removing enemies that fled or are dead from the list of displayed enemy statuses
-Disabling minimap during combat

I hope I get lots of input there...the more the better


Edit:
Current version of the file:

Needs keyboard navigation

A bigger difference between the hovered/selected arrows and regular would help.

What am I doing? Even for an alpha, a little bit of instructions would be nice, even if it's not in the full game.

Some of the background images aren't changing when Michael is turning.

A wolf appeared 0 feet away? Sounds weird. Why not just say I was attacked by a wolf?

It said "a wolf appeared", but then I discovered I was being attacked by 2 wolves. That would change my decision to run or fight.

The combat involves clicking the same menu option over and over until someone is dead. No real skill, but plenty of time wasting.

"hungry wolf dodged Michael Quinn's punch". Needs capitalisation.

Is there are reason for using his full name every time?

"A hungry wolf and a hungry wolf and a hungry wolf appeared 0 feet away". Why not just say "You were attacked by 3 wolves"?

How did I get bitten by a wolf that was 20 feet away?

1 step, Fight. 2 steps, Fight. 1 step. Fight.

Game hangs after getting killed. Some kind of memory error.

Needs keyboard navigation

In now

A bigger difference between the hovered/selected arrows and regular would help.

Will look into that

What am I doing? Even for an alpha, a little bit of instructions would be nice, even if it's not in the full game.

Currently only wandering around and getting into fights (the poor wolves). During this test I only want to test the engine and the combat system.

Some of the background images aren't changing when Michael is turning.

Can you give me some examples? (best screenshots). So far there were a few situations where they looked similar but only through coincidence of how the map
was structured.

A wolf appeared 0 feet away? Sounds weird. Why not just say I was attacked by a wolf?

Will change that later on

It said "a wolf appeared", but then I discovered I was being attacked by 2 wolves. That would change my decision to run or fight.

Hmmm that is strange. It should say "a hungry wolf and a hungry wolf appeared". I wasn't able to get the same problem. Can you try again there and givev me a screenshot?

The combat involves clicking the same menu option over and over until someone is dead. No real skill, but plenty of time wasting.

I added now 2 more skills to use: Kick and headbutt. In the later game players choices for levelups and also found weapons will increase the range of skills available to choose from. Each has its own + and - (I saw that I still need to put in when a skill has a defense or offense modification will do that next then).

"A hungry wolf and a hungry wolf and a hungry wolf appeared 0 feet away". Why not just say "You were attacked by 3 wolves"?

Currently no plans there but will think about it if I can do that easily or not.

1 step, Fight. 2 steps, Fight. 1 step. Fight.

For this test the start chance is 70%. I now modified it so that after a fight the chance is dropped to 0.

Game hangs after getting killed. Some kind of memory error.

Will look into that tomorrow.

How did I get bitten by a wolf that was 20 feet away?

Effects for range will be added later on (if you dont have a ranged weapon you need to close distance...same for the enemy).

"hungry wolf dodged Michael Quinn's punch". Needs capitalisation.

Implemented in the new version.

Is there are reason for using his full name every time?

Sadly yes at least mobs are named very similalrily :/


So I'll upload the new version tomorrow after looking over a few more of the listed points..
Tnx so far btw I hope I'll get more input soon.

Updated the engine. Eliminated most problems there.

Tnx for the input so far and I hope that I'm getting more inputs there the next 2 days.
Till friday I plan on using all gathered inputs to see weaknesses in the engine and eliminate them.

Beginning friday I'll rewrite the engine (as by then I plan to have a good prototype) and make the sourcecode easier, less redundant and a bit more flexible
(will have to completely redo how I implemented the "skills" in order for me to be able to use inventory there also and also make them more flexible).


On another note for the combat itself.....should all chooseable buttons be "clickable" also via keyboard? 1st option as "1" every time,... ?

Oohkay~ I'm excited for your game.

Things to point out:
-Tutorial:
Even for a demo, you might want to put a tutorial for people who are interested in trying out but have never played a dungeon crawler before. Most people here are into VNs, so they might not have played much dungeon crawlers. I'd say the interface is fairly simple, so there's nothing to say there.
-Moving:
You might want to make the character able to move with keyboard controls. Ren'Py games can let you use the up and down keys to already select which option you want to choose, but still letting the player move directly using keyboard is better for a game like this with lots of moving about. ("OTL Now I realise you can move by pressing the number keys... Please make a tutorial to inform us...)
-Interface needs more polish:
For just testing out a game, I understand that it's very rough around the edges, but you definitely need to make it more polished. I can barely tell how close I am to a tree just by looking at it, in the full game you would definitely need transition images. The butttons and stuff also would need to be different from plain old Ren'Py text.
-What's the use of the affection bar?
Are you just testing it? It doesn't seem to have much use in the game. It's just there. Also, in the full game you might not want to stick it there so glaringly. It would probably break the immersion people have and make them realise that they're romancing lines of code.
-Yellow square in the corner:
o_o What's it there for? At first I thought it was a glitch, then I thought it was a bar to signal if the enemy was aware of you, then it did nothing and I was like "wut".
-Map is screwed up.
You probably made an error in the map, the right part of it, while it says that the space is empty (.), it treats it like an (X) and poor Quinn keeps bumping into it.
-Grammatical errors:
You forget your full stops. The wolves appearing at X feet is also weird, you might want to put something like "A wolf appeared nearby." Normal people don't estimate where a wolf appears at how many feet.

It's a pretty nifty engine, and I think with some improvements and more polish it could be really great.

RunicV wrote:I can barely tell how close I am to a tree just by looking at it, in the full game you would definitely need transition images.

It is possible to use transitions that give a feeling of movement. This could definitely work in your favour if done right.

Distance

The feeling of distance CAN get better as soon as I have an artist doing the graphics there (the trees I put myself there and......graphic is really not something I'm good at^^')

-Map is screwed up.

This will be corrected in the rewrite (currently it is extremely hard to make maps, but I have a plan there to improve taht (using a csv that I load instead of manually typing in a list).

-Grammatical errors:
You forget your full stops. The wolves appearing at X feet is also weird, you might want to put something like "A wolf appeared nearby." Normal people don't estimate where a wolf appears at how many feet.

Hmmm full stops: That will be corrected in the rewrite. For teh distance. Problem is that IS important. As the finished version will have melee and ranged weapons
and you can advance (and also the enemy) so ditsnce is an important aspect there.

-Moving:

I'm also thinking of trying to use the arrow keys for movement but not sure if the engine will allow that but that will be part of a test of the finished engine then.

The butttons and stuff also would need to be different from plain old Ren'Py text.

The buttons will be repolished in the final version. In this one I wanted to test functionality and screen layout primarily.

-Yellow square in the corner:

IUt is how alert enemies are to you.......green: no enemies present, yellow: Enemies present and random encounters possible, orange: Enemies searching for you, red: Enemies closing in on you. It resets to the minimum alertness for the map after each battle (but can be a bit higher if you took too long in the battle)

-What's the use of the affection bar?
Are you just testing it? It doesn't seem to have much use in the game. It's just there. Also, in the full game you might not want to stick it there so glaringly. It would probably break the immersion people have and make them realise that they're romancing lines of code.

We talked that out in the renpy IRC a bit. I have had another idea there (although that one needs the finished sprites ther). What do you think about
me putting the faces of love interests there instead of values or a bar (thus angry face,neutral face, happy face, blush to represent hate, neutral, friendship,love)

Also I put it there only for optical reason as I planed it so:
Left side: Party
Middle: Mosnters
Right side: Possible romances (even if currently out of party or in party)

Wolf wrote:For teh distance. Problem is that IS important. As the finished version will have melee and ranged weapons
and you can advance (and also the enemy) so ditsnce is an important aspect there.

Not sure how you feel about it, but I thought I'd suggest having something that mentions range, for example "You see 3 wolves 20 feet away." Then have options to attack with a ranged weapon.

Wolf wrote:I'm also thinking of trying to use the arrow keys for movement but not sure if the engine will allow that but that will be part of a test of the finished engine then.

Just bind the arrow keys to the same functions that are already used for movement.
http://www.renpy.org/wiki/renpy/doc/reference/Keymap

Wolf wrote:
For teh distance. Problem is that IS important. As the finished version will have melee and ranged weapons
and you can advance (and also the enemy) so ditsnce is an important aspect there.
Not sure how you feel about it, but I thought I'd suggest having something that mentions range, for example "You see 3 wolves 20 feet away." Then have options to attack with a ranged weapon.

That is exactly the plan

Wolf wrote:
I'm also thinking of trying to use the arrow keys for movement but not sure if the engine will allow that but that will be part of a test of the finished engine then.
Just bind the arrow keys to the same functions that are already used for movement.
http://www.renpy.org/wiki/renpy/doc/reference/Keymap

tnx there

After quite a few problems with displaying the graphics (and a few ways that didn't work out) I managed to get a new (more flexible) version of the crawler running.
Additionally to the added flexibility, the number of pictures needed from artists per tile is reduced to 2. 1 front and 1 side image per tile (aka wall).

What is in:
-Fog
-Different types of darkness (the cave one starts in is dark in tthe center and not so dark at the entrance. Also not so dark is the part of the cave near the west wall).
-Different types of ambient lightning (although currently set to daiylight for this test)
-2 types of tiles (aka walls. 1 green one representing trees, 1 gray one representing cave walls)
-Different types of special lightning (magical light and catlike both of which are deactivated for this test)
-Movement possible with arrow keys now
-Colission solving

What is not in:

-Battles

What would I like to know:
-How does the darkness effect look like
-How does the fog effect look like
-Are there any errors in how the tiles are displayed (thus gaps, inconsistencies,...)
-How is the distance representation. Do the tiles have to scale harsher in distance (thus should they look smaller than they currently do for each different distance?)
-Minimap: Does it look better if only "blocked / nonblocked" is displayed, or is the current more detailed type ok / useful
-Tiles themselves: If there is any distortions in the lines (didn't see any but that is only my eyes so far)

The file: As always would be nice to get some comments and feedback (positive and negative feedback helps there) tnx

Edit:
Had to replace the file as the configured archiving options and the commands I had used to create/display some images caused troubles. But now should all be ok again.

Prelude:
As I had to improve the engine I tried a few new approaches. Even tough ppl told me that raycasting and even pseudoraycasting is not possible in renpy
I just used a bit of my sparetime to proof that PSEUDOraycasting IS possible.

This demo has no combat included (as I'm redoing characters,.... completely), but else you can move through the small world, time passes, light changes and there is even
fog.

For light and fog I use pseudo raycasting. To present the tiles themselves I use a very abstract pseudo raycasting (which makes good use of how you can have overlapping images with different Z orders in renpy).

Features:
*Walk through a 3D area
*3d Tiles consist of 2 pictures (1 front, 1 side), which are dynamically scaled and positioned
*All pictures can be see through, which enables the display of open doors, windows, cave openings and even small details like flower tiles, or tiles with stalagmites hanging where you can see through and walk through.
*Fog can be created for specific map cells, and the more map cells have fog in them, the denser it is.
*Pseudo-dynamic lighting. Thus every map cell can have its own lighting, which can be modified by lighting that comes from the player AND also lighting differences due to day/night cycles
*Day/night cycles. Time passes as one walks through the map and a day / night cycle happens, which modifies the lighting of the seen area
*Maps are loaded from mapfiles (.csv files) which makes for easy modifications



Graphics:
Tile graphics (with 2 exceptions) are made by: ThisIsNoName
The head of the player character is part of a picture made by: Shadilyn

The 2 tiles that are not made by ThisIsNoName (the smalal flowers on the ground, and the stalagmites) are Pseudopictures made by me, to test/showcase
how flexible the engine really is.

The current version:
Problems I ran into:
After scaling pictures (with fixed new x and y values), I registered discrepancies between the calculations I made and the real situation
(thus the pictures being 3 pixels too short in x, or too long, and too high in y and too low,....).
I never found out WHY those discrepancies came into existence (a forums question there is still unsolved) and I had to manually position the pictures
with try and modify (took hours that way).

Comments on raycasting:
Like I always said pseudoraycasting is quite possible. With raycasting itself I saw that the calculations can be done without problems (fast enough), but presenting the
image is the real problem there as renpy can't print 1366 slices on screen in under 4 seconds (on my machine at least). There is quite probably a workaround for that,
but honestly that isn't really needed by me as I'm happy with how much flexibility my algorithm offers so far already, so I didn't make a real raycaster and went for
pseudoraycasting instead.

I'll try to be as clinical as possible with my views. Nothing is meant to offend, only provide feedback.

• The contrast between floors and distant walls is very sharp. Unless right next to the wall, generally they appear black, but the floor is rather bright.
• Perhaps the arrows could be changed to make it clearer whether we are turning, side-stepping, walking backwards or doing a 180 degree turn.
• The indoor wall tiles aren't tiling well. It's very easy to see where one ends and the next begins.
• It looks very odd that we can only see a short distance in front before things become pitch black. For example, I looked at the cave exit, and it was black outside. I took one step and it's a bright forest.
• Covering the lines between ground and wall with grass was a good idea. Okay, that's not really an issue, but just thought I'd mention it.
• Having trees as wall textures looks very odd when the tree image is cut off partway when there's a corner.
• In some places I turn, and the new wall is exactly the same as the previous. Makes it hard to get a feeling of movement.
• I was a bit confused about what the starting area was. It has flat walls, like a building, but also contains stalagmites, like a cave.

Hi no prob I love feedback got way less so far than I had wished (at least got an alpha tester who helped me find errors so far^^)

TrickWithAKnife wrote:I'll try to be as clinical as possible with my views. Nothing is meant to offend, only provide feedback.
[*]The contrast between floors and distant walls is very sharp. Unless right next to the wall, generally they appear black, but the floor is rather bright.
[*]It looks very odd that we can only see a short distance in front before things become pitch black. For example, I looked at the cave exit, and it was black outside. I took one step and it's a bright forest.

Did you have a look at the ingame clock there? After a few steps night should end and day should begin (thus all getting brighter). Additionally the cave interior itself
is darker than the outside.
The floor itself is known (floor and ceiling is a static/nonmodified background image currently. The flowers and stalagmites were a test into the direction if I could tile as
good as all things, which is the necessary prework I need to created floor and ceiling tiles in order to get the brightness correct for each floor and ceiling tile).

[*]Perhaps the arrows could be changed to make it clearer whether we are turning, side-stepping, walking backwards or doing a 180 degree turn.

Noted and currently looking at other RPGs (etryian oddissey for example) to see what shapes are best there.

[*]The indoor wall tiles aren't tiling well. It's very easy to see where one ends and the next begins.
[*]Having trees as wall textures looks very odd when the tree image is cut off partway when there's a corner.

That is a known problem. But from what I saw at least not directly engine related, but graphics related.
EDIT: Ok second glance I'm not completely sure if the "tiling well" problem is graphics related. could be that it is because of the different brightnesses of the tiles
(thus engine related). Will look into that. Cut off thing is graphic related though.

[*]In some places I turn, and the new wall is exactly the same as the previous. Makes it hard to get a feeling of movement.

Can you go into further details there?

[*]Covering the lines between ground and wall with grass was a good idea. Okay, that's not really an issue, but just thought I'd mention it.

That was the artists idea (and yepp was quite a good idea there!)

[*]I was a bit confused about what the starting area was. It has flat walls, like a building, but also contains stalagmites, like a cave.

Starting area is a cave, and then a small forest path with a clearing beside it.

In some places, the locations of walls are the same when I turn, due to the map design.
In these cases, the view can look exactly the same, giving no indication of movement.

When I'm in the forest, I could see the cave from a distance, which looks like a grey building, possibly due to the textures being visible, but of a limited height. Or perhaps the reason I'm seeing it is something else.

Would it be difficult to add on screen variables for current map location and direction? Of course it wouldn't be suitable for the final game, but it could be helpful for testers when trying to explain where they encountered issues.

TrickWithAKnife wrote:In some places, the locations of walls are the same when I turn, due to the map design.
In these cases, the view can look exactly the same, giving no indication of movement.

When I'm in the forest, I could see the cave from a distance, which looks like a grey building, possibly due to the textures being visible, but of a limited height. Or perhaps the reason I'm seeing it is something else.

Would it be difficult to add on screen variables for current map location and direction? Of course it wouldn't be suitable for the final game, but it could be helpful for testers when trying to explain where they encountered issues.

Ah I c. Hmmm maybe a background where it loojs more like a mountain which is partially "overwritten" by the entry map would be good there.

For the current map location: Is there none displayed at tthe bottom right of your screen? (should be)