I decided to tackle some of the performance issues today. First, I fixed the A* implementation to match the fixed pathfinding implementation. This didn’t resolve my performance issues, and I wasn’t expecting it to, but I wanted to make sure that it wasn’t my issue.
What I thought was my issue was the code that checked network connectivity. I timed that segment of code, and to my surprise, it was running in under 1ms, so that certainly isn’t why the game is crawling along when lots of energy network segments are being checked as powered or not.
That leaves the actual drawing function. With one network segment, it takes ~1ms again do draw, but by the time even ~15 are on the screen, it’s taking ~10ms, and when 85 are on the screen, ~75ms. Still not the smoking gun I expected, but maybe the issue was elsewhere in drawing above the layer where I am technically setting the sprites up to draw.
And then I noticed that I’d missed clearing the children of the network layer. I’m not sure why I need to do this, but I’d already figured out that it seriously impacted performance elsewhere and had to do it. What I’d missed doing for the network and safe layers, leads to huge amounts of sprites that are being drawn, just not visibly (I think, cocos2d/pyglet can be a little opaque at times). Each time a batch is added, it stays there unless it is explicitly gotten rid of, even things that are updated many times. I still don’t know the proper way to do this, but making the change made the game run about 5-10x faster.
Not much to update today. I started work on enemy movement, but was not able to get it working. I’m starting to duplicate large amounts of code, leading me to wonder if I’m doing things correctly around program structure and event handling.
Also, I seem to be doing something else wrong, because the game runs very poorly. Look at the bottom left of the above image. Yes, it is running at 0 FPS (my estimate is more like 0.5 FPS, or worse), which is telling me something is very wrong. Unfortunately, I’m not sure how to profile cocos2d to see if it’s a bottleneck there or in my code, but even for testing, things are unplayably slow, even without enemies attacking and friendly weapons firing on the attacking creeps. I’m not sure how I’ll address this.
Including some code cleanup, I fixed the fog-of-war so that it moves with a unit as it moves. It’s not very important, but it was bugging me. I realized that movement of multiple units at the same time is also broken, which I haven’t looked at yet.
The next thing was starting to implement enemies. The spawning is basic now: enemies spawn close to an enemy controlled core, and they don’t do anything. Making them move, attack and be attackable is the next step (or next few steps).
In future, I want them to spawn more intelligently. Not under safe areas, but near the edges. I’m not sure how to handle making them spawn if large segments of the map are safe, but probably still at the edges.
I’m not sure what the mechanic to take over enemy controlled cores will be. I suspect it will a control network connection and some sort of countdown timer when many enemies rush the core to try to stop the takeover.
Today’s task was moving the noise based terrain generation code from my testing branch into the main branch. Once I did this, and fixed a few bugs that cropped up, I also changes the sprites to be normal sized (64×64) versions of the much smaller (8×8) sprites that I’d used in my test. This should mean that, with some tweaks, chunk generation should work in full screen mode as well.
There are still some things to fix, one of the main things being that the start city core can spawn on water. I’m thinking of either making sure it can’t spawn on water, or making it be able to be connected wirelessly and give a free wireless energy (and control whenever I implement that) tower to the player.
I spent some more time working on terrain generation, preparing to bring it into the main branch of the game so I can start spawning enemy units. I added a second noise layer to use for not-directly-terrain related sources of randomness, in the game’s case, enemy city-core spawning in chunks.
Another relatively slow day, programming wise. I did get a first pass of unit movement working. It’s janky and needs more work, but a unit now follows the path set out for it. I think it’d be nice if it followed the path somewhat smoothly rather than teleporting between hexes, but that’s certainly not needed to get a game working.
There weren’t many examples for how to do move a sprite along a path in cocos2d, so I resorted to looking at the source code for how things are done elsewhere. I ended up subclassing the Action class, and implementing the step() function. I’m still not sure how to make the action stop running when I’ve exhausted the path, but it’s a good start. I definitely don’t want to leave the action running forever in the background.
I worked more on unit movement today. I can now actually make a unit cover the distance between the start and end hex cell, but I haven’t figured out how to make it follow the path I spent all of that time figuring out. Currently, I’m using cocos2d’s MoveBy action to move by a certain amount, and this is certainly the correct start, but I can’t figure out how to do what is essentially enqueuing multiple moves taking place one after another, so that a unit can follow the path between hexes, but smoothly move hex-to-hex.
Cocos2d may have support for moving a sprite along an arbitrary paths, and it might for Bezier curves, but the documentation isn’t very clear on it, other than it’s possible existence. I’ll look into how cocos2d supports some of its actions, potentially I need to subclass it and define my own step() function to do one step of my path.
Unfortunately, not much to show for today. I spent too much time troubleshooting my A* implementation, and then finally realized that it was all correct except that I was using Python’s PriorityQueue wrong.
The next step will be using cocos2d’s movement facilities to move the sprite for a unit along the path A* generated. At some point I’ll need to add in the new terrain generation algorithms, so certain units have something interesting to drive around.
I started work on basic unit movement, as a start to adding in enemy creeps that defend against. Initially, I’ve made a unit which I’ll call a “hover tank” for now. Movement is simple, it teleports instantly, but I’m going to look into cocos2d’s movement and figure out how to actually have it move over the terrain.
Right now, units can be placed on top of networks, but not buildings. This seems reasonable. When it comes time to have them move properly, I may need to figure out how to deal with this. Perhaps all units can be air units and fly over buildings. The other option is to pathfind around buildings, but I was probably going to have units cover the distance directly from the start hex to the end hex. Or I may decide to have it hex pathfind and move hex-by-hex. This won’t use the cocos2d movement system, but it might actually be stylistically better.
Units have a vision area around them, but I may also want to have a safe area around a unit to keep enemy creeps from spawning. Like many things, this will need testing to see what’s fun.
After having gotten basic OpenSimplex noise working, I started working to make it more like real terrain on the scale I was looking at. This involved taking integer x/y coordinates, which are based off of the hex’s offset coordinates rather than cubical coordinates I use everywhere else, and then some factor apart that’s less than 1. I’m calling this a damping factor, because it’s damping how often the noise is sampled. Maybe this is a bad name, but naming things is hard.
Below, I included 4 images showing different damping factors. I’ll need to play around with this a bit more, but I think at the scale, something around 0.05 is going to be the right amount. I’m also going to need to make sure city cores (especially the start core) aren’t drawn underwater, because I don’t intend building to be able to take place underwater. I’ll also probably tweak my transitions between the different terrain hex sprites. I’d like this all to be configurable at some point, and the settings are exposed in the settings.py file right now.
I also fixed fog-of war drawing. I’d accidentally put the the actual draw call inside my for loop, so it was drawing every hex one at a time, rather than a all together in one batch. And once that was fixed, I could move on to further implementing it. Buildings can’t be built under the fog of war, and things that are under the fog of war lose their information. There are a couple minor bugs with redrawing things under the fog.
I’m not sure I’m going to keep this. Protection towers still run and protect the area if they’re being supplied energy, but other than seeing the protected area disappear, there’s no other way to know if they’re working. I might also go the other way and hide the safe area, or not allow it to update its status in fog-of-war areas. It’ll depend on what’s actually fun to play.