Gwen: Streamlining adjacency settings, performance, notifications, allegiance, etc

Eh…this started out being a brief update from the past week and turned into an ongoing update stream of notes. I didn’t have an Internet connection available for much of it, meaning this post may be a bit weird as parts of it were written at different times, but it’s mostly just for me to be able to go back and review my progress.

Streamlining adjacency setting

Attempt #1

I had this idea to change the way that I set the adjacency arrays (when specifying adjacent nodes). Right now it works perfectly, but the process is a bit of a hassle as I have to go into the level editor, check the ID of every node, then make a list of nodes that are next to each node, go back into BBEdit, and manually put them into the appropriate node’s array. What would be easier is if I was able to just write a quick list of nodes that are adjacent to each node entity inside the level editor itself and have that be pulled into each node’s adjacency array from there.

Weltmeister (Impact’s level editor) does allow you to set attributes for individual instances of entities within itself. So I created one called “nearby” for two of my nodes as a test and listed the IDs of their adjacent nodes separated by a comma. Yes, I’m still finding and listing adjaceny nodes manually, but this way I’d be able to do it on the go as I’m building the level inside the editor, which would make the whole process pretty much hassle-free.

Then I passed the ‘nearby’ attribute to the adjacencyList() function from the entity and instead of doing this:

[crayon]m.rows[7] = new Array (8, 11); // node[/crayon]

I did this:

[crayon]m.rows[7] = new Array (nearby); // node[/crayon]

However, this didn’t work. Specifying ‘nearby’ in that array made the final result look like this when I printed m.rows[7] to the console as a test:

[crayon]“8, 11”[/crayon]

So it looks like it’s just turning it into a string, which won’t do. I’m sure there’s some really simple solution there (in fact I’m pretty sure I’ve read about it), but as I don’t have Internet access at the time of writing this I can’t Google it. I’ve made a note for myself to come back to this later, as this really does make the process much easier. Maybe eventually I can even go through and instead of creating each node’s array manually I can have a for loop that cycles through each instance of a base, node, and destination entity.

Attempt #2 I got it working. I ended up doing this (eh, my WP code pasting plugin threw off the spacing a bit):

[crayon] var nearby = nearby.split(","); switch ({ case 0: m.rows[1] = nearby; // node m.rows[3] = nearby; // node m.rows[5] = nearby; // node m.rows[7] = nearby; // node m.rows[8] = nearby; // node m.rows[9] = nearby; // node m.rows[10] = nearby; // base m.rows[11] = nearby; // base m.rows[12] = nearby; // base m.rows[13] = nearby; // node m.rows[14] = nearby; // node m.rows[6] = nearby; // destination break;

        default: console.log('Not in a level');

Move base selection to controller

The next thing I did was move base selection from the individual base to the controller class because I noticed that just like with follower movement, this code will be the same for each base. So now I don’t need to duplicate 33 lines of code in each base entity.

Performance problem

10fps and over five thousand draws?

I noticed that followers were looking quite jittery and slow as they moved along the path. I thought this may have something to do with the movement change I implemented yesterday, but couldn’t really figure it out. So I activated Impact’s debug console and holy crap, this thing was running at 10 frames per second! The Performance tab in the debug console showed a massive amount of draw calls being made, even when follower entities weren’t spawned. I was seeing almost 6000 draws. WTFing ensued. I’m not making that many draws.

Then I got a hunch. If it wasn’t anything in any of my entities drawing stuff, it could only be the tiles I’d placing in the level editor. Sure enough, looking at Weltmeister I saw a “Pre-Render In Game” checkbox that was an optional setting for each level (except collision and entity levels). I didn’t run into this with the last project because that was running an older version of Weltmeiter and must have been pre-rendering everything by default. Activating pre-rendering for the path tile level instantly brought me back to 60fps and 17 draws in my sample level.

So I’m now sitting here during a stopover. I think I’ll use this time to make text notifications show up when the player performs an illegal action. Right now I’m printing error messages to the console for myself just to make sure it’s all triggering properly, but this will eventually have to be part of the UI anyway. Illegal actions so far include:

Off I go then.


I’ve been implementing the notifications and all of the ones I mentioned above are now in.

Ok, so what can I work on next that isn’t blocked by lack of internet access…

Yes, that’s what I’ll do.

Follower allegiance

Ok, I did it. Followers now have an allegiance attribute that is used to detect if they collide with other followers whose allegiance is different from their own. They don’t do anything in response yet except for printing a message to the console, but that’ll come soon.

Coming up next

Right now followers are moving in too uniform a manner and when they collide this results in frequent blocks where colliding groups are pushing against each other and staying in place. Different followers will react to each other differently, but I think the next thing I need to work in is a ‘strength’ or ‘dominance’ attribute for each set of followers. I can then use this to see which batch of followers is more dominant/has more power when colliding with other followers.

© - 2021 · Liza Shulyayeva ·