The Adamite engine, first groundwork and laying out future plans

the current vague plan looks a bit like this:

This blog is here to document my thoughts and my progress on projects I’m making. The first such project is creating an engine for the course “game programming in 2D”, which I’m currently doing at the GAME education on Uppsala University, campus Gotland.

In the course we’ll be using C++ and SDL2  to create a game engine. I’ve chosen to not follow our course director Jerry’s design, which uses raw-pointers and new-delete architecture. Instead I’ve decided to keep to what we’ve learned in earlier courses, and use proper encapsulation in classes with constructors and destructors.

To that end, I’ve started out by taking an earlier architecture that we created in the first programming course, and adapting it more to my style while also using precompiled headers, which we did not do in that course:

(commit 5204386)

Some changes I’ve done to what we did in the earlier course is that I’ve clumped the renderer together with the Window class, and made them into a RenderWindow class. This is mostly out of convenience since I can’t see that I’ll be needing several renders in one Window at this time, and if I need to change it, I can still keep the RenderWindow interface the same, and just factor out the Render functionality into it’s own class.
Another change is that I use precompiled headers, which Jerry is using in this course, but we didn’t use them in the earlier course.

Looking forward, there are a number of things that need to be thought out and implemented, but the current vague plan looks a bit like this:

  • Make a SpriteManager, Sprites, and later on animations of some sort, probably based off of code I’ve seen from one of my upperclassmen.
  • Make a Soundmanager.
  • Make some sort of Entity/GameObject hierarchy, my current thinking is that I’ll create a Component system where I have two abstract interfaces IComponent and IGameObject, where the IGameObject holds a list of updateable IComponents and iterates through that list each update.
    The main problems I’ve thought of with this is how to manage the communications between Components.
  • Some form of decoupling between each domain, my first thoughts were to copy the SDL/SFML Event structure of having a class that contains a type enum, and a union of data structs, which holds the data for whatever event has occurred. However, seeing the ServiceLocator Pattern used in the lectures, and later researching it more, made me interested in trying to use that instead. This requires some more experimenting and thought before deciding.
  • Since SDL doesn’t have it’s own time handling system like SFML does, I’m thinking of trying to use std::chrono for handling time in my engine, but I need to research how it works more first.
  • Loading of files, both for textures, sound, and for my own objects. As I’m thinking of making the game tilebased, a way of loading maps (made in TilEd, for example), would be great. Also being able to specify animations, enemy data, build specifications that can be used in ObjectFactories for example.

Looking at the game I want to make, it will be a Rouge-like, probably tilebased (using TilEd), and based in a post-apocalyptic future where rouge AI’s have killed off most/all humans. The player will play as an AI robot which at the start of the game has just gained concsioussness, and has no idea where they are, or what to do.
I’ll create some “main story” hook, but the ideal setting would be similar to the bethesda rpg’s, where the main story line can be almost entirely ignored in favor of just exploring the world and finding cool stuff and events.

This page probably needs some editing still, but I want to get started coding now, so if this message is here when you read this post, I never got around to editing it =P.

Edit1: I did edit it a bit, it’s a bit messy, but I think I’ll leave it as is, because I could be writing code instead of editing blogposts =).

(Why adamite? it looks cool, and it’s a mineral that begins with an A: