Private FPS challenge

Contests
#1

This is a private competition to create the best multiplayer fps before the end of January. We will use this thread to post progress and try to keep motivation up. The 3 contenders are: tom, tensei and enjoyLuke.

The rules are:

  1. It must be multiplayer and will be tested on LAN
  2. It must be first person 3D
  3. It must be a shooter of some kind (range no melee)

It can be coded in any language and use any library. No game editors allowed.

The competition will be judged by a poll on this and other forums (If we can get anyone to actually test it).

#2
#3

It’s nice to see a multiplayer comp. Are you doing peer-peer with distributed collision detection, or client-server?
Good thing it’s a private comp, as I’m busy on lwjgl16k and haven’t even started a java4k entry yet :sigh:
(I did a 4 player peer-peer LAN 3D FPS for java4k last year, using multicast.)

Good luck, I look forward to seeing the results (and hearing about your multiplayer implementations)

Alan

#4

Hi

bobjob worked on a blueprint of an online FPS, maybe suggest him to participate.

In my humble opinion, the dead line is far enough to make a working blue print with a single arena but not a full game. I remind you that I have seen only a very few first person shooters on JavaGaming.org (Jake 2, Megacorps Online, Flesh Snatcher, Tesseract, Night Squad 2, JWolfenstein, Undead Arena, JavaIsDoomed, Wolkenstein, TUER, etc…). Don’t expect having a lot of competitors and I think it is not achievable for complete newbies (not as a first step).

#5

With LAN you can probably get away with TCP and a client-server model without any noticeable delay as long as you make some small input prediction.

I wouldn’t mind at all if you could provide some basic 3D models and a simple loader for the model type they use to get me starded, as I have no experience loading models.

#6

Only worked on this a few hours. Started on the networking and got something very basic up and running. I’m using TCP for now. Clients sends input to server. The server does the simulation and sends the world state to all clients. I’m using KryoNet for networking which is pleasant. Rendered in ortho mode from above where each player is a line showing position and direction.

Want to do client prediction and world state interpolation next. However it would be better to start adding bullets to make it an actual game.

For graphics I’m planning on doing what I intended for SquareHeads, using only boxes. That was before I got sidetracked by creating a Quake3 renderer and it ended up as Undead Arena. My avatar picture is a screenshot of the player model I used back then. So no modelling required. The world will start as a one big box for the floor. Might add more boxes if I get the time.

The motivation for doing this is to actually finish a game. Making it a competition between friends will hopefully increase the chances of it being successful.

None of us are complete newbies, so I think it is possible to complete it.

#7

Got 3d rendering up and running. Have a simple hud with deaths, kills and health of all the players.

I’ve fulfilled the rules so it is time to improve the game. Think the next thing will be to have a level geometry of some sort. Now it’s just one infinite big plane for the ground. I’ll generate random boxes and use JBullet for the collision response. I really don’t want to write my own collision detection.

#8

Ok, first update.

Got some of the 3D rendering up and running. Just some basic geometry, a crate.
And as you obviously don’t see on the screenshots; very basic, and not, finetuned fps controller and movement.

The crate is textured and illuminated with some shader code with a directional light.

Two screenshots; since pictures are much better than my words! (Usually).

(I have no clue if you have any rules about screenshots. Size, upload places, and so on. If something is wrong, just mention it in the replies.)

#9

That is some sweet looking box :slight_smile: Keep up the good work.

I wrote a little test for doing client side prediction:

Feel free to use it when you start on the networking part.

#10

Newest updates!

(It’s all very basic, so nothing exciting here :slight_smile:

I’ve made a box method, so I can easily make different size of boxes with different textures and so on.
I made this method first with vertex and index buffer arrays, but changed it recently to make meshes directly.
This since I will use the mesh for easy checking against AABB for frustum culling and for picking.

I’ve also made a simple HUD with no fancy graphics whatsoever (the way I like it).
With the HUD there is also a countdown clock.

And last for the HUD I have made a crosshair. This is at the moment just simple rectangles drawn on top of the screen, no sprites.
I also locked the mouse to the center of the screen and hid the mouse cursor.

On the screenshot you can see a very simple “arena” map made with the box method.
You can also see the HUD.

About the networking part… I’ll look at that when almost everything else is done I guess… (probably not smart, but hey).

#11

Nice :slight_smile:

How did you create/generate the arena? I assume you didn’t position each box by hand.

What are you using for collision detection & response?

My experience is that the networking has a lot of influence in how the data structure ends up. And changing the data structure late is difficult. But it is always possible to hack something together.

#12

Here’s a small update from me.

So far I’ve got the networking up and running, using KryoNet like tom and it’s really nice to work with. I’m using a dedicated server with clients connecting to it, no peer-to-peer. For now I’m using TCP, seems to suffice since I’m just running this on LAN. No client prediction yet, but it’s what Im going to start on next - although it seems to run very smoothly at LAN, with updates from the server every 10 ms.

As for the renderer its just the bare minimum I needed in order to debug the networking, I’ve attached a screenshot where you can see three clients with a fourth one observing.

http://www.ia-stud.hiof.no/~thomasw/img/game_network_debug.png

The player models are just for debugging, and the camera is located in the middle of the yellow box. The colored boxes just indicate directions (x,y,z) but looking at the picture now I think it is reminescent of a human (red/green arms, blue head, yellow body) kinda resembling a zombie (you know, doing the zombie walk) so I think I might end up using something similar for my player models.

So that’s it so far, haven’t really been able to spend as much time on this as I would like (damn you work and SWTOR!). The next steps will be to implement shooting, and then client prediction and then I can start working on the actual game! ;D

#13

I guess its my turn to show a screenshot.

http://home.halden.net/tombr/fps/images/fps_screen01.jpg

Client prediction and interpolation of other clients are in. Bullets are little buggy but it is possible to kill other players and deaths and kills are given out.

I’m using KinematicCharacterController from JBullet for player collision with world. It has not jumping implemented, so that is on the todo list. I use picking with JBullet for collision between bullet and world. Bullet-player detection is a line to sphere distance method I’ve written.

Got a bit distracted and wrote a deferred renderer using a scenegraph I wrote a while back. The world has one hemisphere and 100 point lights spread out in a grid. Still some work to fix all the bugs and make it good, but I think I’ll leave it for now. Was really fun to implement though.

The most difficult thing now will be to create an actual level and make it somewhat playable. Don’t want to be bogged down writing a level editor. But I need a way to quickly iterate on the level design. So I’m leaning toward having a separate window where I can edit the boxes somehow.

#14

My code is now checked in to google code.

#15

To start by replying to tom: I did position each box by hand. :smiley:
BUT, there are not so many boxes as you might think. I use texture repeating.
So e.g., the floor, is just one box.

So to the updates.

I’ve implemented a sky, using a sphere and cube mapping. (The sky on the screenshot is a star night, squint your eyes, it’s there, I promise!)

On this next screenshot you can see a spotlight in effect. One. Not a hundred. :slight_smile:

I’ve also implemented bullet physics, so that’s working great, except for the jump function in the KinematicCharacterController (which c++ bullet has apparently).
I think it uses the look vector in its algorithm to determine the force of the jump, cause if I look down, I almost don’t jump at all. But if I look up, I can suddenly jump higher than if I was looking straight forward. So have to look into that, perhaps make my own jump method or something. We’ll see. It’s not prioritized.
On the screenshot you can also see the debug drawer. (The boxes hits the floor after falling from 100 meters).

On the “eye candy” part, I now got some basic bullet impact decals. For the moment only for static objects, since dynamic objects change the rotation on the u/v texture coordinates, and I don’t take that into consideration in my implementation for the time being. I also wanted the bullet impact decals to be shown on the other side of the object being shot at, to present the bullet exit position. I also make a decal on the next wall being hit by the bullet. This can easily be turned on/off.

And lastly a screenshot function, which I’ve used on all these screenshots (which are in 1680x1050 resolution, let me know if it’s too big).

#16

This is a cool thread! :slight_smile:

FWIW, KryoNet has a DeltaCompressor. I always thought it would be fun to do a FPS with Quake style networking.

#17

First of all thank you for KryoNet! It really is a great lib.

I’ll look into DeltaCompressor. Will probably work really well on my data, if it does what I think it does. But it does the compression on a byte array level, right? What would happen if my object contains something dynamic like a String that changes length?

Before you mentioned DeltaCompressor I had plans on doing something similar. By using a property system I can check each property individual and only send the data for the properties that change.

#18

Since today is the “deadline” we set for implementing at least the base features of the game, I though I’d post a little update.

Lately I have been working on my own scene graph for the engine, it’s still pretty basic though, but it’s taking shape. I’ve switched from immediate rendering, to sending the data as VBO’s instead. Shaders have also been implemented, however I have not had time to write anything pretty with it yet, so it’s still the same debugging graphics as last time.

Added collision detection using AABBs, as well as shooting using raycasting and AABB intersections.

Networking is working as it should, although I still need to implement a good form for prediction.

In terms of gameplay the game is all fully working. Players can move around in the world, and objects will block your path. You will fall if there is no solid ground beneath you, and if you fall too far you take damage. Jumping is also implemented. The jumping started out as a normal jump mechanic, but as I played with it I found it much more enjoying with a little more kick in it. Therefore I ended up implementing a jetpack system instead, sidetracking ftw! I think I will do a Tribes kind of gameplay.

Other players that are connected to the server is correctly rendered in the world. And yes, you can shoot them. Also implemented a scoreboard, that shows the players name, kills and deaths.

Following is a couple of screenshots.

Playermodel is rendered in brightly colors when alive, and dead players are rendered in darker colors, with the base block colored red instead of yellow:

http://www.ia-stud.hiof.no/~thomasw/img/fpsmultiplayer_screens/fpsmultiplayer04.png

http://www.ia-stud.hiof.no/~thomasw/img/fpsmultiplayer_screens/fpsmultiplayer00.png

Death/respawn screen:

http://www.ia-stud.hiof.no/~thomasw/img/fpsmultiplayer_screens/fpsmultiplayer01.png

The scoreboard, (and obviously PLAYER12 is cheating!):

http://www.ia-stud.hiof.no/~thomasw/img/fpsmultiplayer_screens/fpsmultiplayer03.png

Just a general picture of the level with some dead players in it:

http://www.ia-stud.hiof.no/~thomasw/img/fpsmultiplayer_screens/fpsmultiplayer02.png

So thats what I got so far. I think I will spend some time on the rendering side in the time to come, would like to add some more eye candy to it.

#19

I guess it is time for my update.

I’ve written a little editor where it is possible to create, remove and edit boxes, point lights and hemisphere lights. It is all done by swing components in a separate window. The changes are sent to all clients when the update button is pushed. So it will be possible to change the level while playing it. Although everyone will be killed and re spawned. Will use this functionality to make it possible to change level later. The whole thing is work in progress and a bit buggy at the moment.

The bullet collision detection bug is fixed. And there is a kill limit now. when it is reached the game ends. At the moment it is not possible to restart.

The renderer now supports textures (wow), normal mapping and specular intensity. And there is a skybox. But I haven’t found any free textures with normal maps yet. I’ll include some screenshots when I do.

There are so many things I want to do, I’m not sure where to start.

I want to improve the avatar a bit. It will look abit like my forum avatar. But with eyebrows and a mouth. The bullets will probably be shot from the nose or the mouth. The eyes will by synched so the look up and down as you move the mouse. Will add some arms that go back and forth and flap like cracy when falling. Must add some little feet that spin as well.

I want to make it possible to play on the internet as well as on a LAN. So I want to look into NAT punch-through to make it possible to play behind routers. This will probably mean using udp :frowning:

Would be fun to throw in some good old demo effects. Was thinking of creating a wormhole effect instead of using a skybox. Could animate textures using fire effect.

Or I will just realize it is to much work and give up.

[quote]Lately I have been working on my own scene graph
[/quote]
hehe, just what the world needs. Yet another scenegraph :stuck_out_tongue:

#20

Thanks! :slight_smile:

The DeltaCompressor on the sending side uses the last data sent to send only a diff. The diff is a series of copy (from the last data) or append (to add new data) commands, very similar to GDIFF (but isn’t GDIFF). The DeltaCompressor on the receiving side uses the last received data and these commands to build the new data. This is all transparent to your app, which just sends and receives objects. The Delta class is used by DeltaCompressor to do the actual work. It takes two buffers and checksums chunks of data to automatically generate the diff commands. Eg, the first send would be something like “append 100 bytes: 100 bytes of data”. The second send, if you added 10 bytes at offset 25, would be “copy 25 bytes at offset 0, append 10 bytes: 10 bytes of data, copy 75 bytes at offset 25”.

If you had an object graph with a string somewhere in the middle that changed length, only the changed data would be sent (with a tiny bit of overhead for the copy/append command bytes).