Project 131: Artillery! Turrets Concept Test

 This is a proof of concept of the turret system for the game "Artillery!" which I am working on. This is based on the TurretShape code already present in T3D, however my implementation has to ability to accept rotation and elevation commands from script, and smoothly interpolate the current turret position to the new position with no jitter or sudden movements.

Turrets are also made in a single file. The turret feature in T3D has a turret body, which is then mounted with a separate "head" object. This head object is defined as a weapon, (A ShapeImage) and can feature and advanced state machine to drive animations. My game didn't need that feature, since the firing calculations will be handled from separate functions (to better simulate different types of physical effects and types of shot) and so I modified the code to allow the turret to be modelled as a single shapefile.

Constructing a turret is relatively simple. Two nodes are required, a "heading" node to control rotation, and a "pitch" node to control elevation, as well as a "Muzzlepoint" to determine the position that the projectile leaves the gun. Any object linked to the heading node is rotated, and any object linked to the pitch node is elevated, so, a simple turret might have a base, which is unlinked so that it doesn't move, and then a mount which is linked to the heading node only, and a gun barrell which is linked to the heading and pitch nodes.

Modelling and animating should be simpler in a single shape file, and I won't have to worry about getting mount points to line up exactly, or have to work with offsets.

This solution works over the network, although not properly. I had to add some script commands to ensure proper animations, and this should not have been neccessary, I intend to properly debug and fix this at a later stage.


You must be a member of this blog to see the comments. Log in now!

Project 131: Artillery! Game Concept




“Artillery” is an addictive, turn-based game from Phoenix Game Development.  Players choose from a selection of tanks and other armoured vehicles, and must square off in an arena with up to 8 other human or AI controlled enemies. Realistic ballistic physics and random level generation make it easy to learn, but difficult to master.


  • Artillery boasts over 20 unique weapons, from conventional High Explosive Shells to Homing Missiles, Cluster Bombs and even the bizarre tunnelling self-propelled mine!


  • The game supports both multiplayer and single player modes. Players may form teams, or mix human or AI controlled opponents. Artillery supports both LAN and online play,  and features a leaderboard to keep track of players scores.


  • Since game maps are randomly generated, no two levels are the same, providing unparalleled replayability. The level generator is sophisticated enough to spawn players in intelligent locations, keeping the game balanced and fair, and preventing players from spawning in frustrating “impossible” locations.


  • Turns have a time limit, forcing the player to think on their feet and make quick decisions, poviding for a fun and faced paced game experience.

  • The wind effects can be turned off, for an easier challenge, or set to constant speed, or random, increasing the challenge.

  • Artillery features a wide variety of level types, from arctic tundra, to grassy plains, to cities and even an asteroid! Each level type has unique properties which affect gameplay, for example the arctic tundra features random blizzards which reduce visibility, the cities have buildings which get in the way of shots, and the asteroid has very low gravity which affects the way a shot flies.




The objective of Artillery is simple: to be the last player (or team) standing! The start location is randomly chosen, and the player may not move during the game. Each player first chooses from a selection of over 20 weapons, and then precisely aims their cannon by rotating and elevating the turrent, and adjusting the power of the shot. Artillery uses realistic ballistic physics, players must take into account the rotation, elevation, and power of the shot, as well as wind speed and direction, and the distance to the target. This makes for a fun, challenging experience.


Target Audience

Artillery is suitable for all ages, with its simple game rules and fun atmosphere. Users will need an internet connection for online play, but LAN and solo play will work without it.



Artillery is built using the Torque3D game engine, and is available on PC only.


© Phoenix Game Development, 2013


You must be a member of this blog to see the comments. Log in now!

Update: October 2013 Fluid Dynamics, Artillery! and Sleep Learning Concept App


This is just a quick update on a few of my projects that will be finishing soon, as well as another one that I have just started.

My fluid dynamics Project is "functionally complete" at the moment. It is a realistic fluid simulation which comes with four material types: Water, Lava, Tar, and Mud, although Water is the one I spent most of my time on. The only problem with the fluid system is that it is quite slow. With any more than one fluid system on screen, the framerate drops dramatically. Before I can release it, I have to find a way to optimise it. I am considering multithreading, as well as a few other improvements. I am hoping to get this done next week.

I have also yet to finish debugging my sleep learning app. This is also feature complete, and should be uploaded to the play store next week.

My latest project is a very simple game called Artillery!. This is not a new game concept, it has existed in various incarnations for several years, but it is a good way for me to improve my knowledge of vector mathematics (simulating wind, different types of projectiles, etc) and it should be a short project (maybe a month or so). I have ideas for a major game project which I am excited about starting, but it will take a long time, so I wanted to make a few short games first before starting on my next long project.

I will post the Game Concept for Artillery! in another post.

You must be a member of this blog to see the comments. Log in now!

Getting Started in Game Development

In this article I intend to try to answer some common questions prospective game developers may have about getting started in the industry. Questions like: What skills are required, what kind of resources and software tools do you need? How much does it cost? Do you need a team?

The gaming industry is huge and includes a wide range of devices from consoles such as the Playstation, Xbox, and Wii, to PC's, browser based games, mobile games for Android and iPhone, and even handheld consoles such as the Playstation Vita. Languages such as Java, C++, JavaScript and ActionScript (flash) can be used. There are a multitude of books, websites, and forums available on each of these. Delving into this world can be a daunting prospect!

Everyone has their own goals and interests when starting out on any new venture, but there are some general tips and advice that I would give to budding game developers. The first thing that I feel is important is discuss is the subject of games engines. A game engine is essentially a software library that can be used to build a game. It has built in rendering, physics and network support. Many people create a game completely from scratch, writing the rendering engine, the physics engine, etc all themselves. This is an excellent way to learn about how a game engine is made, as well as learn about libraries like OpenGL and DirectX, but it is a long, difficult, and time consuming process.

Furthermore, writing your own engine will not necessarily teach you a lot about how to create a game, in the same way that building a car doesn't necessarily make you a good driver. Another approach is to use either a commercial or a free games engine to build your game. These engines can be difficult to learn, but they allow you to focus on building a game, instead of writing an engine. If your objective is to be a game developer, as opposed to a game engine programmer, I feel this is probably the best option.

Choosing an engine which provides access to the source code will also give you the ability to delve deep into the guts of the engine and modify or add features, as you grow more confident. To create a fully-fledged game by yourself, as a novice programmer, is a mammoth task that may leave many feeling frustrated. Even for a seasoned programmer, writing a games engine is a difficult undertaking.

Games engines range in price from completely free, to many thousands of Euros. For this discussion, I am limiting myself to discussing free or sub €100 engines. A point to note here, is that I am not considering an "engine" to be equivalent to one of the many "game maker" type programs out there. An engine is simply a library, in essence, containing a foundation upon which to build your own game. A gamemaker is basically a GUI that provides you with a series of customisation options which are interpreted by the program and used to produce a game. They are very simple to use, but do little to teach real game development skills.

But which is the best games engine? What is the best platform to get started on? PC? Mobile? Console? There are hundreds of engines and software libraries out there, which do you choose? Personal preference matters a lot here, but I will provide some recommendations and pricing information. Many engines are also cross-platform, allowing you to port a game to several devices or systems.

Console development is, for the most part, not an option for the novice developer, especially if you intend to sell your game. Console manufacturers have strict rules on who can develop on their consoles, and the dev kits (basically, a software package to allow a developer to write code for a console) cost into the tens of thousands of dollars. This leaves either mobile game development, or PC game development. Fortunately, both of these are quite accessible and quite lucrative for the amateur game developer.

For the PC, I have mentioned Torque 3D by GarageGames ( many times on my site. I first used the "Torque Game Engine" several years ago after picking up a book on game development ("3D Game Programming  All in One" by Kenneth C.  Finney) which included a version of the TGE with the book. I was immediately hooked, and, in fact, after getting halfway through the book, I was so excited to try out my own ideas that I still, to this day, haven't finished it!

Torque 3D has now gone open source under the MIT license, which makes it free for commercial and non-commercial use. Torque has quite a steep learning curve however, and is possibly not the best choice for someone wanting to get into games development quickly. You can bet on spending at least a few months just learning the ropes, if you are a complete novice. There is also a 2D engine available from GarageGames, Torque2D, which supports Windows, Mac OS X, and iOS mobile development (with Android support in the works).

Unity 3D by Unity Technologies ( is another powerful engine aimed at the indie and hobbyist market. There is a free version available, with some restrictions, and the full version costs $1500. This is steep for someone just getting started, but the free version alone provides ample scope for learning the ropes. Unity 3D supports ioS, Android, Windows phone, and a host of other platforms.

Blitz 3D ( starts at $59 (€43). This is probably one of the simplest and easiest to learn engines out there, as well as being one of the least expensive. It does lack a lot of the power that some of the other engines have, and it mostly used for more casual games. It also only supports windows. However, as a tool to learn programming and game development, it is tough to beat. Blitz3D is built using basic, which is not a common language for game programming, and this may be considered a disadvantage. Blitz Research also offer other engines offering additional features, including support for Linux and Mac OS X, at slightly higher price point.

Mobile games are a massive new market, and their popularity continues to rise. Mobile games are almost always built with Java, and are often, but not necessarily, 2D. Mobile game development can be difficult, since dealing with the limitations of the hardware requires skill and good code optimisation. For Android development, the developer must support a wide range of devices with different screen sizes, processors, and capabilities, while maintaining the same play experience across all devices. This, again, is not always easy. Both Torque 2D and Unity can be used to develop mobile games.

An excellent resource for Java game programing is "Developing Games in Java" by David Brackeen. This is the textbook I used when I was studying game development in college, and it contains a lot of information and code samples to use to build simple games. Topics covered include 2D and 3D games, Artificial Intelligence, Sound and Multiplayer Gaming.

A powerful game engine, however, does not mean that a low-level knowledge of software development is not required. Game programming is a complex and diverse field, which combines software engineering, physics and mathematics in a way that few disciplines do. You can avoid a lot of the maths and physics if you like, but it will limit what kinds of games you can make. Unlike traditional software engineering, where reuse of code is common and encouraged, in game development, every game has to be unique and fresh. Copying code and features from an accounts package to a word processor application is not going to hurt your sales, but making a game that's a clone of something that already out there certainly will.

I would recommend Java as the best all-round language to learn programming. It is a nice language, quite easy to learn, very popular (and becoming more so) and Java programmers are in high demand in game development and software engineering. Java is used for websites, mobile games, apps, and can be used for desktop games as well. It's not as powerful as, say, C++, and not as easy to use as a scripting language like ActionScript, but it has an excellent mix of power and ease of use. For a developer hoping to go into mobile gaming or app development, Java knowledge is a must!

Whether you are working on 3D or 2D games, some graphic design skills will be necessary. There are free programs out there, such as the GIMP ( and Inkscape (, it is not necessary to buy an expensive tool like Photoshop. GIMP (GNU image manipulation program)  is primarily a bitmap graphics package with an excellent feature set. Inkscape is a vector graphics package, and is also impressive and completely free.

In order to create art for a 3D game, a modeling tool will be required. Again, you can pay thousands for a commercial tool such as 3DS Max or Maya, but there are also free alternative available, in the form of Blender ( This is an excellent, feature packed and completely free tool used by commercial and novice game developers and artists alike.

Creating textures for models or objects in the environment often requires the use of a texture library. In most cases it is not practical to create all source images yourself, and simply stealing them off of the internet is not an option! Luckily, for both 2D graphics and sound, there are several online royalty free texture and audio libraries available, both for free and commercial games. Imageafter ( is an excellent source for free textures, and Freesound ( offers many royalty free audio clips and sound effects. Free programs such as Audacity ( can be used to edit and process sound effects before using them. It is also possible to download or purchase 3D art assets from websites such as TurboSquid ( which can reduce the art burden considerably. Some game engine manufactures also have a store where you may purchase art assets.

One final topic of discussion is on the subject of teams. The vast majority of games made are made by groups of people, often quite large groups, however care must be taken when joining or creating a team as a novice developer. I mentioned in a previous post (Here) that forming a team too early can lead to a lack of direction and the eventual failure of the project. This is true even for professionals, but for a novice attempting to create a game with other novices, this is particularly true. With teams of amateurs, it is very common to see people dropping out of the team, producing poor quality work, or no work at all, or creating an atmosphere of discord which can hurt productivity and doom a project.

I personally think, that at least in the beginning, a prospective developer should work alone, on small projects which should not take more than about six months to complete. Working with team members adds additional uncertainty and difficulty, and if a project goes on longer than six months or so it is possible that the developer will lose focus and the project will not be finished, the fate of many great, promising games. If a team is formed, it should be kept small, no more than 4 or 5 people, and they should ideally know each other, or live close to each other. It is common for developers to meet people on forums, and form a virtual team, and this can work well, but these circumstances clearly strain the team dynamic. I once knew someone recruited a team member to work on his project, and they agreed that part of the new recruits payment would be in the form of a licence to the games engine that the developer was using, which the new member would then be free to use for his own projects afterwards. The developer paid for the licence, and then never heard from the other team member again, that was an expensive lesson!

In summary, a prospective game developer must harness a variety of skills, even if they eventually intend to specialise in one area. Luckily, the software tools and resources necessary to develop and hone these skills are either freely available or inexpensive. An excellent general resource for all things game-related in Ireland is ( This is a popular site packed with information, links, and forums for both novices and professionals alike. For programming support, I recommend StackOverflow ( This site has sub forums for many different languages, and has a high response rate. In addition to this, all of the games engines I have mentioned have their own support forums, specific to their engines.

Game Development is a fascinating, rewarding, and diverse field, but it does take time and effort to build up any degree of skill or ability. A games engine, compiler, editor, or modeling package is just a software tool, ultimately the only thing that can make a great game is you!


You must be a member of this blog to see the comments. Log in now!

Project 130: Computational Fluid Dynamics: Instancing, Spherical Mapping, and Real Time Updating

I have made significant progress on the Fluid Dynamics simulation, and I feel that I am coming close to a point where I can release the software. I haven't decided whether to charge for it or release it for free yet, or even where I will release it, but I still have quite a bit of debugging and optimisation to do.

The first update to the software is Real Time updating. Before, all of the variables controlling the simulation were in code, requiring a rebuild of the engine to alter anything. Now, they can be changed from the level editor in real time. This is clearly a vital feature, and one that I had intended to include from the start.

The second update is that I made some changes to the texture coordinate code. I was using a very simplistic approach, which was causing noticeable stretching of the texture on the metablobs. I have since added support for spherical texture mapping. The texture coordinates now take the form: (Obtained from here)


u = aSin(x)/PI+0.5

v = aSin(y)/PI+0.5


This is still much simpler than Triplaner texturing, but I feel that the results with the water shader are much better, with much less stretching. It does not seem to work with the other materials I have created, however. I have made a Lava, Tar, and Mud material using T3D's built in material editor and some custom textures, and the textures do not seem to show up at all with the spherical mapped coordinates. I will probably have to use both systems, and swap between the two depending on which material the user has chosen.

Finally, I have made the simulation completely object-oriented. It was running using global variables, which made testing and debugging easier, but it is now all class and object based, which means I can have as many instances of the fluid simulation running as I want simply by adding another Fluid Simulation object to the world usign the level editor, and each object can have completely different properties, materials, etc.

This has led me to what I feel is the final problem in the project, which is that of optimisation. Even with just two fluid systems in the scene, the framerate is very low. Granted, this was using a debug build, which is noticeable slower than the release build, but I will still need to spend some time researching optimisation techniques for the underlying marching cubes algorithm that powers the metablobs. I have considered multithreading the simulation, and have researched this possibility. I will probably try it, and see if there is much of an improvement in framerate.

You must be a member of this blog to see the comments. Log in now!

<< Previous :: Next >>