Aadvek.co.uk

Just a small update here. After blowing the dust off my old CodeBlocks project and getting it to build again, I’ve been doing bits and pieces of work refactoring and tidying up Battle for Polaris.

I’ve been starting to use Git for source control. It’s horrifying how I never used any version control systems for my own personal and university projects – they are not just for team projects. I remember with NeTron I got myself into a bit of a quagmire with threading bugs, when my older code worked fine, and had to spend hours tidying it up due to lack of any kind of ability to look at history or revert. Once I’m not too ashamed of my code I might even start hosting some of my things on a site like github

One thing I’ve noticed, coming back to code I wrote when I was less experienced, is that my code is actually pretty tidy. This could be due to the fact that I’m now used to having to deal with other people’s code, and everything is nice and consistent for mine.

The real problem is a bit of a lack of reusability – that is, vast swathes of my code is “game-specific” where a lot of the functionality could be moved into common code. What I have been doing is separating the code into projects “BfPGame” for game-specific code and “BfPEngine” for code that can be generalised – not that what I have so far could really be considered an “Engine” in any real sense.

I now have something resembling a physics engine, creatively dubbed “JFPhysics”, that should be reusable for another game. I also have some generic game state code, some of which the physics engine relies upon, and most of the OGRE framework code. There’s also utility code, such as code for calculating aim and turn vectors, vector randomisation, intersection code, and so on.

There are still some things I could do on this front, particularly in separation of control and state code. But for now I’m going to move onto some more interesting things:

• Linux. I’ve looked through the code, and there’s nothing obviously platform specific in it, thanks to my use of OGRE and other such libraries. The main problem is that I’ve only got my project to build with a fairly old version of OGRE/CEGUI so far, not to mention the fact that my old install of Gentoo is a bit “borked” right now, but with those issues solved the Linux version should be a breeze.
• Sound. Currently the game has no sound, though admittedly this makes it rather realistic for a space game. Some music and basic beep-boops and engine rumbles would probably add quite a bit to the atmosphere of the game.
• AI and gameplay improvements. I want to make it more challenging, particularly in how AI ships manouevre; currently they can’t even strafe. I’m going to look into adding some little bits of features towards my desired end of making the game more sandbox-y, such as station docking and AI traffic. First step is drawing out detailed plans for these.

I guess this is mostly for my benefit, but I will be updating as I step up the progress in BfP. Nothing has come of the Roguelike thing yet, but hopefully there’ll be progress updates for that too, once I’ve gotten over the initial barrier of getting the damn thing working.

I haven’t updated the site in quite a while, I know. between work, family, Dragon Age and other distractions, I’ve somewhat neglected this blog and site, and I felt pretty bad about it, so I thought I’d check in.

I have been investigating a few things with Battle for Polaris that has caused a bit of a roadblock; partly on what design direction it should take, and to extent what involvement OGRE should have in its future development. I’m playing around with some additions that would move it in more of a sandbox adventure (think Elite and its offshoots) kind of direction.

There is also a new project in the pipeline, currently also in the planning / messing around stages. Years ago I wrote a little rogue-like game as part of a university project in Java, and although the original code is a hideous spaghettified mess, I’ve always wanted to make an attempt at my take on the genre. In my professional life I’ve taken a liking to Python - not just in a Stockholm syndrome way, either – and, paired with libtcod, it looks like the way to go.

I’ll hopefully be updating more often from this point, on my progress in these projects as well as possibly some inane personal stuff.

After many setbacks and a stomach virus, the new version is done. I had planned to release 0.2a a week ago, but discovered some nasty crash bugs and AI issues that I wanted to fix before making a proper release. There have been many other updates and feature additions; see the “Battle for Polaris Roadmap” post for details.

Battle for Polaris is my biggest C++ project. It is a hybrid of the 3D space combat and real-time strategy genres, with all the code, including AI, Physics, Gameplay and GUI layouts, designed and written by myself. For 3D graphics OGRE was used, and for the interface CEGUI was used. Models are mostly freely-available stuff adapted and some modified for use with OGRE in Blender. Although it formed the basis for my MSc dissertation, work on it is ongoing.

Currently the game has been written and set-up to run with DirectX 9 in Windows. A working OpenGL (and following, the Linux version) will be forthcoming.

This version is 0.21 Beta, as I’m only mostly sure I’ve ironed out all of the major crash bugs and other issues.

Screenshots

Click for full-sized versions.

Videos

Battle for Polaris 0.21b Demo Gameplay Video (2:27, 640×480 WMV, 34.2 Megabytes)

Battle for Polaris 0.21b Demo Gameplay Video (lowres) (2:27, 320×240 WMV, 19.4 Megabytes)

Music is “ROT13 (SHA2 Remix)” by Partition 36, available here under a Creative Commons licence.

Downloads

NOTE: If these links are 404′d and it’s still November, I may still be uploading the new versions.

Battle for Polaris 0.21b for Windows (.ZIP, 20.1 Megabytes) – Initial release with binaries.

Battle for Polaris 0.21b for Windows Development Version (.ZIP, 48.7 Megabytes) – Includes data, source code, CodeBlocks project files, and DLLs for both Release and Debug versions.

Battle for Polaris 0.21b Source (.ZIP, 359 Kilobytes) – Contains only the source code and config files.

A Linux version should also be available not too long after I set it up on my laptop (I actually mean it this time!)

This post contains the “roadmap” of future features to implement for upcoming versions, as of the release of 0.1 Alpha.

Completed Milestones

0.2 – Gameplay & Code

• Major code tidy-up, commenting, namespaces, et cetera.
• New, cleaner group purchase/deployment system
• Gameplay balancing of ship/weapon types and the example scenarios.
• Mission system and tutorials / instant action mode.
• New ship types: probe and drone.
• Homing missiles; weapon group system.
• Click-selection of ship groups.
• Quitting to menu, with confirmation dialogue.
• Minor AI improvements (tweaks & stances affect whether move orders are ignored)

Planned Milestones

0.3 – Visuals & Content

• Better-looking ship models – more variety.
• Better-looking particle effects.
• Better collision detection (use of hirerarchical bounding volumes for ships, stations, etc)
• New ship types and weapon types; redesign of maps; gameplay balancing.
• Sphere with ripple effect (shader) for ship shields on projectile impact.
• Rotating planets and bodies.
• A smaller version of the interface font.

0.4 – AI (Intermediate)

• Some further code tidy-up and restructuring, particularly for the entity/body systems
• Tweaks and improvements of the ship and group AI.
  • Type-specific collision avoidance – e.g. minor projectiles only dodged in Evasive/Passive stances.
  • Use above system also for friendly fire avoidance.
  • AI can select weapon groups.
  • Tweaks and improvements to target selection.

• Tweaks and improvements of the strategic AI
  • Better action evaluation for purchasing – e.g. last-ditch purchasing, saving up
  • Add small random elements into pre-set AI
  • Improve, tweak and verify the abstract state.
  • Many minor improvements

0.5 Onwards (TBC)

• 3D sound and background music
• Dynamic group creation and arbitrary move orders via the mouse
• More maps and scenarios; dynamic map layout & label positioning (instead of using config values)
• Map editor mode
• Automatic map generator
• Story mode (full-featured mission system; communications/conversation system; docking; saving)
• Predictive and adaptive strategic AI, achieved by finishing, testing and tweaking the Logic Engine
• Networked multiplayer mode

Star Horn (or Star Hike, depending on who you ask) was a group assignment for a computer graphics class in my undergraduate course, and my first major 3D game project. It is written in Java, and makes use of the JMonkey game engine.

Initial coding for the HUD and asteroid scene classes was done by other members of the group, as was the work done towards acquiring models, textures, sounds and other resources. On top of work I’ve done over time adding to the aforementioned code, the rest of the code – the core engine code, the gameplay, AI, et cetera – is mine. @author tags in comments should show what code is not mine.

The AI system here was fairly ambitious and only basic elements were working for the final submission; many ideas from it have been carried forward to Battle for Polaris, which is in many ways a continuation of the project re-designed and re-written for OGRE and C++.

Features

• Control a space ship in a 3D randomly-generated asteroid field
• Use of graphical effects, such as particles and lens flare.
• Three weapons: mass driver, laser and homing missile
• Fight off increasing waves of AI enemies to beat your score

Planned Features

Although Battle for Polaris is in many ways its successor, I plan to keep working on this game as a more straightforward arcade action game.

• An easily-executable download version.
• High Scores screen.
• A better HUD.
• More varied enemy ship types.
• More advanced AI, including coordinated groups and simple adaptivity when choosing ships for the next wave.
• Power-ups and upgrade purchases.
• The ability to travel between sectors.

Known Issues

• There may still be a pesky crash bug or two.
• Ship rotation could be smoother for the first-person camera.
• Some other optimisation could improve and smoothen the gameplay.
• Particle effects could use some tweaking for appearance.

Screenshots

Downloads

Star Horn was developed using Eclipse SDK; source code downloads are in the form of Eclipse workspaces. The version of JMonkey with which it was developed is provided.

StarHorn Eclipse Workspace including JMonkey (.ZIP, 60.8 Megabytes)

Work on the 0.2 feature release of Battle for Polaris is progressing, and is currently almost complete. Some minor changes have been made to the targets put out in the road map, summarised below. The main difference is that the tutorial system has been expanded into a more general and flexible “mission” system specified by config files.

Complete

• Major code tidy-up and commenting
• Restructuring of the configuration system to accommodate scenarios & avoid duplication (new)
• The framework for the configurable mission system that uses triggers & events
• Proper texture/material importing from Blender, so that we can more easily add new ship types, planet atmospheres, and so on. (moved back from 0.3)

In Progress

• Implementation & testing of a tutorial scenario using the new mission system
• Rebalancing of ships, weapons and example skirmish scenarios

To Do

• Some minor code restructuring (namespaces)
• Implementation & testing of “Instant action” mode using the new mission system (new)

Moved Forward to 0.3

• Interface improvements, including click-selection of ship groups

A small update, whose main purpose is to fix the most glaring problems in the preliminary alpha version.

Known Bugs

• Minor visual glitch in the planet model.
• Possibly another crash bug, and various miscallenous bugs.
• The new turning system has necessitated a bit of minor tweaking in the aiming system.
• The high-level AI needs tweaking to be more responsive to low-level events (e.g. the player ship arriving)
• Some balance tuning of ships/weapons is required, particularly of the beam corvette (which is a bit overpowered).

Changelog

• Fixed bug wherein switching the target mode in certain situations would cause a crash.
• Fixed bug wherein losing the last player ship could cause a crash.
• Fixed bug wherein faction death wouldn’t register on the final ship being lost.
• Turning should be smoother, and ship AI should no longer get stuck in a turning loop.

Downloads

Battle for Polaris 0.11a for Windows (.ZIP, 17.7 Megabytes) – Runnable demo version

Battle for Polaris 0.11a for Windows (Dev) (.ZIP, 45.0 Megabytes) – Development version (source code, DLLs, and CodeBlocks project file)

A minor update to BendBall, which may fix many of the glitches that appeared in 0.1a. More testing is needed to see if they’ve been completely eliminated, though.

Changelog

• Added the maximum speed requirement to the grab feature.
• Tweaked physics settings to reduce the appearance of glitchy behaviour.

Downloads

BendBall 0.11a for Windows (.ZIP, 2.4 Megabytes)

BendBall Development Version (Visual Studio 2008 project with source code, .ZIP, 3.51 Megabytes)

NeTron was an assignment for a computer networks class in my undergraduate course. Written in Java using Swing, as well as the Sockets and Threads libraries, it allows multiple players to play the classic game over a network. I put it up here partly as an example of my work with Java, networking, and threaded systems, but also because I plan to do further work on it.

Planned Features

• Proper GUI feed-back for when the client is waiting for the game to begin.
• Help (F1) display that informs the player of the game rules and controls.
• A control and monitoring system for the server.
• AI-controlled players.
• Multi-game sessions and scoring.

Known Bugs

• Separate players may go out of sync
• The server program needs to be restarted once a game ends

Screenshots

Click for full-sized versions.

Videos

Video coming with fixed version

Downloads

Download and/or web applet coming soon

BendBall was my first 3D game project in C++. Its primary purpose was to help me teach myself OpenGL using GLUT, as well as the use of shaders with GLSL, and later on for writing my own physics engine. If you’ve played Pong, you’ll comprehend the basic gameplay – it’s 2 players (no AI yet), there is a ball and a paddle for each player, and each player’s objective is to get the ball past the other’s paddle. The twist is that it’s in 3D.

Planned Features

• An AI-controlled player.
• Progression of the game over time – e.g. arena spin speed and ball curve rate.
• Tweaking of physics and game configurations for balance & playability
• The “ball grabber” feature needs to be weakened so that it can’t just grab the ball all the time.

Known Bugs

• The GLUT timer function is weird, or incorrectly set up, so performance may differ between machines.
• The ball may pass through a paddle when moving too fast.
• There is a crash bug that may be related to the above issue.
• The depth marker for the ball may return when the ball is destroyed
• The ball bounces incorrectly when it is “rolling” on a surface.

Screenshots

Click for full-sized versions.

Videos

BendBall 0.1a Demo Gameplay Video (1:37, WMV, 34.6 Megabytes) - A demonstration of a sample game in the preliminary alpha version

Downloads

BendBall 0.1a for Windows (.ZIP, 2.4 Megabytes) – Initial release of the alpha – contains some known issues (fixed version on its way)

Version for Linux may be forthcoming once I work out how to get it working outside of Visual Studio..