|
|||
| Views: 852,814 | 05-19-24, 05:56 am | ||
|
|||
| Views: 852,814 | 05-19-24, 05:56 am | ||
| PillowShout |
Posted on 03-18-13, 04:37 pm in Internalizing the JS engine
|
|
Posts: 81/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Is there any way that internalizing them could reduce performance at all? Because if not, then I think having them all in one file is definitely the way to go. Also, in that respect, I think it might be a good time to try running a profiler on Noxico and see if we can't get rid of a few performance bottlenecks. I've noticed that any time there's more than 30 or so scripts running per tick, it causes the game to slow down quite a bit. It's possible (and fairly likely) that some of the code I've been adding has been less efficient than it should be and it'd be nice to see where the program is spending most of its time. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-19-13, 09:00 am in Pathing bug inside MoveTo (revision 1)
|
|
Posts: 82/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Jesus, this took me forever to figure out! I finally discovered why some of the Boardchars kept trying to run into walls whenever MoveTo was called by the scheduler.
When the constructor was being called without a board being passed, it caused UpdateWalls to try and update using some empty board. This meant that the as far as the mapper was concerned, the entity was in an open field, and hence why it couldn't see the wall in front of its face. The fix is of course maddeningly simple:
And so now, entities that are told to move by MoveTo, can now actually go where they need to be. Now if you'll excuse me, I need to go to bed. x_x Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-19-13, 07:04 pm in Internalizing the JS engine (revision 1)
|
|
Posts: 83/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Hmm, interesting. It's good to know that Jint isn't the culprit, but I wonder then if there's anything we can do to either eliminate or redistribute some of those larger spikes? Maybe try initializing certain variables on load rather than first update?
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-25-13, 07:44 pm in New UI (revision 1)
|
|
Posts: 84/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
I'm really liking the new UI you showed on tumblr (finally, a fucking health bar!), but I noticed that there was quite a bit of blank space, so I figured I'd toss together some quick suggestions on how we could use it. 1. Showing status effects. Knowing when our character is starving or even just really horny could definitely help us to take care of them better. I've lost count of the number of times my character starved to death just be cause I wasn't paying attention to my health, so being able to see at a glance that they're starving would be pretty damn helpful. 2. Showing relevant skills. This one would be a bit more contextual and would probably only be useful some of the time, but knowing, say, how good our character's sweet talking skill is when we're trying to convince an NPC to do something would not only act as a quick check of our chances, but also give new players a better idea of when certain skills are relevant. Additionally, you could also use this to show off skill increases as well. 3. Using the space to show info about the object that the cursor is over, rather than using messages. This not only give us more room to describe the object that we're checking out, but also lets status messages stay in the status area without being overwritten. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-26-13, 08:12 pm in Checklist for release 0.1.2
|
|
Posts: 85/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
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. :(
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-26-13, 09:30 pm in Checklist for release 0.1.2 (revision 2)
|
|
Posts: 86/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
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. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-27-13, 09:16 pm in Checklist for release 0.1.2 (revision 2)
|
|
Posts: 87/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
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. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 03-29-13, 01:16 am in Checklist for release 0.1.2 (revision 3)
|
|
Posts: 88/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
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. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-02-13, 05:14 am in PillowShout's Prose and Code Depositorium
|
|
Posts: 89/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Just a minor update to Scheduler. Also letting you know that I'm not dead yet. https://docs.google.com/file/d/0B_IgNCoukjzDQ1VuOTQ2ODY1SUE/edit Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-03-13, 05:59 am in Making the world more interesting (revision 3)
|
|
Posts: 90/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
This is sort of a spiritual successor to my previous post about making towns feel more alive, but this time it's bit bigger in scope. There's also gonna be a bit of nitpicky stuff here too, but seeing as we're at the point nearing the next release, I feel that it's time to address some if it. Major stuff: Separation of monster and man: The basic idea behind this is that we physically separate towns and wilderness areas in order to better differentiate them. I feel that towns should seem like places of safety and that wilderness areas should be more dangerous, and that the best way to get both of these extremes is to physically separate them into different travelable zones. While towns wouldn't change much aside from monsters or dungeons not spawning around them anymore, the wilderness areas I was thinking of would be a bit like dungeons in that you couldn't fast travel while inside them. The obvious exception to this would be a starting "safe-board" where no monsters spawn and the PC is able to travel, but on any other boards in the wilderness area, monsters would spawn and the PC would not be able to travel. Ultimately, I'd like to see these areas become forests, ravine networks, dead cities and the like, but for the time being we could use the same empty boards we've been using, just so we can test it and see if it's worth pursuing. Edge board boundaries: Another think I'd like to see is boards that are at the edge of a board cluster (ie. boards that don't have a connecting board on all four sides) having some kind of natural boundary. This serves a couple of purposes; one is that it shows the player which sides of the current board are connected to other boards just by looking at it, and the other is that it adds a stronger level visual differentiation to each of the boards and helps the player to keep track of where they are. The way I was thinking this would work it that the boundaries are added to the all boards in a cluster after all the boards have been created, and that the boundary types would depend on the board type and biome. For instance, an open area board in a desert biome might have a boundary constructed of rocks or a cliff, while the same board type in a temperate biome would have a boundary made of trees. For the sake of simplicity and minimizing size, boundaries in towns could just be walls or fences of some kind. Minor stuff: <ul> <li>Making item use take a turn: I'm suggesting this one mostly as a way to prevent players from just stocking up on food and then devouring a shitload of it any time their health gets low. Hopefully this will make combat a bit more tense.</li> <li>Moving 'Trade' into the top level menu: Having trade hidden in the "Talk to" menu is a bit unintuitive, and I think that giving merchants an extra option at the top level interaction menu helps to set them apart from the other characters.</li> <li>Reseting the position of the player character when they travel to another location: This could be done easily by setting the PC XY to the default one (i.e. the one from when they first start) each time they travel. The main reason I have for wanting this is that I hate getting stuck in lakes when I travel. >_< </li> <li>Travel time: Adding a random amount of time to current time whenever the PC travels. This helps to give the impression that the PC is physically going somewhere else instead of just teleporting.</li> <li>Giving the player indications of when the PC can't travel: I think that it might make things less confusing for the player if the game displayed a message when they tried to travel but were unable to, something like "You cannot travel from this location."</li> </ul> Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-03-13, 05:06 pm in Making the world more interesting
|
|
Posts: 91/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
I actually like this solution better as it'll keep the number of travel locations down. One other thing I would like to suggest then is generating pathways that go between boards - sort of like what the demon portal has. You could use these to connect different town boards together and to show the player how to get to wilderness areas from towns.
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-03-13, 05:21 pm in Making the world more interesting
|
|
Posts: 92/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
I guess I should have been more clear. What I mean was adding dirt pathways or roads to the boards and having them match up with adjacent boards. For example, if two town boards are right next to each other, and are surrounded by open boards on all other sides, the town board on the left would generate a dirt road that went to the edge of the board only on the right side, and conversely, the right town board would generate a road that goes to the edge only on the left side. These roads could also be generated in open boards as well, but would contain roads that lead to towns or to wilderness areas. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-11-13, 10:35 pm in Things of note
|
|
Posts: 93/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
It wouldn't really be that hard to write a description function for the actual keybindings and hook it into the token parser. All you'd have to do is pass the function the name of the KeyBinding via the replacement token, get the keybinding from NoxicoGame and return the the key name as a string. Also, as a minor suggestion, would you be willing to rebind the menu button to ESC? I probably should have brought this up earlier, but I've always found it a bit weird that the menu is assigned to F1 considering that it's usually reserved for help functions. I just think that setting it to ESC would probably help to reduce confusion for first time users as it's the defacto menu button in most games. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 08:17 pm in Contrast (revision 2)
|
|
Posts: 94/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
I'm not at all fond of that horrible shade of brown, but I can definitely see the need for some better contrast. My suggestion then is to use a simple color space transformation for the clutter themselves. All you'd need to do is change the Value of the clutter's foreground color in HSV space so that it at least some distance away from the Value of the background color of tile. For example, lets assume we require that the foreground color of a piece of clutter cannot be within 10 points of Value from its background. We then come across a tile where the Value of the background is 47 and the Value of the foreground is 44. To fix this, all we have to do is change the Value of the foreground to either 37 or 57 and that's it, problem solved. :D This way, the color of the foreground isn't affected that much, the color of the background isn't affected at all, and you have a very general solution that can be applied to pretty much anything! What do you think? Edit: Changed to reflect proper terminology Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 08:35 pm in Contrast (revision 1)
|
|
Posts: 95/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Sorry, I mean the stuff like cactuses, trees, rocks and the like. I didn't know if you had a distinct term for them.
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 08:45 pm in Contrast (revision 1)
|
|
Posts: 96/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Ok, edited my first post. Let me know what you think. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 09:09 pm in Contrast (revision 1)
|
|
Posts: 97/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
The changes are pretty subtle, so just compare them with the original.
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 09:15 pm in Contrast
|
|
Posts: 98/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Well, sometimes subtle problems need subtle solutions. ;) You could increase the contrast further if you wanted to, but I can see them just fine as they are.
Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 09:28 pm in Contrast
|
|
Posts: 99/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Ok, but the problem I have with the solution you provided in the second shot is that it is way too heavy handed for the problem. Essentially, what you're doing is the just exact opposite of what I'm suggesting. Where my idea is to simply adjust the contrast levels of the clutter, your solution changes the contrast level of the entire board. Another issue with what you're suggesting is: what happens when you have clutter that has a similar tone to the new board colors? Once again, you're going to have contrast issues. Lead writer on Noxico (and sometimes programmer or designer) <br> |
| PillowShout |
Posted on 04-14-13, 09:48 pm in Contrast (revision 1)
|
|
Posts: 100/105 Since: 12-06-12 Last post: 4051 days Last view: 4033 days |
Just because other rogue-likes have higher contrast environments doesn't change the fact that the second picture just looks like everything is now covered in mud. And as for my scenario, my system still solves the problem better because it doesn't introduce any arbitrary restrictions on the color or brightness of the foreground or background. All it does is change them when they need to be changed and nothing else. Lead writer on Noxico (and sometimes programmer or designer) <br> |
