This may sound bad, but I’m redoing the whole engine, bit by bit. The reason being, I’ve started doing a new tile engine. And it will be a lot more awesome than the current (and limited) model. This new is also opening everything up to new gameplay ideas, and will make the game a lot better in both short and long runs.

I’ll be doing a new Mapper as well. One that’s 100x user-friendlier, and with a lot more functions. And, in general, better.

I won’t be taking down the current pre-alpha though. You can still play it if you want. I just won’t be updating it anymore (even though it had like, what, one patch?!).

Also, I’ll be updating each bug’s status, so be sure to check this post regularly for updates.

Client bugs:

• Console capturing keys after endround if it’s open while it triggers. (FIXED, waiting for patch)
• Chat window isn’t accessible during endround. (FIXED, waiting for patch)
• Bullets sometimes pass through own player. (possibly FIXED, waiting for patch + further testing)
• Sometimes bullets register client-side but not server-side. (this may be due to lag and not a bug itself, but I tweaked it (a lot), so waiting for patch + further testing)

Server bugs:

• Nicknames are bugged. (FIXED, patch 1 here)

Ladies and gentlemen… Killplex Pre-alpha Version 1.

After a few months in development, I finally built a (hopefully) stable, pre-alpha version for public testing. May I remind you that this version is pretty much a work-in-progress, and that lots of things are going to be changed in the road to the final version.

You will need .NET Framework 4.0 and the XNA Redistributable 4.0 installed on your computer, otherwise the game will not run.

You can download the pre-alpha version 1 here (~ 630KB).

You can also download the server patch for the names bug here (~ 26KB). You just need to overwrite the contents of the original folder with the contents in that zip.

Also, here’s a list of useful links (this will be updated regularly):

• Pre-alpha bug list

What’s included in the .zip file?

The game, server and mapper executables. It also has the configuration files for both client and server, and they all need to be in the same folder. The mapper has no configuration files of its own (yet…).

How do I run the game with my own resolution?

I still haven’t done a launcher, but you only have to edit the config.cfg file on a text-editing app (notepad is the best one). You need to edit the “nick” field, replacing “Unknown” with your own nickname. Also, you can edit your resolution by changing the width and height parameters, and you can choose it to be fullscreen or not (you have to put either “true” or “false”).

There is a warning though. Don’t change your resolution to random values while in fullscreen, otherwise you might get a black screen due to unsupported res. I recommend using window mode for that.

How do I connect to a server?

First of all, you must have the IP of that server. Second, put that IP (and port, if it’s not the default one) on the “ip” field in the config.cfg file. Then, all you need to do is run the game.

You can also host your own server on your own machine. You just need to set the IP to “127.0.0.1″ (or “localhost”) and run the game.

What are the keys?

WASD = basic movement.
Left Mouse Button = shoot.
Left Shift = sprint.
R = reload.
Q = melee.
F = flashlight.
J = toggle chat visibility.
K = talk to all.
L = talk to team.
F1 = console.
ALT + F4 = exit game.

How do I control the server?

You can rcon through the game console. Press F1 to toggle the console and write “Server.Rcon <password>”, and replace <password> with the one on your server.cfg (server_rcon parameter).

Unfortunately, the commands are a bit on the short side for now, you can only fetch a user’s info (Server.PlayerInfo <name>), kick him (Server.PlayerKick <name>), and force endround on the server (Server.ForceEndRound) so it goes to the next map in rotation.

Do I have any client-side cool commands?

There is “version” to know which version and build you’re running on, and there’s “Draw.Perf” to show an FPS counter and a game loop timer, other than those, there aren’t any more commands yet.

The mapper is so difficult to mess with!

It’s not supposed to be released to the public. That’s just something I made for myself to edit levels with. On the next stage of testing, it will be completely revamped, so don’t get too fond with it.

Also, levels aren’t shared by the server, so you have to make your creation public in order for other people to play in it.

Why is there only one map?

It’s a good map. Short, but sweet. And it’s a map made for testing. Other than that, I can’t say.

Why is it only Deathmatch?

You can play on custom maps created for TDM and SQDM, but I’m not supporting those modes yet. I want to test other important stuff before actually adding and supporting more modes to the game.

How long will this pre-alpha run?

It will run until there’s a new version. But I don’t have a roadmap, so it could be until infinity and beyond.

—-

So yeah, this is just a short FAQ about the pre-alpha. If you have any questions, please ask them in the comment section below, and I’ll be more than happy to answer them.

I’m working hard on the pre-alpha for Killplex. I’m finishing up some stuff, and then I’ll be launching it for all of you to help me test it. Oh, and I dropped a few stuff from the roadmap, perhaps because I didn’t really think it would fit with the overall tone I want to convey with this game.

So, I’ll be doing the console (for command inputs to control certain gamevars, and to control the server itself) and some tweaks to my bullet damage model (making it more “distance-based” instead of completely random calculations).

I’ll be including the server and the (incomplete) mapper, and I won’t provide a launcher for the time being. I won’t officially support the mapper, its inclusion will be mainly for feedback… I already have plans to revamp it completely (and it will render these pre-alpha maps incompatible). Until then, I’m going to be focusing more on the core game itself.

So yeah, that’s my first update for 2012. I’ll be posting more info soon. :)

Hold on… Wait! Don’t be sad! 2012 is right next door. And I think I’m going to have some time to rest next week. So guess what? I’ll try to release it then. Anywhere between the 2nd and 8th.

But… what’s holding up the pre-alpha? What could possibly be missing‽, you ask. Well, a bunch of stuff:

• Power plates: these handy fellows will give you free stuff when you step on them. They’re not vending machines, I actually don’t even have a better name for them yet. I haven’t yet decided what will spawn there, but I’m thinking something like Health packs, you know, little boosts.
• A console: you know where, in certain games, you are able to open up a nice window and you type gibberish in it? You know, stuff like “drawfps 1″ or “cl_cmdrate 33″ or “devour_your_mom 69″, stuff like that? I intend to implement that, and I have several reasons for it, but I’m going to save them for another post.
• Server optimizations: I still have a bunch of them to do before I release the pre-alpha.
• Launcher: at the moment, the only way to launch the game is to edit the config.cfg with your nickname, screen resolution, and server address (IP and port), and then run the exe. I intend to create a launcher with a server browser (this may not be ready in time for the alpha), and at least a decent way to change graphical options (at the moment, only the screen resolution is changeable, and I didn’t forget the fullscreen option) without resorting to editing the config.

What is the point of this pre-alpha?, you ask again. Well, I have several reasons, but mainly server and client stability with 4+ people, and general feedback to improve the game. This pre-alpha is a way for me to test several stuff that I am unable to test on my own. And mainly for motivation, which I seem to lose quite often, probably because I’m just like that. :)

Expect more news in the next few days.

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?

I expected to have that part ready before the end of September… but fortunately my perfectionist me kicked in and decided to have a play-test… to see how people would react to the game.

There were two, actually. The first wasn’t really planned by me. But both of them allowed me to gather really interesting bugs during development of those features… and I added some more.

Let me go through some bullet points here of what I actually worked on:

• I fixed a major bug with file handling, where the .NET Framework got confused with Decimal Separators (basically switching commas by periods, provoking a game crash).
• There was a “dupe death/score” bug, where two bullets would hit a player. The first would kill him, so theoretically, the second shouldn’t even detect. However, the server wasn’t checking if the player was dead or not, so it was adding another kill to the scoreboard. Now it’s fixed.
• I nailed down a useful code snippet for showing framerate in-game, instead of having to install Fraps on every test machine. That was a must.
• The player can now sprint for a certain period before getting tired (and entering a cooldown period).
• I added a flashlight to each player, allowing them to see in dark spaces. The flashlight is unlimited, but later I may implement a rechargeable one, Half-Life 2-style.
• Crosshair and hitmark functionality is now implemented as well. Whenever the player hits another, a cross (x) appears for a brief time above the crosshair.
• I had to implement a sort-of crash log functionality. In the first playtest, some players crashed mid-game and I didn’t really have a way to diagnose those crashes. For the next playtest, I’ll be ready.
• The spawning algorithm was not really functional. Players would spawn, but on top of each other. That was because of a variable I had wrong in a for loop. Silly me. Thankfully that’s fixed.
• Weapons are done. There will be five weapons at the beginning, and I might extend it later in the process. Basically an assault rifle, a long-range machine gun, an SMG, a shotgun and a high-caliber rifle.
• Bullet code is pretty much done, hit-detection is smooth, but I still need to tweak more before jumping into conclusions.
• Some tweaks and optimizations here and there.

And that’s what’s been done since my last blog post. I will work on the HUD next, and tomorrow I’ll have another playtest to see how it runs with this new code. Let’s hope there aren’t anymore bugs.

Bug fixes apart, I started writing the bullet code. For now, the player can shoot when the left mouse button is released after it was pressed (basically a mouse-up action). The client doesn’t check for firing rates nor reload checking, and the bullet is created and sent to the server.

The server reads the bullet and basically sends it to all clients in-game. The game reads the packet and it sorts it all out. The bullet is then updated regularly.

The collision checks are also mostly complete: it disappears when outside the bounds of the map, when crashing against a tile or when crashing against all players except for the “bullet owner” (who shot it). Only thing that is missing is when checking against the players… basically the client will send a packet to the server indicating the bullet hit a teammate/enemy so it can do game logic: confirming if the player was really in the spot, checking if it hit a teammate, if team-killing is on, and so forth, and then do the corresponding action.

It’s pretty stable and fast, doesn’t crash either instances (server nor client), and the lag doesn’t seem to play a major factor. The only factor I can think of is during collisions: if player positions are behind, the hitboxes are probably not going to be accurate. But that happens in all games, right?

…right?

Anyway, besides server game logic, I’m also lacking a weapon selection system. I’m probably going to have an array of weapons available with default settings, and the server will be able to tweak/disable weapons accordingly. As for which weapons will be available, I’m not going to discuss it now, mostly because not even I know that. For now.

Also, each bullet has its own light. But they’re not like in the video below, where I was purposely testing out the lighting engine… they will be weaker and have different color tones according to the weapon. So don’t freak out.