Koalabeast Games

Page 3 of 4

The Spike Does Not Move

spikes

This week we worked on the design for the spikes. We all wanted a style that was similar to classic  that would fit in perfectly to our new design. The screw head for each spike is oriented a bit differently to give each of them some sugar.  In other news, this week viewport scaling and mousevent code has been added to the map editor. The client/server branch has been re-factored , and a neat data serialization portion added.

 

Discuss this post on Reddit

Speed Boosts Graphics, Client/Server and Material UI

The tooling for the map editor is coming along, hopefully we have something to show in a couple of weeks. On the same note, progress for the overall user interface is happening. You can expect the new user interface to work more like an application and less like a web page. Right now, it’s looking like we are going to use a Material UI framework for the user interface. This will provide us a smooth and simple UI that will scale well to smaller screens if needed.

We have speed boosts graphics! In TagPro Next speed boosts will be spinning discs that hurl a player when touched – we hope you like them. We also have the very beginnings of the client/server communication working. You can see both the speed boosts and the client/server in action in this week’s video:

Discuss this post on Reddit

UDP, Floors, Parallax Scrolling and Live Map Editing

screen01

We have some new graphics to show off. The basic floor tile and background are complete. The floor tiles have subtle differences instead of being completely uniform – we really like the end result. The overall theme of TagPro Next will be a technical one, thus the circuit board background. It’s likely we’ll have some subtle animations included in the background. Parallax scrolling is also implemented for the background which you can see in the video below.

We’ve begun working on live map editing. The goal is that the map editor will be implemented within a special TagPro game. So you’ll launch yourself into a game to create TagPro maps. This will allow you to roll around and test your maps while creating them. We are even planning on allowing you to invite your friends to your map editing sessions to assist you. Check it out in the video below.

We’ve made some strides in the UDP library. For those less technical, UDP is a different method of making computer talks with each other. For gaming purposes, switching to it should result in less noticeable lag. We’ve opted to write our own library for ordering and guaranteeing UDP messages – we’ll likely open source it.

It has been pointed out that the parallax scrolling in the previous video was wrong. The background was moving faster than the foreground. It’s been fixed here and looks a lot better.

Discuss this post on Reddit

New Koalabeast Logo and Engine Progress

First, join us in welcoming the new Koalabeast. As our new company logo, you’ll be seeing more of this devious little jerk.

New Koalabeast Logo

More progress has been made on the prototype engine. A lot of it under the hood while refactoring the Pixi.js rendering code. We did add the flag/base to the engine and were really pleased how such a small thing breathed life into the game. We’ve also began adding controls to the engine so that we can easily tweak the physics of the game while playing. You’ll also notice the camera is locked to the player now.

Discuss this post on Reddit

TagPro Next Status: Artist, Flags, Joiner and Engine

TagPro Next has an artist! We’re really excited to be moving forward with Sergey Basov as the artist for the new TagPro. Sergey is an experienced game artist who has worked on assets for Game of Bombs – A great web game that you should check out. Here Sergey’s first draft of the new flag and base for TagPro Next:

TagPro Next Flags

The first iteration of the new joiner is complete and code reviewed. It’s looking awesome and will really allow us some flexibility on how we join players to games. For example players will be able to specify if they’d like to play in casual games or stat games – and which game modes they’d like to participate in. There is still plenty to do on the joiner, but it’s coming along nicely.

A lot of progress has been made on the prototype game engine. So much so that it will likely become the foundation of the new engine. We’ll be putting some work into adding a UI that will let us easily adjust movement and physics settings, so we can find the perfect feel for TagPro Next. Here is a video of LuckySpammer playing around in it:

Just a reminder, we don’t post all blog update to /r/TagPro – just the most important ones. However we do post all updates to /r/Koalabeast.

Discuss this post on Reddit

RPC, ES6, and Proxies, Oh My!

Today we’ll be kicking off the first in a series where we go into more technical stuff than we have in the past. Not everyone will enjoy or even understand these posts, but we hope that it will give those of you familiar with javascript some neat ideas.

Our experience with TagPro made us weary about large monolithic servers. The DDoS problems grew out of control and there was no great way to get around it. As long as we have large servers, we’re vulnerable to simple DDoS attacks. While thinking about the design of Next, we realized that many of our problems could be alleviated by switching to microservices.

We have a microservice for database access, a microservice for player management, stat management, the joiner, and more. This gives us great flexibility and a lot more resilience than in the current model. However, any of you who have tried using microservices before know that communication is problem number one. There are lots of prerolled solutions out there, but all of them have issues in one way or another.

All we wanted was a dead simple RPC library, and no active library we could find would support what we wanted without significant hacking. So, we decided to build our own. We call it Intercom.

Before delving into any of the code, some background. We are using ES6 extensively throughout this project; most of it is transpiled via babel (formerly 6to5), but there are a couple of features of ES6 that are not transpilable. The one we care most about for the purposes of this discussion is the Proxy object. There’s not a huge amount of documentation for it out there, and its syntax is fairly wonky, but it’s immensely powerful.

A good comparison for it is __getattribute__ in python. Any time you attempt to look up a property on an object, the proxy will intercept it and allow you to override it. So if I call x.blah(), the proxy (x) can decide to send whatever it wants for the “blah” member, which will then be invoked. It’s a great way to accidentally get into infinite recursion.

Why does this matter? It allows us incredibly clean syntax, as you’ll see shortly.
There’s one more thing you should know. We’re using the wonderful ‘co’ library to make our async much cleaner. As a tl;dr, it abuses ES6 generators simulating the async/await features coming in ES7. So for example, it turns this:

Into this:

While it may not seem that amazing in such a small example, when your results depend on 8 different callbacks it makes all the difference in the world.

So, with that out of the way, let me show you how this library is actually used. It’s gone through a lot of iterations, but I think we’re rapidly approaching what the final syntax will look like. Here’s an example of its use from the tests:

Now, this is with an already connected RPC client, but if you have any experience with JS rpc libraries you can see a big difference, in that you can call the actual method name as a method. Before we implemented the proxies, here’s what it looked like:

While still usable, it certainly wasn’t clean. We also had a version that didn’t require the []’s, and also another one that use objects instead, but none of them were satisfying to me. I knew we could do better.

So, how does this magic proxy work? I’ll deconstruct the code below:

It’s a formidable block of code, but we’ll take it one step at a time.

Pretty simple start. We’re just creating a proxy to be used later, and requiring a scope argument. Due to the fact that a proxy is an object we need to provide an explicit outside scope as this can’t be rebound in an object, and that’s what self is.

This is where the magic begins. The Proxy object is a built-in in ES6, and we can only use it using a special experimental flag on io.js, but it’s worth it.

This is called whenever a lookup is done on the object in question. Spoiler alert, we assign this proxy to .rpc, which means if we called yield client.rpc.add(99, 98), then o will be the actual object (not actually used), and name will be add.

This just checks if the object actually has the property we want, and if it does, return it.

This uses the new ES6 syntax allowing a variable number of arguments. Basically we’re creating a decorator function which can accept any number of arguments and will pass it along the network and handle everything else.

Creates a promise, pretty standard stuff.

This allows us flexibility over how long we want a request to hang for. Due to the microservice nature of Next there’s always the potential for a server to be down or hanging, and we want to be able to deal with that if that’s the case.

We’re just grouping together the options to be received by the intercom library on the other side. Nothing fancy, except args is that array from before that I mentioned.

This uses socket.io (for now, we may change to something more low level eventually) to just emit the RPC call to the server, and reject it if it had an error, or resolve it if it didn’t.

So, that’s the client side code. The server side code is quite a bit more complex!

Boy, that’s a lot less clear than the client side code.

All this is doing is handling connections, and once connected it checks if we’ve defined a server api. Let me show you what a server API looks like so you can understand what it’s doing from here on out:

All this does is create a server on 9090, and put those functions into the API. So in the previous code, it’s just looping through those functions.

So now we set up a wrapper. We accept any args and a callback. If there are no arguments, we make an empty array. We push the callback onto the end so if a function wants to handle the callback manually it can.

Then we check if it’s a generator function. If it’s a generator, we want to run it in co before we do anything (like slowEcho above.) So if it is, we apply it with socket as this and then handle the callbacks. If it’s not, we run the function and check if it returned anything. If it did, then we complete the callback with that return data. If it isn’t a generator and it isn’t returning anything, we assume the function is handling the callback itself.

Then we just store that wrapper as what should be called whenever that name is called. This is a Map, a new ES6 data structure very similar to dictionaries in other languages.

Finally, we set up the listeners. If we get any data on the ‘rpc’ channel, check if it has a command. If it has a command, check if we have it. If we don’t, error that back to the caller. If we do, run that wrapper function!

It’s a bit of behind the scenes setup, but it allows us to very easily talk to microservices without the usual syntactic overhead. A simple connection and we’re calling dot methods without ever having to communicate with the original server to get a list. This is also useful as it allows us to modify the API on the fly without the client needing to be notified about it.

As an aside, this library will be open-sourced as we feel it has a lot of utility outside of TagPro.

That’s all for this week. If you have any questions about this code, please do feel free to ask!

Discuss this post on Reddit

TagPro Next Status – 2015-05-10

Over the week we worked with three artist on a single asset: the flag. It’s going really well and it’s a lot of fun watching the artists go from concept to polished asset. By next week, we should have the TagPro Next artist selected!

The author of another web game approached us over working together going forward. Not necessarily directly on each other’s products, but in more of a partnership. It’s likely the two teams will meet soon to discuss further.

We are developing a scaled-down prototype engine for experimenting the new “feel” of TagPro. It will allow us to easily test things like friction, acceleration, max speeds, boosts, ect. It’s also testing the normalized movement – being that moving diagonally will no longer allow you to move faster. It’s possible in the future we will produce a build of the prototype with the values we decide on for community feedback.

AMorpork plans to produce a blog entry the coming week on our inter-process communication layer for TagPro Next: Intercom. It’s fairly unique and a piece we plan on open sourcing.

Discuss this post on Reddit

« Older posts Newer posts »

Copyright © 2017 Koalabeast Games

Theme by Anders NorenUp ↑