Chuck Game
-
Chuck is not dead!
In the last year we’ve been super busy implementing a lot of functionality into the game which we didn’t blog about.
The good news is that we released an alpha version and already completed two alpha test sessions with our small community of testers (see screenshot), which went really well.
It is really great to get feedback after such a long period of developing on our own. We try incorporate the opinions into our workload and there is lots to do.
Last but not least, here is a rough list, of what we did since the last time, we:
- gave each players t-shirt a color (implemented with WebGL shaders)
- rebuilt the controller system, running and jumping has been dramatically simplified and throwing now works by drawing in a line (see how to play)
- added a layer system, which allows background images and non colliding tiles with relative parallax scrolling - it looks damn cool
- made a nice new score overview, for when you press TAB
- built ourselves a deployment system for different environments (dev/production) with pm2
- did lots of bugfixes / optimisations
By the way, if you would like to join the test team, click “Request Invitation” on the top left and fill out the short form.
-
UDP sockets in the browser with WebRTC (node-webrtc)
Realtime multiplayer games need fast fast network communication and it is often desirable to always get the newest information about the current game state. For example with player positions it is not necessary to get every single position update. Instead it is more important to receive the current position as fast as possible.
Unfortunately browser games like chuck are limited to the current websocket implementations for this kind of realtime communication, which only supports TCP connections. TCP provides reliable, ordered and error-checked delivery, which means that obsolete data will block and queue up the arrival of relevant new data. Another connection protocol is called UDP. It does not provide order and reliability and is therefore often used in these kind of contexts.
About a year ago while once again researching the possibility to use UDP in the browser, we found out about WebRTC, which is built on UDP. It allows peer-to-peer connections between several clients. So far, it is primarily used for audio and video communication in the browser, but it also implements “Data Channels”, which can be used to transfer arbitrary data.
For this to become useful to us, we would need a node.js module, so that our game server could act as a peer-client and send/receive UDP data from and to the browser clients.
We have been experimenting with the node-webrtc module for quite a while already, but since this is some pretty cutting edge stuff, there were always bugs and non implemented features, which prevented us from really testing if we could utilize it.
Today we have been able to build and install it successfully for the first time. We could successfully start the server and send data between the browser and a node.js server over WebRTC.
We tried to implement a little script to test if we could receive packages out of order. Every time we sent a package with data, we incremented a counter and attached its value to the package. The data was simply echoed back by the node.js server. The idea was to see how many packages would arrive out of order.
Sadly they all came back in order. Therefore we assume that some kind of order mechanism is still in place. node-webrtc seems to implement some settings to enable or disable this, but the lack of documentation makes it very hard to understand how to use it correctly.
For now, we decided to give up on this approach and we will try to implement a workaround for this positioning problem with TCP.
-
Levels and RagDolls
The last couple of weeks were awesome! The game has already become what I have been dreaming of years ago, when I started imagining the finished game - back then I clearly could not think any further ;) Here is what we did:
Maps
We found an open source tile based map editor called Tiled. With this editor it is much easier for us to create and edit maps. It is quite fun to create and refine new maps and it is really fast, compared to doing it manually in code like we’ve been doing it until now.
Obviously a new level loader was needed, so we had to adapt our code to it, or actually we extended our old level loader so it could cope with the new format called TMX, which a lot of games are compatible with.
Gameplay
For chuck.js to be a real game it needed some kind of gameplay. We have many cool ideas which we will implement over time. The most obvious (and actually original) one is that you throw things on your opponents and they lose health if you hit them. How much health they lose depends on the impact of the object hitting them. The force is a combination of velocity and mass, the higher the velocity and the higher the mass, the more damage they do.
Because we wanted to see the opponent’s health but didn’t want to see it all the time, we added a small bar over everybody’s head which shows their health, but only for 2 seconds after they’ve been hit by someone.
After you lost all your health you die, your death count goes one up and the kill count of the player who hit you goes one up. While dead your dead player body is replaced by a rag doll, which you can’t control anymore.
RagDoll
It took us one whole day to implement some kind of a rag doll, which still isn’t optimal. Your dead body is converted to an object that you can carry and through at others in the game and be used as a weapon for some time. As long as someone is carrying the rag doll, it is just a normal object, but it disappears some time after the last player has dropped it, right now it is after 25 seconds.
When even after a day of development, the rag doll did not look great it came to my mind to look for something like a Box2D editor to solve this problems and we found one! Sadly not open source, but quite cheap, it was only €22 and absolutely worth it. It is called R.U.B.E (Really Useful Box2D Editor). This one is even more awesome. You can create whole Box2D worlds in it with objects, images, joints and what not. Basically you create the whole physic world together with the images and background images and can export it to a file which you later on can import to your game. I think it is best explained in this video:
We didn’t have the time to rewrite the level loader code so it would work with the R.U.B.E files yet. But we’ve been playing with it a bit and made a rag doll, which looks so much better, than the hard-coded one. We will use it as the dead body, check out this live example:
(click and drag chuck, to move him around)
The next steps will be completing a real game play ending with rounds, where we choose a winner after some amount of kills and load the next map and restart the game and so on.
-
At the moment we are more determined towards the game then ever. We got a huge chunk of work done during the winter holidays and now we meet at least once a week for a dev session. We implemented a couple of new features and bugfixes. Also a few new items: A bouncy football and even a skateboard to roll around with! :D Stay alert for new things coming up!
-
Collaboration! As a coincidence, while adding the first items to our development map the banana item happened to spawn where you normally can’t reach it.
It just so happened that we became obsessed with trying to get the banana which was only possible in collaboration with at least another player by jumping on each other in the air.
I really liked this kind of gameplay :).
-
Fight! Here you can see how fantastic this game has already become. There is a lot of action involved and friends who had the privilege to alpha-test it were stunned and quite entertained.
This is a recording of the game running on a real server on the internet, one client in Germany and the other in Sweden. So far we’ve been testing it with up to four concurrent players and it is playable even on older hardware.
-
Refactoring, Animations, Items
During a big refactoring milestone, we decided to use require.js for loading JavaScript files and figured out how to share code between the server and the client. We implement shared code in “Core” modules, which server and client inherit from.
After that we were quite busy, implementing graphics, animations, spawning items and grabing/throwing them. We first implemented graphics and a camera module through a WebGL enabled 3D rendering engine called Three.js, but because of performance issues we decided to go with a newer and faster 2D engine called pixi.js.
-
box2dweb-network-synchronisation
From what we have learned from trying out other box2d network systems we put together our own demo of Box2d networking called box2dweb-network-synchronisation.
It features a client- and serverside Box2d instance, so there is an independend engine on both sides.
To keep all physical worlds in synch we declared the server world the “master” world, which at a certain rate updates all clients with a world update. It contains position, rotation, linear and angular velocity of all objects.
Feel free to fork and play with it!
-
getting down to it .. Box2d network physics tests
onedayitwillmake’s RealtimeMultiplayerNodeJs
The search for a game engine led down an interesting path. As me and Jeena did some research on Cocos2d, we found this misterious repository, which was promising a demo for actual network physics - meaning that physics would be calculated on the server and the objects would be rendered in the clients webbrowser.
But as we followed down the pathway of installation and configuration we stumbled upon some difficulties because it just did not work. So we had to write to the wiseman of the misterious repository to ask for guidance. But eventually we got it to work without him.
I checked the performance on the server. And during multiple client testing we had 100% cpu. So the bottleneck did not seem to be the internet connection. After starting the application without clients connecting to it, it had around 70% cpu, so apparently it was the physics calculation that caused high load.
The server is a cheap 1&1 virtual server, that has 4 virtual processors at 2000 Mhz, of which node.js can only use one unfortunately. Also 2 gigabyte of ram.
So this was not gonna get us anywhere.
agentcooper’s box2dweb networking
After some more research we found another interesting demo. This one was cool, because it had a Box2d engine running on server- and client-side, which were going to be synchronized. This is what we were aiming for. Check out the demonstration video.
Due to a missing package.json, I did not know what version of socket.io had to be used and the most recent version did not work. So I put in the effort to clone and repair the repo - meaning to update it to the latest socket.io version.
This was already pretty cool, and very smooth and all, but the downside was that only mouse joints were transmitted and synchronized, which was causing the box-positions to go out of sync after a while.
Anyway, it made us confident to experiment with physics synchronization ourselves.
-
changing directions.. javascript ftw
Just a few weeks ago, I coincidentally discovered that someone had brought out a new JavaScript port of Box2d called box2dweb and I was quite suprised by the fact that it looked exactly like the flash demos and seemed to have the same speed.
So I started experimenting with it and decided, that I would simply rewrite the game in JavaScript, whohoo! Finally the development for chuck could go on.
Generally, games written JS seem to arouse peoples interest much more than AS3 games, at least with people I know ;). I set up a facebook group to discuss a few aspects and to gather opinions on different possible frameworks and technologies to use.
Here is a list of interesting frameworks that we are considering:
- Three.js a mind-blowing hardware accelerated webGL engine
- Tween.js for smooth animations
- Illuminated.js very nice looking lights and shadow engine
- Cocos2D the js port of the 2D game/graphics engine based on cocos2d-iphone
- Isogenic Engine very interesting game engine but at least 250$ for a license
- ImpactJS another really cool game engine - 99$
- IvanK Lib Flash style WebGL powered graphics engine
If you happen to know anything worth a look, let me know :)
-
initial commit.. the history of chuck
I’ve decided to start a blog about the game I am currently working on with a few friends in our free time.
The idea is to create a game, where people login on a server and are able to jump and run through a physical world. They can pick up any objects that lie around, for example household items like, knives, television, refrigerator, etc. and throw it at the other players (inspired by throwing knives in the free 2D action game Soldat).
I actually started writing this game in ActionScript 3 back in 2009. But after a while it got clear, that physics had to run centrally on a server. It was the time when node.js (javascript runtime for networking/servers) was talked of everywhere and we were thinking about using it on the server side.
At that time Jeena was preparing his bachelor thesis - a generic game server in erlang. He started helping me out with finding the right technologies for chuck.
But what we really wanted, was a server in AS3 in order to be able to reuse game classes. So we started looking for possibilities to run AS3 on the command line and found out about the tamarin and redtamarin projects. We spend a few days trying to get the game to run in it, but had no luck. After this, we stopped development for a while. It didn’t seem like the right technology.
