Slow coding is slow

I haven’t been coding Killplex due to the simple fact that I reached an area of boredom. I’m right now doing a sound engine, I have most of the sound library, but I just can’t figure out how to make it blend with the gameplay. Also, I have to do graphics, more objective-based modes, maps and so on. That is just overwhelming to think of.

I want to do positional audio… shots from your left actually come out of the left side, traveling bullets also swoosh from one side to the other, making a good audio experience for a 2D game. The thing is, I don’t know anything about XACT, and the idea of converting sounds from map positions (for example player: 200,400; shot: 100, 400) to screen decimals (for example player: 0,0; bullet: -1,0) in runtime without losing performance actually frightens me.

But… last weekend I had a LAN, where I put three other people playtesting with me. The experience was none other than exciting, watching people other than myself actually having fun with something I did. It motivated me to go and release this game.

That playtesting also brought me some ideas for tweaks and improvements. For example, I added text to the Health and Ammo bars (it now shows the values). I bound the ENTER key to the Spawn action when in the menu. And now I’m in a phase where I should rewrite most of the server processing code, in order to make it more modular, and to be able to make an API. This will make it possible (and easier) to build a RCON tool in order to manage the game, a.k.a. kick/ban players, change maps at will, etc.

It will also make feature extensibility easier, so that when new gamemodes are planned, I’d be able to just write the code and BAM! Of course, it’s never that easy, due to client changes, but you get the point.

I will change the network packaging today. Instead of sending movement and stats in the same packet with the same reliability, I will separate them. Movement will go through one channel with unreliable (but ordered) delivery every 60 times per second (this is adjustable in the server config), while stats will be processed independently (I’ll make a variable for it, possibly 4 times per second?). This way, I can make stats messages more reliable (through some techniques), improve performance, and will make them extensible enough to implement other messages into that one.

I will also revamp the methods to allow for better end-round behaviour… right now, it’s currently internally named a “server restart” instead of a “map transition”, disconnecting all players and resetting everything. This will lead the client to check if the flag “endRound” is activated, and if so, it will try to reconnect to the server when it gets booted (and accepts connections). This leads to some bugs, like infinite loading (the client doesn’t disconnect properly), so I’m changing it up. I’ll make it so it loads the map while it’s in the end-round screen, and then just changing player states and loading up the map on the client’s end. That seems robust enough. Leave me tips in the comments, though.

So that’s an update for you. I will try and stay active, and possibly release an alpha test by the end of the year. Does that sound nice?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s