Sunday, July 15, 2012

Preview of Things to Come

Run & Jump is running a little behind schedule, mostly because my co-developer and I aren't able to work together right now. He's been moving and getting a new job and blah, blah, blah but everything should be settled in soon enough. In the meantime, the rest of the world is going to get to see a preview of the game before he does.


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

Friday, July 6, 2012

Walk or Fall

My most recent game project is nearing completion. A little project I like to call

Run & Jump

As you may or may not have guessed, you can run and you can also jump in this game. I plan to release it on the PC soon enough, shortly after doing an XBLA release (right after I upgrade to a paid membership). It's a very simple game that is just about finished and we've only been working on it for about 2 weeks. However, in this simple project I did get to do something that was kind of cool.
In Run & Jump you never make it to the end. As in, the game goes on forever. So naturally, how do you create infinity when the player can move in either direction, i.e., they would be able to tell if the level all of a sudden changed upon going backwards. We took a couple of cues from procedurally generated games, as well as from Hanna-Barbera. We have different sections broken in to "chunks." Each of these chunks contain a set of random scenery for the level. The game contains some X number of chunks, so many of them that the player most likely wouldn't be able to recognize them all. After the player passes the last chunk in the level it wraps around, much like the "chase" scenes in The Flinstones and other similar cartoons.
It's not horribly technically impressive but it was a fun little trick that I never got to try out before.

Expect to see Run & Jump out soon.

Friday, June 29, 2012

New Project(s)

Here's a little micro-post for all of you out there. It's been quite a while since I posted something, mostly because a lot has been happening. The game I had been working on has been tossed. In short, we had a lot of ideas but very little was concrete and the team wasn't working very well together. The pre-pre-pre work for a new RPG has started. Myself and my co-developer are just working on the story right now, not even bothering to put code to compiler yet. In the meantime, we've decided to start working on a series of smaller games that, hopefully, each one shouldn't take more than a month to do. The current one is a platformer and after a week it's about 40% done. All of the basic functionality is there, we just need to add some art, music, menus, wrap it up, and let it go. Expect a release from Space Lime Studios for PC and XBox 360 in the near future.

Sunday, February 19, 2012

Gotten A Little Crazy

Just a quick micro-post of sorts. I had intended to write a couple more posts recently, specifically discussing the Entity-Component framework and one on billboarding, but things have gotten a little crazy as of late. School has gotten in to full swing and 14 credit hours is beginning to take it's toll. Couple that with the fact that my team is about to release our first product (so excited!) and that's left me with little to no time to try and stay on top of this blog thing.

I've already written a rough draft for my tutorial on billboarding (gave me such a headache figuring out the first time) so I'll aim to finish it soon enough.

Sunday, January 15, 2012

Intro to My Engine

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:

    Engine

  • C#
  • XNA
  • Entity-Component Framework (sort of, I'll get to that)
  • Toolkit

  • Intended to be general purpose toolkit for engine
  • Currently supports 2D mapping
  • Custom serialization method (to be expanded on further in the future)

Engine

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:

  • Layer
    • System[]
    • Entity[]
  • Entity
    • Component[]

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.

Toolkit

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.