Shyft

Posted December 14th, 2010 in Games, Porfolio by Charles Micou

Shyft was in the works across 2010-2011, and we finally decided that we were happy enough with it to release it to the world and move on. Please do note that it is still far from a definitive ‘final release’ build, and that (while not completely plagued with glitches) it will still play up at times.

Download it here: Shyft. The map editor can be found here: http://www.mapeditor.org/

It started off as more of a technical exercise than a plan for a fully-fledged strategy game. We had a load of things floating around that we wanted to get working: LAN multiplayer, a map editor, pathfinding, music… the list goes on. For a long while we didn’t think much would come of it, but in the end we were pleasantly surprised. Shyft has turned out as a nice, clean and simple turn based strategy game with a lot of potential for casual user-end customisation, balancing and modding.

Notable Features:

  • LAN/Online Multiplayer (note: it is a direct connection, so the host will need to forward port 25565 if not playing over LAN)
  • Custom Map maker support
  • Easily editable tilesets
  • Hotseat mode for two players at one computer

We would recommend you start up a game for yourself (if you’re wondering which map, Snowy Peak is a personal favourite) and play a friend. Having them run straight into your carefully planned artillery trap is definitely one of the more satisfying moments you can experience. The game involves a lot more strategy than you’d think at a first glance, especially on a well made map, so you might want to have a go at that as well. We’d love to see any custom maps you come up with, so just drop by our forums. A quick tutorial on how to make maps can be found here.

In theory there is still a lot you could add to Shyft: A campaign mode, a custom campaign maker, single player AIs of varying difficulty, animations, more sound effects… But getting carried away with more and more features is what pushed this release so far back in the first place. Well, that and breaking hard drives, university applications, A-Levels and what have become fairly intense school lives. Please forget that we ever even mentioned an April release. We don’t plan on leaving Shyft here and moving on, there is still the truckload of tidying that comes with all the bugs you find in a beta release, as well as a few other things we have thought of but didn’t get around to implementing. That said, it’s also a great weight off our chests to finally have a fun, stable, working version. It was a lot of fun to make, and we hope you enjoy it.

Yay, screenshots!

 


Old article during development:

We will be releasing an alpha version of Shyft in the near future. When we do, you’ll be able to find it on this page.

Currently, this game is 100% multiplayer, whether over LAN or on the same computer. The aim is to direct your troops to secure a battlefield’s key locations and destroy the enemy’s forces. Players take turns moving their units and attacking, allowing each unit to move and attack once before their turn is over (or the time for their turn runs out). To win the game, players will have to use the correct units in the correct locations: securing chokes with long-ranged units like artillery, blocking the way with heavy tanks and gathering intel by scouting with air units. The landscapes are varied and have different effects: some tiles will provide you with additional cover, giving you a defense bonus when under fire, and some terrain can be harder to cross (or impossible for some units, like boats on land). The key locations are marked by large towers. Depending on the towers you control, you will get bonuses: increased damage, greater line of sight, reinforcements… Shyft has a great enough variety in its unit, building and terrain combinations to make for a game with fairly strong strategic depth.

Shyft is also very easy to customise, even if you don’t know any Java. You can make your own maps in Tiled with the game’s tile-sets. You can even make your own tile-sets, your own units, or reskin the graphics to your liking with Tiled. The interface for editing maps is very intuitive (actually quite fun, and nothing like the map editing in The Calling of the Seals, we promise). We are hoping that if Shyft becomes in any way popular, there will be a large amount of custom maps in circulation that anyone can play. And if you’re worried that you’re joining a game that you don’t have the map for, don’t worry: some genius server code takes care of that for you.

Shyft was born in the summer of 2010: after Callum had worked on the Android platform for a little while making Orb-Wars, we decided that we needed some more experience before we could produce a game that would be marketable as an app. Because it was more in the actual ‘making-of-a-game’ field we felt needed to progress more, we moved back to the standard Java platform ready to make a new game. We weren’t quite sure what type of game to make. We quite liked tile-based games and we weren’t so keen on having everything animate, so we eventually settled on an Advance Wars style tiled based strategy.

The two main things that we would be gaining from this were multiplayer support and a more efficient way to handle the production of maps. Callum single-handedly produced both a hefty chunk of server code and an attribute loader. The multiplayer works both over LAN and in hotseat form. The attribute loader reads files that can be edited entirely in Tiled, so it’s very easy for pretty much anyone to make a map for the game (provided they set up Tiled in a specific way, which has caused us a few troubles in the past).

The graphics of Shyft have changed significantly throughout the course of its development. Charlie originally made all of the graphics himself, but we soon decided that if we wanted to make this game a solid long-term project, they needed to be of a higher standard and there needed to be much more of them. Luckily, we stumbled upon an abandoned gaming relic from 1992: Hard Vacuum. This was a real time strategy game that was never released, and so the team artist (Daniel Cook) decided to release the graphics royalty free so that they wouldn’t go to waste. The tile-set linked on the site was incomplete in many places, with transition tiles missing and only half the units and buildings shadowed, but the artwork was perfect. The style was exactly what we had been hoping for. Everything wasn’t formatted just right, and it all needed putting into a tileset, but that was taken care of easily enough. We went from 41 tiles to over 700 and from 7 units to 12. Charlie also tore apart the GUI, originally made for tiny 420*300 px screens, and used it as a template for the final interface. Shyft is by far the prettiest game we’ve ever produced.

The funny thing about Shyft is that we could, given infinite time and patience, just keep adding to it. It’s already pretty much playable, but there is so much more that could be done. We could add AI, smooth motions, a campaign mode, team games, alternate game-modes, more units, maps that went around in circles, special abilities… This project is only really going to end when we say ‘Stop. It’s time for something new.’

Memory Checker

Posted December 13th, 2010 in Other Software, Porfolio by Callum Lawson

Memory checker is an android app that tests the handset’s RAM and SD card.

If you are interested in games, look away now! Technical details follow.

The memory checker application seeks to detect memory corruptions caused by memory errors or single event upsets. To this end, it writes and reads data from the phone while checking for errors and recording them to a log file. The application is configurable on the phone and seeks to produce data that is easy to graph and interpret.

You can configure the test using the following variables:

Number of cycles:
This is the number of write/read cycles that are carried out in the test. Each cycle, the amount of data set in the data size box is checked, written and read.

Number of checks:
This is the number of times the saved data is read and checked by the program. A higher number of checks will increase the chance of detecting a read error and reduce the chance of recording a false write error. Using a large number of checks may slow the test down marginally.

Check Delay (ms):
The check delay is the time the program waits after writing and before reading. Changing this value will allow the user to test how the amount of time and the amount of the data left on the disk affect the number of errors produced. This value has an effect on the length of the test but it is small in comparison to the size of the data saved.

Data Size (mb):
This is the size of the data array saved to the phone’s memory each cycle. Setting this to a high value will dramatically increase the duration of the test. Without “rooting” the phone and increasing the maximum heap size this value cannot be set to a value higher than 20mb. 18mb is the highest amount recommended for reliable use.

Print Rate (s):
This is the time between result outputs. For example, if this is set to 5 then the number of memory/write errors and read errors will be printed every 5 seconds. It is highly recommended that the time between prints is set to a value higher than the time it takes to complete a cycle as this will make the results easier to interpret.

We have not yet released Memory checker as it requires further testing before being made available. However if its just what you’re looking for make a post in the forums and we can e-mail you the .apk

The Calling of the Seals

Posted December 13th, 2010 in Games, Porfolio by Charles Micou

DISCLAIMER
The Calling of the Seals really was our first attempt at making any game, ever. It’s several years old right now, and while it was a cute initial project, we have half a mind to disown it as something we never produced. Scroll down at your own peril, and watch out for Turtlebears.


The Calling of the Seals was our first project, an RPG in the style of early tile based console games. If you want to play it, you can download it right here: The Calling of the Seals.

The game follows the standard RPG plot: evil forces are threatening the fictional land we didn’t name, so to save the day hero must break ancient seals in temples. A play-through of the game takes about forty minutes for me, so when you’re figuring out puzzles and the like it will probably take a little longer. A lot of the time is taken up by having to go heal yourself, this was a little oversight in game design. The environments are varied, as are the enemies, and you can upgrade and swap weapons, as well as buy healing bandages (spoiler: which are an absolute must for one of the bosses). Each temple has its own puzzle: teleporter mazes, light-switch puzzles (one of the few things I’ve coded that was ever used!), falling through pits to avoid ghosts and pushing blocks on to pressure pads.

The battles follow a style similar to the Gameboy Pokémon games: you walk across an enemy’s field of vision and this initiates a turn by turn fight until one of you is dead. The bosses in the game do not have special moves, but the final boss (which is lacking a graphic and an actual place in the game) has a few lines dedicated to healing himself. There aren’t really any secrets in the game, only a few easter-eggish NPCs on the eastern side of the main city. If you’re at a loose end and want to play a slightly buggy, partially unfinished RPG then feel free to download the game here. Oh, and if it’s too boring to finish in one go: it has saving.


TCotS was where both of our programming and game designing careers started off. The code was pieced together and guessed at, disregarding dozens of conventions and making a bit of a mess in a few places. All the graphics were hand-pixeled and each map carefully sketched out on paper before feeding it through the incredibly tedious procedures we had got ourselves tangled up in with newbie-code.

This is a little harsh on TCotS: we really enjoyed making the game, and learned a lot about what not to do. The game is definitely not an all time classic, but it has its fun moments and has its charm. As Callum put it when we were deciding what made us actually like the game: “It has soul.”

Orb-Wars

Posted December 13th, 2010 in Games, Porfolio by Charles Micou

Orb-Wars is an arcade game for Android phones.

The objective of Orb-Wars is to fly your spaceship between black holes and around obstacles to safety. It plays a lot like a mini-golf game: each level has its own optimal solution, and you aim to complete the level in as few ‘shots’ as possible. You control the ship by rotating it and then giving it a burst of power.
There are a few differences, the main one being that it is all done in real time. Unlike a golf game, you can fire again midway through a shot. After all, this being set in outer space, you never actually stop. As you bounce off walls, your ship’s shields gradually weaken and will eventually fade away. If you hit anything after this, you lose a life. The black holes provide an interesting mechanic: with a little practice, you can fling yourself around corners without hitting walls; but get it wrong and you spiral to your death.

The game is very, very unfinished, and has been gathering dust for quite some time, but if you have an Android phone and you want to play through the first 3 levels, you can download the game here: Orb-Wars.

Intersection

Posted December 13th, 2010 in Uncategorized by Callum Lawson

Intersection was a game Callum wrote for a school competition a year ago.

You play against a friend or the computer and take turns to place counters. The aim is the find the intersection between you column (which you know) and their row (which you don’t know).

The game will be uploaded shortly.

jMonkeyEngine

Posted October 5th, 2010 in Game Design by Charles Micou
Although we are currently limited to 2D in a big way, and our projects for a while yet will still probably be top down (perhaps iso with overlapping to mimic 3D if I somehow develop artistic ability overnight), I cannot stop drooling over this: http://www.jmonkeyengine.com/
The running at over 1000 fps at times might be a little excessive, but I doubt a cap would be to hard. This opensource Java engine is still an alpha after all, and it looks like it has a whole lot of potential.
Callum and I would need to switch from using Eclipse to netBeans, but it’s far from the end of the world, and well worth it by the looks of things. 3D is just one of those things that makes everything better.
I should probably stop daydreaming and get back to doing some work since this is such a long way off, but maybe in a year’s time we’ll have some 3D up and running.

Thoughts on Maps for Shyft

Posted October 1st, 2010 in Game Design by Charles Micou
As Callum pointed out earlier, the map we’re working with for testing is not one you’d want to use when actually playing a game. First of all, it needs to be fair. This usually implies symmetry or randomness (which I will get on to further down), or both. More importantly, however, a good map needs to be interesting.
Consider the map below:
This map looks quite nice: the trees are by the water and the mountain, and everything is spread out in an even way. What really matters about this map, though, is that there are multiple strategies a player is likely to consider:
So, we have Player 1 starting in the bottom left, and Player 2 starting in the top right. Because roads provide such a large bonus to movement, mobilising troops towards the centre of the map (A) is very easy and the fastest path to the enemy. However, the choke points caused by the bridges (B) mean that you can hold off your opponent. The alternative is to go round the sides, passing through (C). Note that because of the very defensive terrain near (D), it would be wiser for Player 1 to attack along the bottom of the map whereas Player 2 would be better off going along the top. This slight imbalance means that you either have to scout or preempt your opponent.
This constitutes what I would call a fairly good map. If you had the added complexity of resources (which we might get around to adding at some point) and construction of units, many resources placed in the centre and perhaps a few along the flanks would make this map more fun.
Our criteria for maps, such that they could be generated via some seed numbers (and perhaps a selection of other factors) would have to be as follows:
-The two teams can reach each other

-Tiles are assembled correctly (i.e. rivers the right way around)
-The map is symmetrical (simply because this makes balancing so much easier)
But what about if we want good maps:
-There is more than one route to the enemy
-There is imbalance in these routes, such that decisions have to be made by each player as to which route to take
-Aesthetic appeal and ‘common sense’ in placement of tiles (this is a hard, yet interesting bit)
-There is ample space to manoeuvre troops, but also choke points
I am all for a random map generation option: it gives the game a longer lifespan, can be more fun under certain circumstances and provides variety. However, if 10 or 20 maps similar to the above (which was not by any means a challenge to make) could be played to provide this variety, the quality of the random maps would need to be quite good to compete. It looks like if we want to give the game more longevity via maps, letting the user use Tiled to make their own is the best option at this point.

What is an algorithm?

Posted October 1st, 2010 in Game Design by Callum Lawson

A algorithm is defined by both the algorithmic problem and its solution. An algorithmic problem is the characterisation of all the legal inputs for the algorithm and the desired outputs for those inputs. This is a rather trivial example of an algorithmic problem:

  • Given a set of numbers (i.e 5,9,7,2,1,5) return how many numbers are divisible by 3.
For the above set of numbers the answer is 1. One could easily write a function that would give this output:

for input(a,b,c,d….) output(1) 


This would provide the correct output for the example set of data but not all possible sets of data – it is not an algorithmic solution. An algorithmic solution is one which will provide the correct output for any legal input. The pseudo-code below would be an example of an algorithmic solution for this problem.

(1) create variable a
(2) for – number of numbers in the set
           if – current number is divisible by 3
           add one to variable a
(3) return a


This code would produce the correct output for this algorithmic problem regardless of what the input is as long as it is a legal input (a set of numbers). It does not matter if the set is 5 numbers or a million – the correct result will be returned.

After claiming that my line of sight code in the previous post was an algorithm I realised that I do not know the definition of one. So I did some research and wrote the above. In hindsight I think I was correct in calling my code an algorithm.

Shyft GUI

Posted October 1st, 2010 in Game Design by Charles Micou
I’m Charlie, and since Callum’s ability with programming far surpasses my own, I have stayed pretty much completely out of the code so far. However, as the slightly less graphically challenged member of the pair of us, I have so far done most of my work on potential content, graphics, GUIs and gameplay mechanics.
The way the GUI has come along so far is very interesting, as it has sort of evolved with the way the game is going so as to keep the code simplistic while making the GUI as intuitive and easy to use as possible.

The earliest GUI design was simply a way of displaying the information that we knew we’d need:

This was then refined to a slightly less conventional layout, with commands for units on the sides (map background image was taken from Advanced Wars as a placeholder):
Comfortable with the shape of something similar to the above, we expanded it to accommodate some of the features we decided to add:
After some refining of the above, we have finally settled on the bar you see on the right dynamically adapting to which tile the user’s cursor is over, or which tile has been selected. This will mean that we can display more things in more space as and when they are needed.

Map Randomisation

Posted September 30th, 2010 in Game Design by Callum Lawson
I was recently thinking about how I could generate a playable random map for my tile based strategy game. I can foresee many difficulties with this. Below is a sample map created in the map editor:
This map although not very well balanced looks sensible. The roads are connected and features such as trees and mountains are grouped in semi-realistic clumps. The river is also continuous and flows from one side of the map to another. If this sort of result is to be achieved my a random map generator it will need to follow these rules:
  • If the tile is blank there must be a chance that a feature is placed on it. This should be larger if adjacent tiles contain this feature.
  • Roads and rivers must form a closed loop. (counting the map edge as closed).
  • If there is a road or river section in an adjacent tile and it is “facing” into the tile it must be continued.

  • (Optional) The map be balanced in terms of resource and position or be symmetrical.

Ideally the chance of each feature (i.e. hills,woods,mountains) being placed in tile should be determined by an initial value and the tiles surrounding it. If this was a case the user could define the initial chances by selecting an option such as hilly or woodland before generating the map while the affect of nearby tiles could help produce the desired “clumping” of features.

I intend to try and write some pseudocode which achieves these effects soon.