Developer: PCF (no news … but soon)
Publisher: JoWooD (thx fleabay)
Release: October 26th 2007 Amazon.co.uk and play.com
Platform: PC

I also found 2 german links
GIGA-Games
ingame.de

It will be a new stand alone title.
Not just an simple expansion! Including new content + new playable character and a brandnew story. And its built on the original PK engine.

Keep in mind its PK1.5 and not PK2 wich will be (so god will) built on an entirely new engine and released 2008/2009.

Demos were the original reason I started looking at PK, but in fixing demos a lot of other things need to be in place first. But before I explain that let me give an overview of demos as they are now.

Firstly when existing demos are played, they are simply rendering the few entities that you can see and nothing else. There is no game running, the player objects arent real, items/models are only there when you can see them, local player has no model. Also names are left out, comments, there is NO health or armour information. When you do not see the opponent, there is no way of telling where he is (I believe – need to check that).

This is slightly annoying, since I had planned to at least write a converter into any new/improved format. The fact a lot of the information I want is not there stored, or cannot be determined from the gameplay, is frustrating.

However, in order to create a new demo format – one where, say, you can run it at any speed, switch POVS, go spec, make movies from it. Effectively what I need is to write the netcode to file, and replay it. Obviously I would not want to store it at rendering fps, or even at netcode fps. To play it back, everything needs to be smooth, being played from any framerate. Of course this is where interpolation comes into play, and why it is so very important. With smooth interpolation I can replay demos and fill in the missing information.

The only thin I have yet to do is to tie up some loose ends of an initial snapshot of the level (item respawn times, etc), although in truth, this can just be captured from the netcode.

This weekend was particularly productive, mainly because I provided a test version to some players who seemed happy with the progress.

As you may imagine, from tweaking the code I ended up with a version very far away from PK++. This step change is not ideal for testing properly, so it is important to trickle the changes into PK++ over a length of time.

My main objective was to put a lot of the netcode fixes into PK++. This is mainly concerned with interpolation, and determining where issues are in PK netcode and gameplay.

Before I add more, understand that interpolation is important because it allows players to run at much lower data rates from the server. This is important:

1. If you want the game to be stable with lots of players on the server.
2. If you want to add lots of monsters.
3. If you have demos of low quality and want to watch it smoothly.

Firstly before anything else in added a netgraph. This plots (much like Q3), ping over time (indicating packet loss too), as well as interpolation deltas (basically indicating how much interpolation is taking place). Testing indicated that PK suffers from a degree of flux in ping, with occasional lags due to certain events. On the whole though it didnt look that bad. Command is \drawlatencygraph 1. Obviously there is a lot of processing for this, so fps is damaged.

Next for interpolation, I wrote three methods. The first is linear interpolation for each player. I decided that it is possible that lagging players on bad connection might not update the server at the same rate, so would still move badly if interpolation was done on a per-game-frame basis. Instead what I decided to do was look for updates on players themselves, and have each player in their own interpolation space-time. The second and third methods are quadratic, and the average of linear and quadratic, respectively. At very low update rates I would suspect the quadratic to be slightly better (mainly on vertical movement). Command is \interpolation 1/2/3. Testing showed that it was playable at \serverframerate 15 (equivalent to snaps), although 30 was playable. Remember \netstats 1 to view what is going on.

Here I also added timenudge (which qw and q3 players will know). This moves the interpolation forward or backwards in time. A positive timenudge can allow more for variations in ping, whereas a negative timenudge may draw the players closer to their actual position.

Next I added an option to interpolate from the previous position or from the last interpolation position. What I found was that the last interpolated position method gave worse results.

Next I added a method to automatically adjust timenudge for latency variation. Although this was damped quite heavily, it looks to be unstable on first testing at certain times. I would be a nice method if it works.

Next I tweaked teleport behaviour on the client. Up until now on higher pings, teleporting would either result in a judder or double teleport. Teleporting is now entirely predicted on the client, so server updates are ignored (mistakes are captured in synchronisation frames anyway). Likewise the jumppad was updated. Both methods help reduce the feeling of lag on the client which is important for movement. Weapon prediction needs to be completed, and possibly zero ping at some stage soon.

Console commands were altered slightly so that settings could be edited. This will mean less actual code, and less inconsistency between what is seen in the console between commands.

Finally I will update you on my next task – looking at rendering framerate. I was aware testing that my fps dropped heavily in FFA once it got above 10 players. Without players on the server I get 190fps on sacred, but it can drop as low as 40 in FFA. As a quick test it seems that 90fps of the drop might be from drawing items which arent required for rendering (which can be fixed by hiding things you cannot see), and 60fps from the game ticks themselves (although admittedly I was testing with bots). I have already done some work on improving ticks, so will migrate that across and test. I would suggest that even saving 10 or 20 fps might have a real impact on game playability.

For a test version I will provide this soon, but please do not expect too much yet since it is work in progress and most of the work is elsewhere and yet to be transferred. You can download a test version always here:

LScripts.pak

which you pop into \Data\ (remember to back up the old one. Then run normal (not PK++), or alternatively rename this file to PKPlus.pak and use PK++. Please set \interpolationnosmooth 1 though or you will have issues. If you do not understand it, or have issues, I am not yet helping you fix them until I reach a beta test phase. You are welcome to paste feedback though, positive or negative (if it is negative – remember it is work in progress!). Also fixes/bugs/suggestions are more than welcome, either here or direct email to kerberos99@hotmail.com

I am grateful for any help from now on, be it images/sounds/code/testing/ideas. I am more than willing to accept help in any way since my free time is limited.

Have fun and happy fragging!

The czech developers Mindware Studios, based in Prague, has announced today plans to release (August 2007) a community created SP mod for Painkiller, including new levels, new weapons and new end bosses!

More infos, artworks and screenshots HERE.

I have not had time to work on it recently, but the last series of tests were promising.

Running PK online at a 6th of the bandwidth and still relatively smooth gameplay. There may still be some issues created by the server not running at a constant rate, which in itself might resolve a lot of the issues. Other things which need attention are:

1. Local client prediction of events (item, teleport, weapon).
2. Item events in PK code are not specified by time (PCF themselves criticised this!). What it means is if you have an update every 50ms, then all events over that last 50ms happen all at once. This is not particularly healthy for the code where 50ms can easily represent 6 or so frames of gameplay. At lower update rates this becomes signifcantly stuttery.
3. Local client anti-lag test, i.e. what you hit on the client is what you hit on the server.

I will keep you updated soon and hopefully issue a early test version. Do not forget that perfection is iterative and it will take time with your help to improve.