LÖVE

What about STI? I've never used it's full potential, but maybe I'll be able to help?

4aiman wrote: ↑Tue Feb 14, 2017 12:55 pm What about STI? I've never used it's full potential, but maybe I'll be able to help?

I was having a weird offset issue, turns out the fix was grabing the coordinates via the gamera (gamera:toWorld) instead of just love.mouse.getPosition().

Anyway, the teething issues with STI are all but solved, so I'm plugging along copying the code from the orthogonal version to the isometric version. Should be back to all features next week (Saturday = no coding, busy).

I attached the current state of the isometric version. It's missing the FOV as well as most bells and whistles (character creation screen, inventory screen, etc.) but you can move around the map and the AI moves, too.

Niceeee! ^_______^

O_o

Iso-test, a minimalistic test, downloaded 40 times?!

Anyway the isometric version has almost reached feature parity with the orthogonal version. The GUI is there, the enemies and items spawn and can be interacted with appropriately.
The character creation screen received an additional button that enables you to start the game. To prevent starting the game accidentally, I disabled the esc to close functionality for this screen only.

What is missing:
- showing the FOV in a meaningful way (I'll have to look into stencils due to how STI works)
- non-hostile NPCs and chatting
- game menu

The isometric version is now equal to the orthogonal version. The only thing missing is somehow showing the FOV.

The library bug which caused you to get all identical rolls when creating character was fixed.


A short clip of the game in action

I also sneaked in a couple of improvements - the visible log above the bottom bar now always shows last 5 messages and a shield shows up instead of damage splash if the target was not hit.

Zireael wrote: ↑Tue Feb 21, 2017 6:52 pmThe library bug which caused you to get all identical rolls when creating character was fixed.

Nope, it wasn't... I'm getting all "6".
Also, Remember when I had all 18?

Well, that's due to the fact its is possible to drag just a couple of highest numbers and then re-roll until you get another high number.
The game should either enforce dragging all the numbers to the left or reset those to default every re-roll.

Keep it up

4aiman, thanks for the report. I'm sorry to say I wasn't able to squeeze a fix this week.


Pretty debug item creation screen


Funny bug with outline shader


Visibility overlay that allowed me to find a bug in FOV calculations

Changelog for this week:
Implement a debug menu
Implement a debug summon NPC option (creates a selected NPC next to the player, with some caveats - e.g. if we're missing the tile for it, we don't spawn to avoid crashing the game)
Implement a debug create item option (creates an item on the player's tile)
Implement "egos" in Angband-speak (item magical properties) - for now only for armors, for test purposes
Spend the rest of the day making debug item menu look pretty
The debug create item allows you to add multiple "properties" (see above), provided they don't conflict (e.g. you can only add one "material" or one "bonus"). Yaay for my own code, no more problems with a leather armor +1 +3 or mithril adamantine leather armor lol (speaking of, I should disallow some materials based on whether it's a leather or metal item, too)
Write a function to spawn an item with a defined property (e.g. "spawn a leather armor +1 at x,y") outside of the debug menu
Shuffle the treasure table/list to a data file (no need for it to bloat the Treasure class)
Suddenly remember I forgot the outline shader (funny bug along the way) and the Cogmind-style labels above actors/items
Discover a bug in FOV calculations thanks to the labels code, write a debugging visibility overlay, five hours later discover I had a typo in the "does this tile let light pass" function >.<
Draw actors only on visible tiles, items on visible tiles or those that were once visible
Write a wrapper function for a ROTLove library function to muzzle printing the whole Dijkstra map to console every time it was recalculated
Comment out/remove or move to log many debugging prints (the game initializes noticeably faster)
Adjust the label locations to prevent them overlapping

I would have done more if I wasn't busy trying to understand the ECS. I think the components would be a godsend for complex stuff such as the actors. But I'm stuck on how to make ECS work alongside inheritance.

For now, still rolling along with an old T-Engine solution for classes based on an obsolete Lua "module" keyword. Haven't found a LOVE class library that would allow multiple inheritance (many of my classes rely on it). Ran into loops when "requiring" stuff a couple of times so started to look at components (see above)...

I don't say I understand the stuff about "module" keyword, but here's a link to a seemingly relevant conversation: https://love2d.org/forums/viewtopic.php?f=14&t=83241
Maybe it'll help a bit.

I spent the last few days trying to speed up game's startup. I rearranged the loading order, so that actual classes and tiles are loaded AFTER you decide to start the game (since a player could exit at the main menu for some reason). This made the main menu loading almost instantaneous.
I removed some unnecessary debug logging and shunted the 'open log folder' function to a keypress, but still the game starts slow enough (3-4 seconds) to warrant adding some sort of a loading screen.

Here it is:



I tried to optimize it further, but hit a wall: That's right, creating four actors takes 0.7s... That's no bueno for something that's going to be called a TON of times. Simple maths says 10 actors would take 1,75s, assuming no additional overhead, and 50 actors would be 8,75s.

That's not kosher! I can't figure out how to optimize it further at this point...

Do you think switching to ECS would help with the actor creation performance problem? It's a huge showstopper and I've been making a Java port in which creating 4 actors takes 20 ms...