JoeCraft

University Projects

by on Aug.26, 2014, under University Projects

I’ve corralled all of my older University work into this section. I wrote them way back when I was still just a learner, and had no real professional experience. They are mainly here for posterity, since I would likely rewrite them rather than improve the existing Java projects; they shouldn’t be taken as representative of my newer work.

Leave a Comment more...

BendBall 0.12

by on Aug.25, 2014, under BendBall

This replaces version 0.11b. The main visible changes here are tweaks to gameplay, and making the grabber function automatic.

Besides that, I’ve been working towards tidying up the code. I’ve done a bit to split code up and do some tidy-up so far; I’ve been writing comments noting these as I go, and as I find the time I’ll be making further improvements. Sources are always available to see in the BitBucket repository (see below).

Code Analysis and Future Plans

Functionality-wise, my immediate plans are to fix the main known issues. Particular priority to the “ball sinking” state, where deflector positions should be reset and the ball marker should not be displayed; and the collision resolution system, which should be made to better handle fast moving objects and three-way collisions between ball, wall and deflector.

It’s been interesting taking a look at code I wrote 4-5 years ago, when I I had much less experience with C++ (and no professional experience). A lot of the basic structure I think is fine, but I have found various aspects that I think could be better. I see three main problems:

  1. Duplication – there’s a lot of unnecessary duplication. In my experience, a “Don’t Repeat Yourself” philosophy really helps make code more maintainable and readable in the long run.
  2. God objects” – classes like FPGame and FPSettings are too big and cumbersome, and should be split up.
  3. High coupling with external libraries – OpenGL rendering specific code is placed within the game classes. Ideally I’d like to reduce this coupling as much as possible, by having one or a set of classes specific to external libraries like OpenGL and GLUT.

With my newer projects I’ve tried to have a wrapper class that governs an entity and a factory for making entities from configs or specifications, rather than having them created and kept loose on a main class. I’ve also had a separate class that governs setting up and performing the actual rendering of the game world, and would like to do the same for the main game init and loop. This would allow for keeping OpenGL/GLUT code separate.

Free time allowing, I would like to write up a common game framework using the above ideas. This could then be used for both BendBall, BattleForPolaris, and any future C++ game projects. I’ve been Die Evil Rocks project in Python, and once that structure is finalised I would like to draw up the design and port it back to my common C++ code.

Changelog

  • Project code restructure, and bundled libraries.
  • Grabber use is now automatic, preventing players from just grabbing the ball during normal play.
  • Settings tweaks to improve gameplay; particularly physics and game field size.

Links

BendBall 0.12 for Windows (.ZIP, 2.48 Megabytes)

BendBall Source (BitBucket Repository)

Leave a Comment more...

Battle for Polaris Roadmap

by on Aug.24, 2014, under Battle for Polaris

This post is to keep track of the “roadmap” of future features to implement for upcoming versions, as of the release of 0.1 Alpha. I revise this occasionally, removing old parts to keep it manageable, hence the bumps in the publish date.

For the latest release, see Battle for Polaris 0.21b.

For latest code, see Battle for Polaris on BitBucket.

Completed Milestones

0.22 – Refactor, Restructure and Update

  • Refactor of objects, entities and configuration system
  • Update of OGRE and CEGUI libraries to latest, and code changes to support this.
  • Removed some reliance on OGRE, e.g. singletons
  • Optimisations and improvements, particularly to aiming code
  • General code tidy-up

In-Progress Milestones

0.23 – Logging, AI and small Gameplay improvements

  • Simple logging system with switchable labels and levels, just to console (or Windows debug output) now
  •  Improvements to dogfight AI, using improved logging
    • Debug issues with target selection and retreating appearing incorrect, such as a group of ships sometimes all picking the same target.
    • Also better evasive/retreat behaviours; attempt lateral movement and shaking the player off their tail, rather than just flying away and wiggling a bit.
  • Tweaks to gameplay. Longer ranges, movement, scale and weapon tweaks, and provide some chance of skill in avoiding shots.
  • Convincing random inaccuracy to AI for a fairer challenge.
  • Wave survival mode for the simulator, instead of having to jump from sector to sector.
  • Tweaks to particle effects.
  • Add particle effects to vertical/lateral thrusters.

Ongoing – Refactors and Cross-Platform

This is kind of a side-milestone for project and code improvements that don’t involve actual game content or functionality. I’m keeping this list separate, since I am trying to alternate between this utility/infrastructure work and the work that makes the game itself better.

  • CMake project files.
  • Linux build and development environment.
  • Ongoing phasing out of direct use of OGRE code for utilities such as logging and configuration.
  • Game Engine Refactor – use common engine framework between BfP, BendBall, and future projects.
    • Single componentised interface for rendering, main loop and events to OGRE/OIS/CEGUI
    • Objective is to fully decouple my code from these dependencies, so that they can eventually be easily switchable to alternatives.

Planned Milestones

0.3 – AI (Intermediate) and RTS Gameplay

  • RTS gameplay improvements
    • Allow ships to be moved to points, rather than just circling objects. New representation of the world is needed for the AI to handle this.
    • Alterations to how ships move, in terms of speed, and weapon range/effectiveness, to allow for a more tactical game of ship positioning and flanking.
    • Terrain types (e.g. dust clouds) with bonuses.
    • Pathfinding system that takes advantage of terrain and flanking.
  • AI debug draw system – visuals for AI ship and strategic state, motion, targeting/aiming… (needs design)
  • Tweaks and improvements of the ship and group AI.
    • Better decision-making, using weighted-randomness. Fixes to how (and where) ships choose to retreat and choose their targets.
    • Type-specific collision avoidance – e.g. minor projectiles only dodged in Evasive/Passive stances.
    • Use above system also for friendly fire avoidance.
    • AI can strafe to dodge and adopt formation more quickly.
    • AI can select weapon groups.
    • Tweaks and improvements to target selection.
    • More dynamic dogfighting AI
  • 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.
    • Other improvements? (TBC)

0.4 – Visuals & Content

  • Better-looking ship models – more variety.
  • Better-looking particle effects.
  • Better and more dynamic space backgrounds.
  • 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 with atmospheres.
  • A smaller version of the interface font.

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
  • First-person POV
  • VR (Oculus Rift) support
Leave a Comment more...

Dot Muncher 0.1a

by on Aug.18, 2014, under Dot Muncher

I did a little something, which I thought might be worth putting up here. I was recently given this as a C++/SDL programming assignment, but got a bit carried away and effectively re-wrote the whole thing with my own code. I also did all of the terrible programmer art myself in GIMP.

It’s nothing too creative right now, just a Pac-Man clone. Just the one level at the moment, and without a fancy intro or game over screen. Control with the arrow keys.

I’ve found this to be a worthwhile exercise in just writing a little game to finish, and it’s a pretty decent example of my recent code. It’s heavily commented, particularly with a few more changes I plan on doing soon-ish.

Links

Dot Muncher 0.1a for Windows (.ZIP, 1.83 Megabytes)

Dot Muncher Source (BitBucket repository)

Leave a Comment more...

Progress Update

by on Jul.06, 2014, under Battle for Polaris, Personal

It’s been a few months, so I thought I’d post a progress update. I’ve been rather busy on the personal and work side of things, but have managed to work on some behind-the-scenes improvements in the meantime. Here’s a summary of what I’ve done over the last few months:

Battle for Polaris

I’ve finished the first set of major restructures and refactors I wanted to do. This included updating the codebase to work with latest OGRE and CEGUI, which was a job and a half in itself. I’ve also done some general tidy-up, and changed the project’s folder structure to separate header and source files. Since I’m trying to move towards having BfPEngine be a reusable framework, this made sense to me.

The main thing left to do in terms of refactor is the phasing out of OGRE code. I’m not particularly happy about depending on OGRE for simple things such as singletons, logging, string/real types, and so forth; I’ve worked quite a bit with logging systems – particularly Python’s nice logging system – since I did this, so I think I can do much better now. These plans are, however, on short-to-medium-term hold, since it feels like it’s been too long since I’ve worked on improving the meat of the gameplay and AI.

I’ve been reading back on my original plans from this project, from way back in my University days. I’ll be revisiting the old roadmap and writing up specific documentation as I go along, but the high-level summary of where I want to take the game AI is as follows:

  • General improvements to gameplay, and unit/group AI. Already summarised in my older (recently-updated) roadmap.
  • Use of probabilistic reasoning with Bayesian Networks in the high-level AI. Initially this would be to predict the player’s ship and sector positions, as a form of inferred influence map.
  • High-level AI that learns a player model over time, e.g. learning the player’s ship preferences. This already has a design, but may need revisiting after gameplay changes.
  • Investigate reinforcement learning AI. This is of academic interest, but in terms of practicality may need a more pragmatic hybrid approach.

I would like to further document this on the blog, so will be putting up posts with diagrams and overviews as I revisit and improve each section of the game code.

Interactive Fiction

This is still in the ideas stage. I would like to do something visual and gamey with this, but it has to work around my lack of artistic talent. I hope to draw up a proper design of this when I have a chance, though BfP is the priority at the moment.

Leave a Comment more...

Ongoing projects

by on Jan.06, 2014, under Personal

Ha, you thought I was serious when I said I’d be posting more often. Excuses aside, I’m just going to post a “brief” summary of what kind of things I’m wanting to work on and at what kind of stage they are. Again, this is largely for my own benefit.

Battle for Polaris

It’s been so long since I did anything major with this project, at least in terms of adding features. I’m still mired in refactoring it to make it compatible with latest versions of OGRE/CEGUI/etc, mainly so that I can have a nice CMake project and build it across different IDEs and OSs.

After that, I want to revisit and possibly revise the roadmap. There’s still an overwhelming amount of stuff I want to do with this project.

Die Evil Rocks (project codename!)

This is a 2D game project using pygame that I’ve been working on a bit. Since I’m a Sci-Fi nerd who can’t draw people or animate, it’s naturally another space game.

As usual, I have mega-ambitious ideas for this project. I don’t want to go into too much detail on it yet, but suffice to say that I’m being greatly influenced by an all-time favourite Star Control 2 as well as the glut of indie Metroidvania-style games we’ve been seeing.

I have a more sensible and achievable (in the shorter term) prototype/demo that involves showing off the flight controls and combat in a more limited explorable environment.

A lot of of the base game engine framework is down, and I’m working on getting a decent side-scrolling spaceship control system working. Again, this is more a matter of iterating over and tweaking a design, since obviously the controls are a massively important aspect of a combat/exploration game. I have in mind a weighty but not awkward physics-based flight system for the controls; Defender and Lunar Lander are both points of inspiration and not anywhere near what I want; Aquaria is probably the closest thing to the weighty but intuitive movement I have in mind for my game that I can think of.

The code is on my BitBucket, but I’m not going to make it public until I’ve got something worth showing – at least some nice controls and basic visuals.

Roguelike

This is on hold, pending a proper (initial) design, as well as a decision on what language/framework I want to use. I started off with Python and libtcod, but might end up going with C/C++. This is partly for performance reasons, and wanting to implement interesting things like lighting and line-of-sight myself. Back burner for the time being though.

Roguelikes are one of my favourite genres, and I’ve always wanted to make a classic-style ASCII one of my own. Unfortunately I’m currently just more excited about Die Evil Rocks and Battle for Polaris.

Fiction

The novel is at about 70-80% completion of the first draft – most of the story is done, but I’m busy working another perspective into it that should tie the narrative together better.

Also, one of these weekends I’m going to sit down, pick out a short story idea from the bucket, and bash something out. In the mean time, I’m looking into putting up some of my old short stories here, if I deem them not to be too embarrassing.

Interactive Fiction

I’ve recently become aware of interactive fiction – not that I didn’t know it existed before, but you know what I mean – and I’m quite interested in putting my hand in there. Current plan is:

  1. Research the interactive fiction engines/frameworks out there – either find one to use, or thing about implementing it myself.
  2. Come up with a decent premise or story, or adapt an existing one to the plan
  3. Make the bloody thing
Leave a Comment more...

BitBucket & plans

by on Jan.01, 2014, under Battle for Polaris

I’ve been using BitBucket for my source code. Latest code is available at the following URL: https://bitbucket.org/Imek/battle-for-polaris

Most of the latest changes have been refactors, mainly towards being able to swap out GUI frameworks and the ultimate goal of being able to build portably between Windows/Linux. Hence, there’s not much point in a new binary release.

The closest thing to a visible change is improvement to target-leading AI, using a proper mathematical method that is capable of taking projectile acceleration into account. This is also *far* more efficient than the naïve “expanding circle” algorithm it replaced.

Hopefully I’ll be getting more of a chance to work on this towards version 0.3; expect an re-evaluated (in terms of priorities) roadmap, though.

Leave a Comment more...

Still around.

by on May.09, 2011, under Personal

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.

Leave a Comment more...

Battle for Polaris 0.21b

by on Nov.29, 2009, under Battle for Polaris

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.

Battle for Polaris 0.1a Screen 1 Battle for Polaris 0.1a Screen 2

Battle for Polaris 0.1a Screen 3 Battle for Polaris 0.1a Screen 4

Battle for Polaris 0.1a Screen 5 Battle for Polaris 0.1a Screen 6

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

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

Below are old development and source releases. NOTE that you will find much more up-to-date code at Battle for Polaris on BitBucket.

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!)

Leave a Comment more...

Star Horn

by on Oct.27, 2009, under University Projects

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

Battle for Polaris is pretty much the successor to this project, and as such I have no explicit plans to work further on Star Horn. However, the wave-defence scenario is something I do want to incorporate into BfP. For posterity and reference, here is the planned features list I had at time of original upload:

  • 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

StarHorn Screen 1 StarHorn Screen 2

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)

Leave a Comment more...