Really nice! Sometimes a tiny bit laggy but I love the general style and phylosophy behind it! Keep up the good work!
Inner Demons Dungeon Crawl
Utilize Trust, Faith, and Hope. Acquire abilities like Independence, Compassion, and Intuition and face off against the darkest adversaries out there: things like Challenge, Ridicule, Doubt, and Struggle. Discover if you act in the interest of self or the interest of others. Grow your Courage, Will, Patience, and Resilience until you’re ready for anything.
UpdateNov 2 bug fixins
How to play:
Check the "options" for instructions :)
Current Bugs: (0.0.6)
- In the options, the buttons to switch from 32x32 tiles to 64x64 tiles are mismatched
- The keyboard shortcuts don't work anymore. Use the options screen instead. It was causing me some lag to keep the options loaded in the scene for keyboard shortcuts - the options menu fixed that :)
- Battle screens are broken: in this update I redesigned the game from absolute values to relative values, this will require reconstruction of all the battle areas.
- Only the first 3 areas are accessible. I redesigned the codebase to use a more "modular" approach where necessary functions are loaded as needed; this allowed me to achieve much better performance, but will take some work to redesign the levels to take advantage of it.
- A bug was uncovered in the controls that may leave some buttons truncated on mobile device; it was my fault as I forgot to include the scaling function in the recent export. Hopefully fixed
in the next update
- Mobile controls are working, but largely untested. I made a lot of changes to the source and it now runs much much better on mobile
This should be considered a pre-release stage game distributed for feedback purposes. It is playable but you should expect to find bugs. Other feedback, like improving the relationships between skills and adversaries is also welcomed.
For a full list of credits, click "options" and then "credits"
Thanks for trying.
|Updated||26 days ago|
|Platforms||Windows, macOS, Linux, Android, HTML5|
|Genre||Role Playing, Adventure|
|Made with||GIMP, Audacity, PixiJS, GDevelop|
|Tags||3D, dungeon-crawl, Dungeon Crawler, gdevelop, Pixel Art, Singleplayer|
|Average session||A few minutes|
|Inputs||Keyboard, Mouse, Gamepad (any), Touchscreen|
Click download now to get access to the following files:
Log in with itch.io to leave a comment.
Yes I've noticed the lag, particular in the beginning of the scene with the transparent wall; it gets a bit worse as more npcs are added. I was a bit zealous in making the scene too large with too many objects in that small area.
I wanted to make this scene bigger than it currently is, but after noticing the lag I've changed my strategy and will start branching off into different scenes rather than continuing to add to this one.
you can also try to dlete objects to far away to see and recreate them when approaching. Like you have external layouts and zones, and when you get too far away from a zone, it deletes objects in it, and when approaching it again recreate from exernal layout
I also want to do some comparisons to see how I can achieve the highest frame rate.
Noticing the lag as I put in more objects, I started to use just 1 object (what I call the faceless npc) and shade it, but it occurs to me that from what I've learned of GDevelop, one area it typically does really well is in handling lots of objects. I've heard of some people with thousands of objects in a scene with no lag - so I may have been counterproductive. I want to make 2 different experimental scenes, 1 with 10 different npc objects, the other with 10 of the same npc object shaded differently and see what gives me the highest frame rate.
With some advice from https://mikhail-pomaskin.itch.io I was able to consolidate some code. I was running the events that move and scale the objects 4 times, once for each type of object. I've consolidated all the objects into a single group and now running the events once for all objects which gave me a noticeable improvement. It could still be better, but I noticed it immediately.
Typically I am able to run on my dilapidated hardware about 30 fps - which may not seem very good, but given that it's displaying 3d in a program that was never meant to display 3d, I think that's not too bad.
Regarding deleting/creating objects - I was doing something similar trying to fix some display issues. I was using the objects scale to determine when to hide an object. It didn't seem to affect performance in any noticeable way.
I wonder if it would be good to employ this method of deleting and creating objects on the fly depending on distance from player, but perhaps run it only every second or two to conserve resources. Or maybe delete the objects in every frame, since that seems less cpu intensive, then create the objects as needed once every second.
Thank you for your ideas :)
I tried a similar solution (removing / creating walls depending on the distance), the result was not very goodthe - fps increased, but was not stable.
So far the best thing to do is to move the wall sprites where the player is looking with the help of "rays". And I also reduced the number of "bases" and wall sprites. There is an example of this optimization:
there are only ~ 700+ (wrong in the first time) bases and 720 wall sprites. Sorry for my English))
I tried using distance and raycasting but it didn't go very well for me, it made the lag worse. perhaps the raycasting was too broad? I've not used it before (raycasting) so perhaps I wasn't using it the best way.
I really like the idea of using a single base to make multiple wall sprites.
Of course, there may be another solution, the idea of controlling the drawing range using sprite scaling did not occur to me, i trying this later))
Deleting objects may be overkill indeed, but it would definitely be worth it as each objects gets lots of calculations applied to it for the 3D effect. What I recommend doing is doing a big hitbox arround the player as field of view. Only apply the mathematics to objects in collisions with that FoV object and hide the others to not generate anyy visual glitches. This trick should greatly improve performance. Then maybe you already have something like that in your code, as it’s the most obvious and basic optimization…
I was actually just working on this now. It not only helps improve performance but gives it a nice creepy effect with the shading around the players field of view.
Regarding the slow-down when approaching corners due to the multiple rays hitting: I have been working to make npcs appear, and have figured out a way. I put the npc images as animations of the walls, then set an instance variable for the ray obstacle for the npc, which passes from the obstacle to the sensor to the wall with an extra condition during wall creation. I put an npc in a corner, and it helps the lag a little by deflecting some of those rays from hitting the same spots.
However, it creates a minor display bug in the wall behind the npc, since the rays don't pass through it.