Project Structure

Leave a reply

Spare-time game development for me is primarily a learning exercise. If I get a game out the other end then that’s great, but I’m more interested in what I learn along the way. I’ve been reading through old entries on Noel Llopis (co-creator of Amazing Alex/Casey’s Contraptions)’s blog, Games From Within and was inspired by his comments on unit testing and TDD and thought I’d try out TDD in my own project. The interface for some of my low level code had gotten pretty nasty so I thought I’d throw it all out and start again. This is a strange luxury of personal projects, and the reason I never end up finishing anything. I guess I’ll leave shipping games to my day job. This also presented a perfect opportunity to really familiarise myself with Xcode I recently bought a MacBook Air and until now my experience with Xcode has primarily been a process of getting a project to compile for iOS and never changing anything ever again. Integrating projects to run unit tests after a compile which would interrupt the build process would allow me to explore some of the more advanced features of the IDE.

My Xcode workspace currently takes this shape:

Project structure diagram

Actual, unedited screenshot of my project structure!

  • Engine – non-game-specific, re-usable code. This is where all my entity/component base classes live, along with some re-usable components and subsystems
    • EngineTests – unit tests for the engine code
  • GameLib – game code library. This is where all the game-specific code goes
    • GameLibTests – unit tests for the game code
  • Cocos2dx – the cross platform graphics framework I’m using
  • UnitTest++ – unit testing framework
  • GLM – GLSL-like C++ library for vectors/matrices/etc
  • Game launcher – the platform-specific entry point for the game. Used to make a window, set up the render context, etc

All of these projects except the launcher and the test projects compile to a shared library to keep everything nice and modular – the tests projects use the same .a file as the game launcher itself.
This is all currently building a Mac binary, but switching over to iOS or Android should just be a matter of adding a new target for the appropriate platform and changing a couple of its settings for the most-part everything will just work. There’s no game yet but that’ll come in time!

Update: Just to potentially make this post useful to someone, I thought I’d share something that I had to wrestle with briefly trying to set this all up. In Xcode, if you run your unit tests as a pre-build phase of your Scheme, the return code will be ignored and it won’t count as a build error, so any unit tests which fail will do so silently. I have a Target for my game setup which has a Run Script build phase on it, which is just the path to the Product produced by unit test project, and the Scheme is setup to build the game and the unit tests. This way the build will show errors if any unit tests fail.

 

 

Events Are Operational

Leave a reply

I have implemented my proposal outlined in the previous post and all it’s working great. There’s a base TriggerComponent class which holds a pointer to its action. PositionTriggerComponent extends TriggerComponent, and PositionTriggerSubSystem checks for objects occupying PositionTriggerComponent-Entities’ tiles and sets the triggered flag on their Actions. Finally, classes inheriting from ActionSubsystem decide how to handle their actions being triggered. This is working for a simple DebugActionComponent/SubSystem but the idea should apply to anything else. Getting closer to being able to make a game.

Hello, The Internet

Leave a reply

I'm currently developing a personal-project mobile game using Cocos2d-x, a cross platform port of the Cocos2d-iOS framework. I got as far as having a few graphical layers moving sprites on the screen when I got tired of 2d-x's weird Objective-C–shoehorned–into–C++ style, which encourages the use of static factory functions to create objects, when C++ already has constructors. I had also been reading a lot about Entity/Component (EC) systems for game development – a methodology that allows for game objects to be built up from collections of reusable components, and, relevantly, forces logic to be separated from display code. I thought this would be a great opportunity to implement my own EC system, as it would keep the nasty Object-C style code very localised and wouldn't spread to any parts of the game logic.

This went really well – after writing and refining the EC framework, then coding some fundamental components and subsystems (such as SpriteRenderable and Position components and SpriteRenderer subsystem), I had a character I could set the world position of, and the SpriteRenderer subsystem would set the Cocos sprite's position accordingly. I went on to write the relevant components and subsystems to get the character moving around a tile base map, using the Cocos touch interface and all was good.

Then I hit a problem. The game I'm developing needs a trigger system. An entity (e.g. a button) needs to trigger an action (e.g. a door opening). This requires the subsystem to track entities with Button components (the trigger) and entities with Position components (the entity that will cause the button to trigger) and consider them independently:

for each Entity with Button and Position: b
    for each Entity with Position: p
        if b.pos == p.pos
            b.button.triggerAction()

..which my current system doesn't support, so I'll have to add the concept of or and and operators to the class that defines the types a subsystem is interested in. I'll check back in when that's implemented and hopefully I'll have a nice, flexible event triggering system.