Sunday, 2 September 2018

Demo building



It's nearly time to show everybody a glimpse of just what the hell I've been up to these past months.
As you can see from the picture above, things still look pretty barebones right now, so I can't say for sure when all this will be ready.
I don't want to shoot myself in the foot with an overly optimistic date, but I'm working hard to make it as early as possible without releasing v0.0.1 bullshit.

This week I mainly occupied myself with writing a short demo scenario where you'll get hands on with all the main mechanics, so you can see if you like it and I can figure out what I can do to improve them for the main game.

Progress:
- Finished up remaining work on hentai engine, including better speed change turnaround and C-meter grinding sweet spot
- Created tilesets for the upcoming demo (really feels great to work on some new art after months of the same rooms)
- Created some rooms for the demo
- Tuned how doors, fixtures and NPCs differ behind the scenes
- Tackled a huge lag spike on battle start, still not perfect but seems to be a once-per-session framerate dip, with subsequent battles not slowing things down. Will get to later.
- Wrote out the full story for the demo scenario, estimating about 15 to 20 minutes long, just enough to give an impression of how the game will look, run and feel.
- Any window that can be opened with number keys can be closed with them too, feels more intuitive and comfortable. Trying to maximise comfort of 1-handed play this time.

Improvements:
I wrote some small functions to solve persistent Lateshifter issues:
Default RPGMaker system for movement is really only good for pokemon style cutscenes, where all action and player input stops, a character walks onscreen, says something, then walks back out of the scene or remains stationary.
The main problem I had in Lateshifter which accounted for 95% of all bugs is that I wanted NPCs to move around independently while the player is also able to move.
This meant the player could get trapped by npcs or the player could be move-routed into a wall because all movement is relative and requires the moons aligning to not go wrong.

So I've hopefully solved all those problems with my new system. Now I use the builtin pathfinding that seemingly only gets used natively to make the player path toward location of mouse/touch input and for "move toward / away from" movement route rules.

Old system:
>Punch in relative-to-current-position movement directions that should get the npc to the desired location
>Move up, move up, move up, move left, move left etc.

>Oops, you're lodged in the fucking wall / a move got dropped because you walked in front, ruining the rest of the movement, the NPC didn't end up where they ought to and now the whole flow is broken, hope you saved! (SIKE, saving fucks up the move routes too! :DDD)

New system:
>Punch in "walk($gamePlayer,4,4,true);"
>If the player is not at position 4,4, path there, walking around any obstacles (including ones changing while en route) and resume the story flow once he gets there.

I'll expand this later to be smarter, checking if 4,4 is occupied and if so an argument for whether it's acceptable to pick a square nearby to path to instead, or to make this npc able to just walk through the blockage, but it SHOULD be a tight enough ship to not need these yet.


That's about it from me, I wrote a few minutes of new music for the demo this week and did some romancable girl design, physical and personal.
For the rest of today I'll be scripting the broad strokes of the demo with placeholder sprites, then when that's all done I can fill out the placeholders with final text, art and music.



Thanks for reading, I hope you're doing well.
Oko

1 comment:

  1. i am very excited to see what you can do. your distinct aesthetic and writing is always a sight to see. :)

    ReplyDelete