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") |
Musings, rants, and knowledge of an aspiring game programmer.
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.
What? You want to know why there's yet another programming blog on the block? Okay, let me tell you
I've been following the works of programmers like Falco Girgis and Rachel Morris for quite some time now and I really like what they bring to the table. Their videos are informative and entertaining which is a great break from the stuffy, highly technical literature we usually read. I do what I can and learn quite a bit from StackExchange but the straightforward QA format is great for exact issues but not as great for general learning purposes.
I would not consider myself a regular of the blogging community. The only blog I even follow semi-regularly is Coding Horror (awesome blog, check it out if you haven't), however, I have read many blog posts. Usually when I'm searching for an explanation of a concept or am just thinking about an interesting topic in the world of programming.
So many nameless programmers helped me so much.
I'd like to add my name to that list of the nameless. Maybe someone will be having trouble with a particular concept which I figured out, or in the very least made some headway, and I can help them solve it.
As I'm sure everyone has heard from a history teacher at one time or another, how can we know where we're going if we don't know where we've been? Computer Science is still in it's infancy compared to other sciences but this doesn't mean that we don't have a history. Programming takes time--a lot of time--and we only have a limited amount of time to code everything that we want. There's no point in re-inventing the wheel (unless of course you're making the wheel better) and by logging what I've done I can reference back to it and avoid wasting time.
Primarily, this blog is for my entertainment. A way for me to get out my thoughts, keep track of my progress, and hopefully help some other people along the way. That being said, I plan to post on more than just programming. While programming is my main addiction and source of entertainment, I also try to keep involved in other worldly affairs.
I don't know how often I'll post, what exactly I'll post, or even why I'm posting it. But it ought to be an interesting journey.