September 14, 2014

Racing Tower Workshop

Over the past few years I’ve been working for the Swansea University branch of Reaching Wider. Reaching wider delivers workshops to under-represented groups in higher education, it’s about raising aspiration. I deliver a lot of workshops, some have worked some have not. I figured it might be useful to start sharing some of the workshop ideas.

One of the workshops I’ve run a lot is something I call drag racing. This is aimed at primary school kids, you can see me running it here, that’s my sleeve in the background.

The drag racing activity is pretty simple, but at the same time tricky to explain. You split the kids into teams and give them all remote control cars. With only paper their job is to sabotage the car, which will be driven by another team, with the rule not to touch the wheels or create anything which touched the floor. This activity takes place after a mind mapping activity on fast and slow things, idea being that the kids think about cross sectional area. It’s a nice exercise but really is only suited to young kids. Last week I was asked to run something like this but with older kids, 13 plus, this is what I came up with.

Racing Towers

Equipment

Remote control cars – the bigger the better, you can get these pretty cheap, 1 per group
A4 paper – thicker high quality stuff works best, 5 sheets per group
Parcel tape, 1 roll per group
Tennis balls, 1 per group
Scissors
Tape measure
Stopwatch
Something to make a race course out of, I used chairs

The 'race track' just a simple slalom — The ‘race track’ just a simple slalom

I made a very simple presentation to go with the workshop, you get it here. The first slide is a Bloodhound SSC video which I included because Swansea University are heavily involved with the project. It also helps introduce the key idea of the workshop which is optimisation.

So I start out by playing that video then roughly going over the following points:

The Bloodhound is going to go really fast, it’s kinda crazy actually
Designing a thing to go 1000mph with no constraints would not be so hard, what makes it hard is doing it without killing someone
Then I talk about the design of the intake duct, make it too big and there will be too much drag, too small and not enough air will get inside

This then leads into the brief for the workshop: using 5 sheets of A4 paper design something to carry a tennis ball on your car during a race. The rules of the race are:

The team with the lowest time wins
There will be three laps
If the ball falls off the car the timer keeps running, the driver must stop until a second team member puts the ball back
The teams final time will be divided by the height of the tennis ball, when the car is stationary, in centimeters

That’s pretty much all you need to know. The kids quickly got the idea that their choice comes down to making a tall slow tower or a short fast one. A few things surprised me on the day, they did not take long to build the towers at all. You could either enforce a design period with no building, or have a series of races with only the best time counting. The second option would give an opportunity for design refinement. I was also surprised how close the end scores were, this was despite the difference in driver skill. Talking of which, if you have an extra pair of hands get them to set up a practice circuit and let one member at a time from each team try their hands at racing. Make sure you test the cars before hand, some cars can be tricky to control. Also don’t assume everyone has driven a remote control car before, make them follow the car it helps some people figure out which direction to turn.

The workshop is simple and you could expand on it in a number of ways. If you do try this I’d love to hear from you on twitter or in the comments below to see how it goes and share other ideas.

June 14, 2014

Thinking about cameras

Simultaneously the most important and most unnoticed element of most games is the camera. Since I spent a number of weekends working on the camera in Slingshot, I thought it warranted a blog post.

Slingshot is implemented in javascript using the Phaser, so this post will lean towards that particular framework. Phaser has a number of pre-set camera follow methods, these are all great but not exactly what we wanted in slingshot.

When you create a phaser game a camera is created, and changing the values of game.camera.x and game.camera.y will move the camera. The goal is to write a function which updates theses coordinates. There are many ways to do this and rather than talk about those I’m simply going to show you the code currently in slingshot and go through the reasoning behind each step.

Before I started writing the code I needed to think about what the camera needed to do. I wanted it to be reasonably loose, like the camera work in battlestar galactica or the new star trek films. Rather than aim for the camera centre to match the players position I wanted it to be pushed in the direction the player is facing, giving you more awareness in that direction. Since the gravitation motion in slingshot is quite complex I also wanted to pull the camera slightly in the direction the player is actually travelling in.

The screenshots above gives an idea of the thought process I was going through, and is an attempt at a visual representation of the algorithm. The two points we need to calculate are pLook which is a point in the direction the player is facing, and pTravel which is the direction the player is moving in.

In phaser we can get the angle the player is facing simply from player.rotation where player is the sprite object representing the player.

To make the camera more loose, rather than using the players current rotation we can store an average rotation, rotAver. This is updated by rotAver = (99.0 * rotAver + player.rotation) / 100; which is effectively the average over the last 100 frames. Once we have this angle we can use some phaser magic to calculate pLook.

var pLook = new Phaser.Point(player.x + 0.75 * viewDist, player.y);

pLook.rotate(player.x, player.y, rotAver, false);

Here viewDist is a variable which controls the distance from the player to pLook. In slingshot pLook is calculated as half the camera height, but this is something you can play with.

Calculating pTravel in most games would be easy, in phaser the current direction of travel of the player is stored in player.angle and you could simply use this angle as before to draw a straight line to pTravel.

In slingshot however the pull of gravity from all the planets means the player is never travelling in a straight line. To get around this we can use the equation of motion new position = old position + velocity*time + 0.5*acceleration*time*time to predict the next position of the player.

In phaser the time (in ms) elapsed since the last frame can be accessed in the variable game.time.elapsed Then using all the physics variables in player, and making sure the units match we can find pTravel as

var pTravel = new Phaser.Point(player.x + (player.body.velocity.x * game.time.elapsed * 0.001 + 0.5 * player.body.acceleration.x * game.time.elapsed * 0.001 * game.time.elapsed * 0.001),

player.y + (player.body.velocity.y * game.time.elapsed * 0.001 + 0.5 * player.body.acceleration.y *game.time.elapsed * 0.001 * game.time.elapsed * 0.001));

It is true that in a lot of cases pTravel is not going to be that far away from the player. However in slingshot the acceleration gets quite large, and the inclusion of pTravel ensures that the player always remains on screen.

pTarg can then be simply calculated as the mid point of the line between pTravel and pLook. Since we want the camera to be smooth we don’t just set the camera coordinates to the target coordinates, we ease it towards the target in the following way.

var pTarg = new Phaser.Point(targX, targY);

     var t = 0.0;

     var dx = game.camera.x - pTarg.x;

     var dy = game.camera.y - pTarg.y;

     t = 0.7 * (Math.abs(dx) + Math.abs(dy)) / viewDist;

     t = Math.min(t, 1);


     //Offset to center of camera

     targX = targX - 0.5 * game.camera.width;

     targY = targY - 0.5 * game.camera.height;


     game.camera.x = game.camera.x + t * (targX - game.camera.x);

     game.camera.y = game.camera.y + t * (targY - game.camera.y);

The variable t controls how quickly the camera catches up with the target, I’ve tried to make it so that the further away the camera is the quicker it moves to the target.

Finally the next lines

 if (camShake) {


       game.camera.x = game.camera.x + game.rnd.integerInRange(-1 * camShakeAmplitude, camShakeAmplitude);

       game.camera.y = game.camera.y + game.rnd.integerInRange(-1 * camShakeAmplitude, camShakeAmplitude);

       camShake = false;


     }

Allow us to shake the camera simply by setting camShake to true anywhere else in the code. For example any time the player takes damage. In slingshot the shake amplitude is set to 2 pixels.

Hopefully this has given you an idea of the work that goes into something which is only noticed when it goes bad, and hopefully it has given some of you some ideas of how to write camera follow code. You can try the game here and let me know what you think of the camera.

Slingshot is a roguelike ‘like’ space shooter with realistic orbital mechanics, developed for HTML5 using Phaser. You can play the game here To keep up to date follow me @DrSeanWalton and Barry @Half_Hit_Points on twitter.

May 30, 2014

Implementing Flak

Towards the end of my previous post I started talking about submarine combat. Firing a torpedo isn’t just a case of point, shoot and hit. The target is tracked, its course is predicted and the torpedo is essentially programmed to explode in the targets path to cause the damage. It’s not only submarines which do this, but also certain kinds of anti-air flak cannons. Below is a flak avoidance training video from world war 2 which shows how these anti-air guns worked.

Flying among all those explosions must have been terrifying and very stressful. I thought why not add some flak cannons to the mother ship in Slingshot? There wasn’t much information on-line about how to implement flak, so here is how I tackled the problem.

I had three main goals with the flak in slingshot: 1) The effect needed to look cool, 2) I wanted players to be able to watch the flak training video and gain an advantage from it, and 3) I wanted it to be more deadly the closer you got to the mother ship.

To achieve the first and second goal I’d need to model the flak cannons somewhat realistically. The problem comes down to plotting an intercept course, a very simple one. We know the players position, P1, and velocity, PV. If we call the position of the flak cannon F1 and the firing velocity of the flak FV. Then…



P2 = P1 + t*PV

where t is time. If we want the flak to hit the player at P2 then…



P2 = F1 + t*FV

which leads to…



P1 + t*PV = F1 + t*FV

The flak shell needs to explode at P2 which means t is the length of the fuse we want to set in the flak shell. I decided to change t depending on the distance, R in the diagram, from the player to the mother ship. Clearly a smaller t would give the player less time to change course to avoid the shell. So the closer the player is the lower the value of t, which means the closer you are to the mother ship the more deadly the flak. Once an equation is set up to work out t at a given value of R we simply calculate it and use



FV = (P1+t*PV-F1)/t

to find the launch velocity. A value for the fuse length on the flak shell is set and we fire it at the launch velocity. If the player is within the explosion effect then do some damage. Hopefully that made sense…

I’m quite happy with how the effect turned out. In slingshot I’ve made the gravitational pull of all the planets and sun effect the motion of the flak. This means you get some interesting results and effects. I’ve also set the range of the flak quite large but the vision of the mother ship low, but I’ve implemented communication between the AI. Smaller ships can effectively spot for the mother ship.

If you want to see the effect in action you can play the game right now. It is a javascript game so you can play it in your browser, just fly towards the red dot on the map, and as always let me know what you think!

Slingshot is a roguelike ‘like’ space shooter with realistic orbital mechanics, developed for HTML5 using Phaser. You can play the game here To keep up to date follow me @DrSeanWalton and Barry @Half_Hit_Points on twitter.

May 14, 2014

In space games everyone can hear you scream

My science teacher once told us that Star Wars was silly because sound doesn’t travel through space. He was right about the science, but a silent Star Wars would be more silly than the one we got. Why is it that whenever the enterprise meets an alien ship they are always the same way up? The crew on each ship don’t share the same language, have never met each other and yet they seem to have a pre-agreement to which way is up which itself is a tricky concept in space. The real reason that they are always the right way up is that it would look silly otherwise, and wouldn’t match viewer’s expectations.

Space combat and manoeuvring in most sci-fi games is wrong, but for good reason. You can think about playing a game like a simple cycle. You make some come kind of input, move a stick, press a button, do something stupid in front of a kinect. This input is read by the game and the game’s internal model updates, this could be mario jumping, a racing car accelerating or firing a bullet in call of duty. What ever way the designer decided to model the physics and behaviour of the things in the game happens. This code runs and causes some kind of feedback, sound, visual or rumbling. Then you the player see, feel or hear this feedback and use your own internal model and ideas about how the game works and makes an input. If space games modelled space flight and combat realistically the model in the game would be, in most cases, wildly different to the model in your head. You would get frustrated, think the controls in the game don’t work stop playing and go back to watching cat videos.

The thing is I actually think realistic space combat is an interesting thing to think about. There are lots of articles you can find which discuss what space combat would be like if it happened. Here I’m going to talk about what I think it would be like, and how this is the way we want our upcoming game, Slingshot, to feel.

Star Trek has lots of artificial fake gravity, but it’s missing the real stuff. All space flight is governed by orbital mechanics which results in some weird rules. Lets say you are in low orbit around the Earth and you want to get to the moon. The best way to do this is to point your ship in the direction of the orbit and burn your engines. This means you’re not facing the place you want to get to, which understandably is weird to most people.

This means space warfare might be more like sailing ship naval warfare than dog fighting. Then the direction of the wind had a massive impact on a battle and was an invisible force to fight against, Sid Meier’s pirates does a pretty good job of creating an experience like this. Watch the video below to see how much the wind dictates the series of events. To win you really have to think about how to use the wind to your advantage.

Imagine this on a much larger scale orbiting around a planet and I think you are getting towards what space combat would feel like. In Slingshot you will be flying around solar systems which full Newtonian physics models. Planets orbit a star and you have to use the gravity and your engines to get around. Slingshot is a two dimensional game viewed from above, much like Pirates, to make manoeuvring decisions easier to make.

Not only would the ships themselves be effected by orbital mechanics but also the projectiles. Lets for now dismiss the idea of laser weapons and assume you’re going to use big projectiles to try and break through the hull of an enemy ship. The projectiles you fire will be orbiting and as soon as you fire them you’ve lost control; hitting your enemy is going to need some planning. This is just like the kind of thing which was done in world war 2 submarine combat. A submarine’s weapons officer would have to calculate a torpedo firing solution after stalking a prey. In both cases the smallest hull breach could be fatal. If you want a good taste of submarine combat check out the Silent Hunter series.

In Slingshot all the projectiles and item drops are effected by the gravity. This means you are going to have to build a good sense of how things move in the environment. It is possible to literally shoot yourself in the back if you are not careful.

Similarities between submarine and space combat doesn’t stop at the weapons, you are inside a tin can keeping out impending death. As you loose health in Slingshot you’ll start to hear creaks and cracking, I’m hoping this will add some tension. I want to try and make you feel claustrophobic playing the game, like you would feel in a submarine. Since the view is from above the only way I can see to do this is through the sound. The creaks and cracking, the sound when you are hit by an asteroid or projectile, and eventually the sound of your own breath. Sound which, by the way, will only be from things inside or hitting your ship, just like my science teacher would have wanted.

Slingshot is a rougelike ‘like’ space shooter with realistic orbital mechanics, developed for HTML5 using Phaser. You can play the game here To keep up to date follow me @DrSeanWalton and Barry @Half_Hit_Points on twitter.

April 27, 2014

Capturing the Feeling of Homeworld

Earlier this week I was listening to the radio and Adagio for Strings started playing. It straight away took me back to a defining period of my childhood, the original Homeworld. This was the first game I played which really made me feel something, probably was the first media that did this actually. If you haven’t played the game you really should, it does so many things right. There is a remake on the way, but I’m sure there are other ways to play it.

Below is an edited version of the mission where Adagio for Strings is used phenomenally well to set the tone of the whole game (obviously that has spoilers, as does the rest of this post). The basic story in Homeworld is that your species found an ancient map which pointed to a system in space labelled “home”. This leads to the invention of warp drive, skip forward a few years and you the player is put in command of the mothership which is to make the maiden warp flight. The aim of the test flight was to meet with an engineering ship which had travelled into space using sub-light engines. You warp and arrive to see this ship has been attacked and destroyed by some unknown force.

After warping back home Adagio for Strings starts playing. You arrive home to see your entire planet burning, you’re tasked with defending some orbiting cryochambers which hold the only remaining survivors of your race. The mothership reads the statistics of numbers of survivors as you bring them on board, it’s very chilling and you can even hear the sadness in the hardened admiral dude’s voice. It is a brilliant moment in gaming and, perhaps surprisingly, it happened in a strategy game.

Homeworld doesn’t stop there to make you feel something. The genius of the game is that there is a finite set of resources throughout the entire campaign. A decision to build 10 weak frigates or 5 mining vessels in the 3rd mission might mean you can’t afford that battleship in the last mission. This really makes you care about every unit and every decision. It makes you try and disable hostile ships so you can salvage them. It makes you stay behind and mine every last asteroid even when the mission is won. It’s the kind of feeling you get playing a game like DayZ scrounging for cans of beans, celebrating finding a single bullet for a gun you don’t have yet. This is the kind of thing I love about games and is something which I failed to achieve with Waltonia.

It is this kind of feeling I want people to have when playing our next game, Slingshot. In the game you take control of a single ship which has lost it’s fleet and damaged it’s warp navigation systems. Your job is to survive and try and find a way home.

The emotions and feelings we are shooting for largely comes from Homeworld. Feelings of loneliness and desperation as you scrounge for warp fuel and aimlessly guess how to get home. These are relatively easy to represent, the scale of the system compared to the player, the infinite (yes infinite – procedural generation for the win) number of systems to search through, seemingly overwhelming odds, correct choice of music.

A slightly more difficult feeling to capture is itself hard to define. It’s something we all experience a lot throughout life, the feeling that you can’t balance things. I need to plan a talk for next week, but I’ve also got to mark some students work, and my shirts need ironing. In Homeworld this comes from trying to micro manage all your units, you can’t possibly look at them all at the same time so you have to decide which units will be fine figuring out stuff by themselves. This kind of feeling comes naturally in strategy games and any games where you are controlling a number of units. Another example of this would be trying to play Broodmother in DOTA 2, if you don’t understand that reference watch this…

So how do you make the player feel like she has lots of things to balance when there is only a single unit to control? This is what we are currently considering now and haven’t really come up with a solution.

Initially I wanted to have some interaction with you and your ships crew, they’re lost as well after all. Do we force the player to have to spend time looking for food for instance? I didn’t like this idea because it would probably amount to having some kind of energy bar which always decreases and some item you have to find, all kind of arbitrary. Perhaps a stress indicator might be a better idea? Much like how in a game like ARMA 3 if you run for ages it’s really hard to shoot anything because you are tired. Would a system like that work, or would it end up just bring another arbitrary bar? We already have a shield charge system, just like the one in halo, which I guess results in the same decisions to avoid combat to charge shields every so often. I did wonder if having a virtual pet style game running to represent your crew might be a way to add this feeling, but might that become too complex, or worse just end up being a set of energy bars and click buttons?

Another, more subtle, way of adding this feeling could be in the controls. What if I forced you to take your finger off the flight controls to fire your gun? That would feel a lot like plate spinning while riding a bike, you would really have to plan your decisions.

The direction we are currently taking is to use the levelling upgrade system to make you feel like you’re balancing something. Barry came up with the idea of using alchemy as a theme for the game, imagine if alchemy was real and chemistry turned out to be the pseudo-science? That is the universe of slingshot, destroying asteroids in the game will be a way of mining gems which represent the alchemy elements, Albedo, Nigredo, Citrinitas and Rubedo (hope I spelt those correctly!). These elements will be how you improve your abilities and skills. Perhaps a certain combination of these elements will improve or change how your weapons fire, but if you save up Rubedo’s you can convert that into rare warp fuel and try warping to a new area. Perhaps your hanger deck will be a puzzle game, putting Albedo and Nigredo next to each other would have dire consequences. How do we dish these out to you? If every time an asteroid blows up all four elements fly off in different directions you would have to make a split second decision on which to grab.

There are lots of possibilities and I think the only way to know which direction to go in is to test them. Maybe a combination of some of these ideas could work quite well together. A four element upgrade system could be quite simple, but if we implement it carefully it will have depth. Now I want to go play some Homeworld…

Slingshot is a roguelike ‘like’ space shooter with realistic orbital mechanics, developed for HTML5 using Phaser. You can play the game here To keep up to date follow me on twitter @DrSeanWalton

March 2, 2014

Ordo’s Brain – Part 3

This final post discussing the brain of Ordo is going to detail how a series of numbers ends up effecting the behaviour of an opponent paddle in the game. It may get a little maths-ey but there is no avoiding it.

As much as possible I’ve tried to give the opponent paddle access to the same information a player has. Each different ‘program’ is a series of numbers, which are coefficients and constants in a function which takes that information and gives back a target position for the paddle. The target position is the equivalent of where a player puts their finger on the screen, Bruce coded the engine in such a way that the player and AI paddle are indistinguishable. The program from Ordo is essentially calculating where to place it’s finger on the screen.

In most ‘retro tennis paddle’ games the AI is simply sets the target paddle position to the balls y position. Difficulty can then be changed by simply controlling how fast the paddle reaches it’s target. If Ordo was a simple game then this would clearly be the best strategy and that would be kind of boring.

In an attempt to make things more interesting we added a few elements to the game which make it a little different. Throughout development we came up with lots of crazy ideas, from having portals flying on the screen, to having multiple balls with different powers. We found that the size of a phone really limits how much interesting stuff can happen in the space between the two paddles, so we settled for keeping things relativity simple.

The first key difference is that in Ordo the balls are modelled more like real tennis balls than other retro games. I’ll leave it to Bruce to explain more about this, but the important thing to know is that you can hit curve balls by adding spin. To encourage the use of a curve shot there are white moving paddles behind each player.

We have also added a powershot if you hit the ball with the centre of the paddle. The powershot speeds things up, so we added a score for each time you hit a ball which increases the faster the ball is travelling. This score is much less than what you get for actually scoring a goal, but it gives you a way of increasing your high score by keeping rallys going. It also means we can see how effective an program is even if it never scores a goal from how many times it hits the ball.

The last major change, important to know for this post, is that the main blue game ball will spawn other balls. These secondary balls are worth less points and will disappear after so many hits. They appear when the main game ball is travelling above a critical velocity, this again gives more ways of trying to get a high score.

Using some dodgy paint skills lets see what information Ordo uses to figure out where to move.

In the above image, P1 and V1 are the position and velocity of the player paddle. P2 and V2 are the average position and velocity of all the non-game balls, S1 is the average spin velocity of the balls. I’ve added a dependence on spin velocity because you can quite clearly see when a ball is curving. P3, V3 and S2 are the same variables but for the game ball. The variables are combined in a non-linear, pretty fudging complicated, 31 parameter function to give a y-value which is where the programs virtual finger sits on the phone screen. Some of those parameters are constants so actually serve to offset the position of the paddle.

The thing which I find really interesting about this is that I have no idea what the best set of those parameters will be. In testing I’ve seen programs which try to follow my paddle precisely, which actually has put me off so much I’ve lost a match. I’ve seen paddles which wait until the game ball is almost touching then quickly moves up or down adding spin, and I’ve seen paddles which try to follow the game ball. All of these feel very different, and in some cases feels like you are playing another human.

If all goes well we will be starting a closed alpha on Monday. I’m really interested to see what happens when people start playing. We have put an initial version of the stats tracking page on-line, so you can follow along if you are interested. We are going to stay in closed alpha probably for about a month to iron out some stuff and take some feedback. The beta will be open, so follow me on twitter @DrSeanWalton if you want to know when that will be.

February 11, 2014

Second Project Announcment

Finally I’m in the position to announce the project I’ve been working on since my last Waltonia blog post. The project is actually something I’ve been working on with a friend, Bruce, for a while. It’s going to be a free release on Android, in a nut shell it’s a retro tennis game which learns to play you. It’s all based on AI and genetics algorithms and stuff, there is also a component where opponents generated on your phone also end up on other player’s phones. The game is called Ordo and you can find out more on our website.

Bruce and I met while we were studying for our PhDs and he is currently working as a research engineer at MIT. We’ve been talking about making games together for years and are going to do it under the umbrella of CrossProduct, some of you may have noticed I moved the blog to a crossproduct.co.uk domain. You can check Bruce’s blog out here and my personal blog out here.

So what does this mean for Waltonia? Nothing much, Bruce has been helping me test Waltonia behind the scenes and throwing ideas around since before I launched the game. It does mean I’m going to be working on Ordo in my spare time over the next few months while we push it to release. However, while we work on the finishing touches of Ordo we are planning the next version of Waltonia. Bruce will be a much bigger part of the Waltonia re-write, which will be a desktop native game. I’m really excited to try and put together something more ambitious with that version, and if you have suggestions on what should go in that version comment here or in the sub-reddit. I’m going to make the development process for that completely open (unless I put any secret forth wall stuff in it, which I think I will) which I think is expected from any indie game these days. As always thanks for the continued support!

February 8, 2014

Ordo’s Brain – Part 2

In this blog post I’m going to explain what happens when you play a game in Ordo and a new opponent program is requested by the game. One of three things happen, either a program you have already faced gets selected, a program downloaded from the server gets selected, or a new program is generated.

The way new programs are generated is where the magic of Ordo happens. Programs are generated using optimisation techniques. In mathematics optimisation techniques are used to maximise or minimise a function. In Ordo we are assuming that the parameters which define the programs behaviour effect how well the program performs. By changing those parameters we want to increase the performance, maximising a function.

Optimisation has been a big interest for me, in fact my PhD thesis was about applying optimisation techniques to engineering problems. In particular I am interested in a family of techniques loosely grouped together under the umbrella of evolutionary algorithms. These are algorithms that behave much like the evolution of life, different programs breed together passing on genetic information to offspring. As well as this genetic crossover random mutation occurs which helps diversify your population which means you have a better chance of finding the best set of parameters. The downside of these particular techniques is that they are random and it is really hard to tell which algorithm is better than another. To account for this in Ordo 4 optimisation techniques are used all simultaneously and distributed over all players’ devices:

One of these techniques is used each time a new program is generated. The game records which technique was used, so we can keep track of which technique produces the best programs, and so can you when we get the statistics webpages up and running.

Next time I’m going to talk about the programs themselves and the equation which makes them live. Any questions are welcome, fire away.

February 2, 2014

Ordo’s Brain – part 1

I’ve been itching to write this series of blog posts since Bruce and I started working on Ordo. The core mechanic of the game is pretty simple, a retro paddle tennis game which learns as you play it. There are lots of different ways you can go about this, we tested a number of possibilities before sticking with the system I’m going to explain in the following few blog posts.

Before I explain the details we need to get the semantics clear. Ordo is the AI in the game, but Ordo does not control the opposing paddle, Ordo writes the programs which control those paddles. Those programs have access to all the information a player would have during a game. They know how many balls are in play, where they are, what speed they are going, where the player’s paddle is etc etc. A 31 parameter non-linear equation, which I’ll talk about in a future post, takes all that information and turns it into a target position of the opponent paddle. Ordo is trying to find the best set of those 31 parameters to win games.

On each device connected to the network, remember Ordo is a single entity spread over all player’s devices, there is room for 10 programs. The first time you start the game those programs are just randomly generated so probably won’t be very good. Every time you play a game Ordo gets a request for a program. Ordo will send you a program, I’ll detail how it does that in a later blog post. At the end of the game the program is rated and sent into an ‘inbox’ on your device.

Every

so often Ordo looks in the inbox and does one of two things to a program in there, either it gets uploaded to a central server or it is compared to a program on the device. If it’s better than the program on the device that program gets deleted and is replaced by the better program. This is why the programs you face appear to get better.

Things get interesting when Ordo sends you a program, but that’s pretty involved so I’ll cover that in the next post. I hope this initial post has started to give you a feel of what this game is about, any questions fire them my way.

January 11, 2014

Reflection and visions for the future

Okay the title for this post is rather pretentious, but I could not think of anything better. A lot has happened in the last 3 months since the game launched. The site has had over six thousand unique visitors and ten thousand page views which is way more than I had anticipated. With the help from feedback of players, Waltonia has transformed from a silly science experiment to something which actually resembles a game. More recently David’s input and work has transformed the look of everything. The team working on the game will be expanding, I’m itching to talk about that some more but I’m still waiting on a few other pieces to fall into place.

For the past few weeks I’ve been trying to find the time to write down exactly where I want the game to go in the future. Rather than have this hidden in some design brief on dropbox I thought I’d write it on here. I suck at photoshop so I took some photos of some sketches I made earlier.

In my mind Waltonia is going to be a space exploration MMO of sorts. The universe will be made up of systems which contain worlds. The aim of the game will be to control as many systems as you can. To control a system the majority (say 80%) of life in that system must have been created by you. Each player will have a home system which no one else can take control of.

Each system contains a number of worlds, these worlds will orbit a star and depending on their distance from said star climates will be different on each one. The layout of the biomes of each plant will be different, as will things like viscosity and density of the oceans. In your home system you will have all the controls you currently have in the game, with the addition of gate control. The gate allows you to open a door between two worlds. When you select the gate you’ll open up the following map window…

This shows the current network of systems and how they are connected in the gate network. I’ve not decided exactly how this map will be generated, it will be procedural and have to expand as new players join. Each system shows the state of control. The yellow arrows indicate the origin of the gate, and the blue circle where the gate will send creatures.

When you select a system you then have to choose which world to gate to. Each world will have a pie chart which shows the relative number of creatures each player has living on it.

Once you open the gate you go into the world view, which is the only view currently in the game. The main difference will be a glow around creatures to show you which player they were created by. The ‘Create random xxx’ buttons will all be locked until you get a sufficient foothold on that planet. Creatures will come through the gate from your world and creatures can go the other way too, adding an element of risk….

So what do you think? Hope that all made sense, it was a bit of a brain fart but I had to get it out there. I have no idea where to start implementing all this, I’ll have to consider the pros and cons of continuing to develop in javascript vs a native application. I’m pretty excited to see where this goes, we have some good people on board with getting this (and maybe some other cool projects) going. Thanks for the continued support, leave comments here or on the subreddit. If you happened to navigate to this page before playing Waltonia, just click Play the game at the top of the page.