Indie game development, the final (well, next at least) frontier. These are the voyages of a novice developer. The ongoing mission: to explore new technologies and new methods. To boldly go where no novice has gone before.
Over the course of this project, it became more and more apparent that the Marte Engine wasn’t going to work for me for several reasons, not least of which was that the way it’s set up leaves no room for unit testing without building a mock environment. Also I saw some ugly inheritance issues looming on the horizon.
After having considered how best to resolve these problems (with a great deal of advice from my friend Alex), I decided to migrate to a component system. I did some research on some existing component frameworks (Artemis, for example), but I was concerned that I’d run into some of the same problems with other existing frameworks. The only way to be sure an engine or framework is going to work the way I need it to is to write it myself, so I have been.
Alex recommended I use PicoContainer to handle my component instantiation, which turned out to be brilliant and exactly the sort of tool I needed. I’ve also switched over to Scala, partly because a future project with which I will be involved will be in Scala, but primarily because it allows me to directly solve some problems that java would make me circumvent.
I’m not nearly at the same place I was when using Marte, however, I’m farther along on my engine in Scala than I was in java. Using PicoContainer Script, an extension for pico that enables container construction from XML or a variety of scripting formats, I’ve built a complete entity creation system, wherein I pass an XML file in one end specifying what sorts of components the entity needs, and get a fully populated (and functioning) Entity instance out the other side. I’m very pleased.
The next step is to figure out a way to parse an XML file and create a Reader of some sort with only a specific block. For example, I want to have all the entities that exist in a given level in the same XML file with all the tiles and so on.
<component-imlementation class=”some.package.Class” />
<component-implementation class=”some.other.Thing” />
The XMLContainerBuilder only cares about the <container> block. I’d like to extract each such block to squeeze through the builder without having to have a separate file for each one.
In this case, it’s very very nice that scala and java are interoperable. This would all be hellish otherwise. Instead, it’s quite fun!
Today a forum-friend of mine ( we linked up at a game programming forum) who happens to be someone working for a game company pointed out that my interest and my learning process was not matching each other and Since I am more interested in gameplay programming and AI for games, I should focus on gameplay programming. His Exact words were:
So, I suggest you to put your study of DX11 on hold and start making something using any of the game engines available to you, that will certainly help your portfolio rather than learning DX11.
Okay, so that’s the whole story, So I now have to re-think my learning strategy. I might put DX11 on hold for now although I’m sure the skills I have learned using DX so far will be helpful for me in making games using other engines as well.
In the meanwhile I am looking for a suitable game engine. Any Ideas would be helpful!!!
I found myself in a similar place when I first started on my journey to game development. I was armed with a copy of Killer Game Programming in Java and a general idea of what I wanted. I started out following KGPJ and trying to make a basic platformer, but that required writing a render/update loop, a physics engine and using Java2D. Yuck.
Thankfully, a friend recommended I check out Slick, and from there I encountered the Marte Engine. I can definitely appreciate not having to reinvent the wheel, and instead focus my attention on the actual game code.
I wish the original author the best of luck in choosing a game to make. Cheers!