|
|||
| Views: 694,134 | 06-28-21, 01:24 am | ||
code block | Thread review | |
|---|---|
| Kawa |
Yes, I much prefer seeing NPCs that can go faster than the player (be it because their SPEed is maxed, or because they have Haste) actually move instead of teleport. If the NPC gets two moves for each one of the player, they visibly jump over the spot they moved into on their first step. This gets a little silly and confusing when you're on a diagonal, as the player cannot move diagonally, but the NPC seems to take a single diagonal step. It gets worse when the NPC is fast and you're slow, because the jumps have been doubled. :luna: And that's why I rather prefer it this way. Here's that Youtube video I made again, which shows the intended speed. It obviously shows a debug build, which has unoptimized code (the factor I've found to cause noto's speed difference and apparently yours, now). And on my system, with my admittedly bad sense of seconds-or-smaller timing¹, it seems to go about as fast as a release build. I suppose there are certain things to try, such as increasing the update timer's interval from 10 to something higher, so that a turn in a release build takes about as long as a turn in that video. Not a clue what that'd do to a debug build's speed, though. At least not on my system. Notostraca still hasn't returned, so I haven't had a chance to have him try the latest build, and so I still don't know if the single-tap double-move thing is fixed for him. Assuming it is, I hope we can close this chapter soon. I feel like working on leaving bodily fluids all over the place. <small>¹ it's a wonder I can play rhythm games, really.</small> |
| PillowShout |
Well, I just tried it again in both debug and release using the newest commit, and while it's still slower than it used to be, it's much better than the half second turn time. To test it, I walked the character from one side of the screen to the other and timed how long it took them. For debug mode it took on average 11 seconds to cross or 11/80 = 0.1375s per turn. In release mode, it took on average 9 seconds to cross the screen or 9/80 = 0.1125s per turn. Using a build from the 25th, I tested it the same way and found that in both release and debug it took me on average 6 seconds to cross the screen, or 0.075s per turn. What that means is that turns are now taking between 83% to 50% longer, and it definitely feels like it. I'm not sure if you wanted to slow noxico down from how it was before, but as a matter of personal preference, I liked it better when it was faster because it felt more responsive and walking around didn't feel as arduous as it does now. Admittedly, seeing the entities move around through each turn does look better than just having them jump, but I'm still not entirely convinced that it's worth the performance cost. |
| Kawa |
What's funny is that notostraca, when I asked him to confirm it wasn't just me, revealed that release builds reacted too fast for him: • On my system, Release and Debug builds run just about equally well, matching the Youtube video, assuming there's nothing on stdout in the debug build. • On noto's Win7 64 "fast-ish laptop proc", the Release build I gave him goes so fast he takes two steps for each single sharp tap. Debug build matches the video, and the special "Debug build with Release-style code optimization" is too fast again. • I don't know which of the two you were referring to when you said it's sluggish, but there's something rotten in the state of Denmark. So I made some timing changes -- eliminated the time check in Game.Update(). On my system, both builds, again, run equally well and roughly match the video. I'm still waiting for noto to return from his pingout so he can give it a try. |
| PillowShout |
Yeah, having had a look at some of the top level code, I gotta say that it's kind of a mess and could really do with some refactoring. There's a fair bit of spaghetti code going on and it's honestly hard to tell when or where these things are getting called. Also a good refactoring would definitely help with tracking down bugs like that last one. Maybe you could also try to pull the screen updates out of the game updates. That way even when the frame rate drops a bit, the game will still play at the same speed. I know this would mean having to make the sceen update asynchronously - which would be a major pain in the ass - but it could help to make things run a bit smoother. Just something to consider if you're feeling ambitious. |
| Kawa |
It's not redrawing the entire screen, only the parts that changed. Personally I prefer it this way as fast opponents no longer teleport -- you can see them actually move now. Still... half a second? That's just not right. It should be more like this. Now admittedly, I added a thing to count how many times Board.Redraw() was called between every Player.EndTurn() and put it in stdout -- four or six at the start, then zero. Started a new game... and then I noticed that it was flushing and reloading neighbor maps every turn. As if the neighbors didn't update and thus were slated for unloading and actually got there. Load and flush are also written to stdout, after all. Knowing for certain that it wasn't redrawing the entire screen, I removed that counter thingy again. That was the only change since yesterday. But the strangest thing of all is that it stopped flushing neighbor maps. |
| PillowShout |
Yeah, I just caught that bug recently when I was playing around with the new timer system. Speaking of which, after you made the switch to the DoomRL style timer, the game really started chugging for me, where each turn was taking about half a second to complete. I noticed that the game seemed to be redrawing the screen several times per turn, and I'm thinking that might have something to do with it. |
| Kawa |
It's sad to hear that. In better news, we now have biome-specific random clutter. Trees and rocks and cacti oh my. Edit: oh and the pony content let me know that your scheduler and my expectations didn't work together well. Now they do. Expected characters had no schedules. |
| PillowShout | Honestly, I'm not sure how long it'll be before I manage to get my shit together. If you want to bump up to the next version and publish a release, then go right ahead. Otherwise you might be waiting for a while. :( |
| Kawa | Travel system, timing, UI, scheduler, stability... I think this is worth a bump to 0.1.2. The only reason not to is Pillowshout's checklist. |
| Kawa | Added the ability to read books and raise stats with them, and to use an XInput gamepad. |
| Kawa |
Speaking of vendor mode, I added actual vendors. Basically, for each town being generated, there's a 50% chance of a non-outskirts board to have a vendor. Once one is placed, the chance lowers for the next board. Vendors have a "role/vendor" token added, plus a random amount of money (at least 1000 I already have an idea on how to do vendors with specific kinds of items, but for now they'll just sell random gargbage. Fun thing to try: have a vendor within talkin range, and empty their closet. Immediately talk to the vendor and sell them as much of their own shit as you can. You will have most if not all of their money and not be attacked, since you're no longer carrying stuff with their name attached. I should make inventory management take a turn. |
| Kawa |
I was like, "if I filter them out in vendor mode but not container mode, it'll be inconsistent, even though the two screens are literally the same code with a few mode checks in. Also, if I filter them out, it'll be inconsistent with the inventory screen." So I just shrugged and decided I'd tackle the alternative when I add error feedback. |
| PillowShout | I figured that you might have, but I just thought I'd bring it up on the off chance that you didn't. |
| Kawa | I considered filtering equipped stuff, actually. |
| PillowShout |
Yeah, I tried out the vendor thing, and I'm happy that it means we're one step closer being able to buy equipment. One complaint I have is that it'd be nice if equipped items were filtered out, seeing as you can't buy/sell those anyway. The armour and attacks thing is pretty cool, and definitely adds a bit of strategy to combat. I guess now I have a reason to look what my opponents gear, rather than just their "equipment". :awsum: |
| Kawa |
Instead of doing the villager scheduler, I added a skin vs weapon defense multiplier thingy. I also cracked compression for the MIX system, reducing the size of Noxico.mix from 388.238 to 142.935 bytes by GZipping all the .xml and .txt files contained therein. Also there is initial support for vendors. Did I mention that yet? |
| PillowShout | What I'll try to do then is to make the changeling rapes adaptable enough that they should work for ponies as well. That way it won't look too weird if the player happens across any rape-happy ponies (Like ones that have spent too much time in Nox). |
| Kawa |
...either share the changeling scenes in much the same way they share good sex, or not rape. In fact, I'm thinking of making that a cultural flag. So if a hostile is horny enough, it checks their culture to see if they'd be willing to victory rape at all, and if they're willing to be unfaithful. That last bit is not a joke btw there already is a "monogamous" setting in the culture data. |
| PillowShout |
Ah, alright then. I think I need to start running this stuff by you more so I don't end up doing this again. I am curious though: What should the ponies do when you try to steal from them or something that would otherwise make them hostile? |
| Kawa |
As I just snuck into your gdoc: Ponies are never hostile. They only appear in villages and can thus not be raped, nor can they rape you. The player, as a pony, can rape hostiles. Changelings can be considered "dark ponies". They appear in villages as well as in the wild, but rarely. Only those in the wild are marked as hostile and can thus rape and be raped. They can share most scenes with ponies, the only difference being their disposition (more Renegade than Paragon), hole-filled legs, and insect wings. So no, those are not intended to happen, but the changelings let you keep your 10%. You're welcome. |