The graphics will likely change a lot before the final release. Also, there's going to be a lot more than just trees. |
Here you can see how the top and bottom halves mirror each other. The landscape will do similar mirroring (one "happy", one "sad") |
The graphics will likely change a lot before the final release. Also, there's going to be a lot more than just trees. |
Here you can see how the top and bottom halves mirror each other. The landscape will do similar mirroring (one "happy", one "sad") |
What with school being back in session, I haven't really had too much time to work on my personal projects but I figure now is as good of a time as any to share where I'm at so far. Here's the basic setup:
First off, I'm doing things in what some consider a backwards fashion. I have a game that I'd like to build but I'm focused on building the engine itself before creating the game. I've made quite a few small games in the past and have started to get an idea of what parts I always have to recreate (rendering, input, collision, etc.) so I figured it made sense to start building my own engine at this point. Since I am taking it from the other end, it also made more sense to try out a new system. Enter: the Entity-Component framework.
Remember how I said sort of? Here's what I mean: a pure Entity-Component framework is purely relational. That is to say, there is no "Entity" object. An Entity only exists in the sense that one or more Components are related to one another through an ID system. I'm using a sort-of system because I actually have an Entity class. Basically, my framework is laid out as:
So a Layer contains a set of Entities and each Entity contains a set of Components and, finally, some Components can subscribe to Systems which act as special behavior checks (such as collision structures). I opted for this design because I feel that I still reap many of the extensible benefits of the Entity-Component design, whilst keeping some of the advantages of an OO design.
The Entity class really doesn't do much of anything outside of contains Components and an ID. However, some collections of Components are very common and so I can extend the Entity class to create a common Entity type (which can be further extended). As for example, when dealing with a 2D game, a large chunk of your objects are going to have a texture, animation, and collision component. So rather than having to do this:
Entity myEntity = new Entity(); myEntity.AddComponent(new CTexture("sprite.png")); myEntity.AddComponent(new CAnimation()); ...
every single time I need a sprite, I can just do something like this:
public class ESprite : Entity { // Fields and properties and things public ESprite(string textureName) { this.AddComponent(new CTexture(textureName)) this.AddComponent(new CAnimation()) ... }
}
Now I can use ESprite anywhere that I need an Entity with those given Components and I can still safely cast it down to an Entity without worry of loss of data. Personally, I also like to add special properties which access the properties of those specialized Components but that's not incredibly important.
The toolkit acts as a direct extension of the engine. Not much can be said for design, as the design is relatively straightforward at this point. Pick your tool, use the tool. What is kind of interesting is that for the toolkit, a map file had to be developed. As such, in the core of the engine lies a self-built serialization system which relies on Reflection to dynamically load in and write out fields to various objects. The serializer only directly recognizes the existence of Components, Entities, and Layers but from those it can automatically read/write any objects which extend from them. I'm sure after I have more time I will go in to more depth on the process.
Stay tuned for updates and feel free to send me any questions, comments, criticism, etc.