My collegue and I joined for a game programming course that was organized by the Tampere University of Technology. One (and the most important) task was to implement a working game as a project group. There was no limits about the genre and the tools could be chosen quite freely. We chose Unity 3D and Android as the target platform. For the genre we chose Marble madness styled ball controlling and puzzle resolving game.
Schedule for the game design and implementation was pretty tight, so we decided to stick with the basics and get the building blocks done. We managed to implement six different levels, with three difficulty levels each. The levels are implemented for demonstrating the building blocks we implemented and the actual game is not that finished. E.g. we do have collectable coins, but those cannot be used for anything, also there is no limit how many times player may die.
Anyways, the basic building blocks are there and they could be used for creating a real game 🙂
I attached some screen captures of the game on Mac OSX and there is a link below if you want to try out the game in your browser using Unity web plugin.
I was trying out some HTML5 when I stumbled into this site. I am still a bit unsure about HTML5, but it has its potential. If I manage to finish my tiny project I will show the results on this blog.
In my search for a solution to make my graphics scalable I heard a rumor about Nintendo having released their pixels-to-vector algorithm as open source! Could this be true? I haven’t found any reliable information of this yet.
What I am talking about is something like Johannes Kopf and Dani Lischinski had developed and described in their paper Depixelizing Pixel Art. Sadly, their solution is not available for public and it seems that I end up looking this paper after every search attempt… There is something going on at the SNES scene, for example xBr 2.2, but real time shaders aren’t exactly what am looking for.
This is a bit old stuff, but I wanted to share it with you. Inaria is a very simple role playing game that was originally created by Anthony Salter as a result of 40-hours game project. When Anthony released source code for Inaria, someone took initiative and ported it to C#. After trying out C# version I began my own Java port of Inaria and here are the results.
The basic game play should be equal to Anthony’s version. I also added some eye candy and improvements to the user interface. E.g. actions have shortcut keys, buttons are animated when pressed and there are some fading effects and animations added.
Hexagon has appealing characteristics for a map tile. It has six neighbours and the distance from any hexagon to its neighbour is exactly same. More traditional square based map tile has eight neighbours and distance varies from 1 to 1.414.., depending on in which direction particular neighbour is located at. However, they both have one characteristic in common, they look dull.
If you take a closer look at Small World map you will see that map tiles have hexagonal aspect and they do not look dull. Tiles have pretty strong border in high contrast which separates tiles from each other. Hexagon segments have been deformed and the tiles are textured using hand drawn textures with some extra details on top of them. These little finishing touches make them look great and pretty hard to spot hexagon aspect when you look at the map.
As a part of Farout project I have been playing around with Dehexifying algorithm to make hexagon map looks something like Small World map in the image above. Algorithm is simple, yet the results are quite stunning. Algorithm can be divided into following steps:
Create vertices for hexagon map (in my implementation caller gives number of hexagons in horizontal and vertical direction, and width of one hexagon as parameters)
Connect vertices into segments, every segment contains exactly two vertices at this point (segments reference to vertices, therefore altering one vertex affects every other segment using same vertex)
Create hexagons from segments (hexagons reference segments, therefore modifying one segment alters other hexagons using same segment)
Deform the vertices (this could be done before step 3 it just happens to be 4th step in my implementation)
Split segments into several vertices. Number of vertices created for segment depends on the segment’s length after step 4. The longer the segment is the more vertices will be created.
Deform newly created vertices to make segments non planar.
Dehexifying algorithm steps
After these six steps hexagon map looks surprisingly lot like a Small World map, depending on how well your deforming algorithms work. One has to remember that this is just a model for the dehexified map – what it really looks like depends on rendering algorithm, which I will talk more about in my next post.
Here is an example image of how difficult it is to make use of old 8-bit graphics in a modern game development. The first image on the left was drawn way back in the late 80’s. It was the first attempt to create a heavy infantry icon to our game, then called Warmaster for Amiga OS. The second to the right is just a doubled image of a later SVGA-version for Windows. Third image is a experiment with HQ2X – an attempt to speed up the graphic design process. It’s better than the plain nearest neighbour scaling but we have to admit it lacks the detail and refinement of a hand crafted icon. Although pixel editing is slow and considered a skill from the past, we’ll have to stick to it unless there soon pops out a powerful pixel-to-vector-converter somewhere.
Long time ago we had a small game project called DragonWars. It was a strategy game using hexagon maps and hand drawn graphics. Unit graphics are nice but the problem with them is the size. Units are 16px * 16px which is way too small for today’s modern games. Therefore Juha has been playing around with different scaling algorithms to see how we could use those old graphics without the need to fully redraw them. The most promising algorithms have been Hq4x and Microsoft research center’s Depixeling the Pixel art -project (DPA from now on).
Hq4x is widely available while the DPA has no reference implementation available. What makes DPA more appealing in our eyes is the fact that DPA generates vector graphics from the raster graphics while hq4x just scales the raster graphics into new fixed size raster graphics. For our longer plans vector graphics would be ideal but for now we will have to stick with raster graphics and hq4x.
If Juha gives me his permission I will later post some example icons to this blog.
It’s been a while.. Me and my friend Juha have been brainstroming ideas for a new multiplayer strategy game. We are both fans of Small World, really great board game from Days of Wonder. It is the game we play during our biannual meetings (warning: Finnish pages) and we even have a competition based on this game.
Therefore it is no surprise we have taken some ideas from the game that we are so fond of. Some of the rules are from a game concept we designed like almost ten years ago, but then forgotten because of other interests in life. We both felt that now is a perfect time to start a new project called Farout.
Farout is a game of conquer, diplomacy and economics. Who earns the most victory points wins. There are several different ways to earn victory points and most of them require use of army. Rules are still work in progress and the development will not start until we are both content with the rules.
All kind of information about Games and Game programming
