Engine growing pains

Where did I left off? Oh, that's right:

After playing around with Chipmunk for a while, and implementing a few of the features that I want for one of my projects, I can do little but recommend it as a great physics library, very easy to code with, with great performance, and flexible! Allowed me to prototype some more complex features I want to add (destructible objects) with ease, and its structured in a way to allow to adapt it to many game mechanic scenarios. Some tests I did on an older computer showed it performed better than Box2D, but it was a superficial test, so I won't back up that claim :)

Having a fine physics engine at my disposal, I decided I needed to create a level editor to easily start laying down levels; so, I needed a GUI. I looked around for a barebones lightweight GUI that would integrate well into Allegro, and went with the recommendations for GUIChan. It was indeed easy to integrate and use, and allowed me to design a GUI that let me add floors, walls and connect them with joints. This gave me an incredible sense of achievement, motivation, and the project started feeling more like a game and less like tech development, which was great. And doing levels in it was fun :)

From this point, the code to connect the several engine parts was becoming a bit muddled, so I took a break to refactor it, and from there decided I needed to integrate scripting into the Engine, to allow for easier prototyping (I frequently realize that doing something that will apparently take a long time pays off in the long run, as it simplifies greatly the work and speeds it up after it is integrated and working).

I looked around for available scripting engines, considering Lua, GameMonkey, Angelscript, Squirrel (I rejected Javascript as I don't quite like its syntax). I had some experience working with Lua, and it's generally the, but Wolfire's reasons to their choice for scripting engine sounded quite reasonable (most importantly to me, C++ native integration and syntax), and the Internet showed me that AngelScript was showing a lot of promise, so in I went.

I can say from my experience, integrating a new and unknown library into a project always involves some degree of time needed just to become acquainted with it's workings and quirks, and for integrating a scripting library, it takes quite a lot of time. After this initial period of figuring AngelScript's binding format and details, it was very rewarding to see my "main" function reduced to a few lines and the main code running from a script file, from there having access to all of my engine, being it graphics, gui or physics :)

The next step was to integrate Hardware Graphic Acceleration into Allegro's drawing routines.
I have been an Allegro fan for quite a few years, since I was exposed to Johan Peitz's excellent games "Alex the Allegator", "Operation Spacehog" and "Icy Tower", which I played extensively and all used Allegro).

It presents lots of great features for quickly prototyping games, but being a library with a long legacy (from early DOS days), nowadays it requires a few add-ons to have important features, such as Jpeg and Png loading, and hardware acceleration for graphic rendering (and subsequent benefits from hardware rendering, such as fast transparency and lighting effects).

With these being features I need for my projects, I looked into integrating hardware acceleration into Allegro, based on available libraries. The most obvious options were AllegroGL, which allows making OpenGL calls directly from Allegro (but requires knowledge of OpenGL, of which I possess but am quite rusty on:) ), or OpenLayer, which nicely covers all of OpenGL's technical stuff under a simple API. So, OpenLayer it was.

...happily I went to integrate OpenLayer. Everything was going well, until... I wanted to load a Jpeg. OpenLayer natively allows png loading, but provides no support for Jpeg. "Ok", I think "I'll just the jpeg loader which I had previously included, it let's me load jpegs into Allegro fine".

Turns out it wasn't so easy. OpenLayer was not doing well with me making non-Openlayer Allegro calls, which were necessary to load jpegs, and was not being capable of obtaining the data I passed onto it after loading from the image file. Looking around the web for some help or a solution made the problem obvious: OpenLayer once had a forum/mailing list, but is now discontinued; all the help I could get would be from Allegro's forums, but I could not find any information related to the problem I was facing, and to add the fact that OpenLayer had not been updated since 2007, I figured it was better to try another approach: move on.

I went for a walk on the cold night air, to think it through, ponder my choices and come to a sound decision. Removing Allegro would involve refactoring most of the engine (and possibly losing the chance to use GUIChan), which would take extra time. However, with what I knew at the time, it was something I needed to do.

So I looked for alternatives, from "game libraries", to "graphic libraries" to "game engines" (the difference between a library and an engine being that a library is code that integrates into other code, generally in C or C++, and an engine provides a more or less "complete" set of game necessary features such as graphics, sound, input, and collision/physics and is interacted with trough a scripting language, which allows for faster prototype/game development but is less flexible to adapt to your needs and probably slower than a game engine customized by yourself).

So, for the switch from Allegro to another library, I went with Simple and Fast Multimedia Library (SFML), an excellently documented (tutorials are the best documentation ever!), with a live community, great and simple API and feature complete for what I needed.
I also considered using a 3D engine (Irrlicht, which I have some experience with and found very fast, unlike Ogre3D, and is used by Soldat's Michał Marcinkowski to a similar end that I would use), or an already available "game engine", such as "cocos2d", "angel-engine", "indielib", "love2d", or 2dboy's "rapid-prototyping-framework".

Fortunately, SFML's great design and easy to follow documentation, and the fact that I already had the design for my engine decided and thought out made the reimplementation quick and painless. I strongly recommend SFML as a 2D game development library :)

So now the Engine is composed of:

SFML - Windowing, Graphics (Hardware accelerated), Input, Image/Font/Sound loading (and much more :))
GUI - still to determine (possibilities: CEGUI, cpGUI, GUIChan with SFML wrapper)
AngelScript - for Scripting
Chipmunk - Physics library

P.S: at the time I was thinking/looking for alternatives, I totally forgot that Allegro's recent branch (which will become Allegro 5) has included hardware acceleration and png/jpeg loading, which were the main features I needed to add. However, it's always refered to as "work in progress" and "unstable" and there weren't many Internet references to it, so it's probably best to avoid it for a while, and keep SFML as my current engine.

So currently, I'm working on an animation system and resource management. Next, re-exposing the new engine to AngelScript, and finding a GUI. Then, defining and adding game objects including both visual and physical representations :) And from there, a game level with most/all game features in it (and naturally, starting work on graphics).

Change of Pace

So I started thinking about how complex the whole Game Engine was becoming, and specifically the collision response module, and decided to switch gears for a while. In order to take a more frugal approach to the development of an engine I might use to create games, I decided to start from the other end, developing games without an underlying game engine, and learn from what I actually use to create the game, and then go from there.
Started a new project which uses the excellent Chipmunk 2d Physics engine, hopefully I'll post more about it soon (the "Stealth-Platformer-Shooter Project" I mention in the top right box).

Breaking news - Working on Game Engine

So hay!

These past few months I have been experimenting and designing a collision detection and response method that would allow me to configure the objects collision parameters and don't have to implement how it would be handled, and make it reasonably flexible so it would cover most of the kinds of collision response seen in platforming games like Sonic, Megaman, or simpler ones like puzzlers.

This has taken quite a lot of thinking, research, trial and error, and mostly TIME, and will take even more of these, so stuff got delayed (all this when I realised I wanted to not have to bother much with how collision response would behave in Pong! Then i started thinking how to build a unified and configurable collision response method so it would work for the kind of games I want to do, and would save me the trouble of rewriting code or worse, having to redesign my Game Engine).

I'm designing it so it will not suffer from the problem of "tunelling", a frequent problem in game collision detection/response in which fast moving objects will go through other ones, ignoring the collison. This is something that i don't see correctly handled in many games, even to this day, and since I don't want to have to worry with bugs occurring from things that I can avoid by designing against them, I will design with that in mind.
Also, it will feature basic dynamics, so that one can configure object's mass or bounciness, add some speed to them and they'll bounce around like nuts (no rotation though, yet).

I see recent game creation frameworks such as Unity also do this, and i see it as a quite useful feature for an engine of this kind.


On the other hand, I added a list on the side with the projects I plan on doing, which will be updated as I get into them, linking to posts about them, and will ultimately link to the game download.


To break the monotony of not actually making games, I started work on a side project about a game played by writing mathematical equations. I'll post it when it reaches "really fun" status (right now it's only "marginally interesting").

Playing around with cyberclay (a mimetic polyalloy)!

So I got the word (from TIGSource) that a cool freeware sculpting tool came out, Sculptris, by the same guy who made the coolest sound generator tool sfxr, and took some time off working in the "physics response" coding lab for the game engine, to give it a go. It's pretty cool, reminds me a bit of ZBrush's sculpting mode but has a few more interesting features (such as adding geometry where details is being added), is much easier to get into and do cool stuff, and all this for free!

Xml-style game loading

How are you gentlemen

After continuing the process of adding features to the Engine in order to allow the building and playing of a basic Pong game, i came to the point where i wanted to have the whole thing loaded from an external xml file.
So i've spent the past 2-3 weeks designing a way to parse xml files and load the appropriate objects into the game, which has been quite a challenge because

1. writing xml file parsers is kinda boring
2. took a bit of code refactoring (to allow incremental construction of an Object - define an empty game entity and add modules to it as they are read from the file)
3. adding the feature to inherit properties from an object (kinda like inheritance in object oriented design)

So after testing loading a few basic entities from the xml format and playing with configuring them in different ways from the xml file, i'm now beginning to add all the available tags to fully allow the definition of the game in xml format. More uncreative and repetitive code, but necessary to have great big fun with it later :)

May News Update

So here's the current state of affairs: the game engine has reached a point where there still is a lot missing from it, but some basic gameplay can be designed. So i've started to do some old-school basic games, and keep building the engine as the games require, and generalize from that (i think it's good practice to design around the necessary game requirements instead of over generalizing the engine, which tends to make it in a state of never being complete).

I've started with Pong, which interestingly has a few somewhat advanced features that some modern games don't even use, such as collision detection and dynamics (ball/paddle speed), and causes me to add stuff to the engine that i may have missed in design or underdesigned.

I hope to post these first efforts soon :)

It's rewarding to finally see (after some months of working on it) how easy the game engine allows to quickly come up with a game prototype, edit and change stuff, instead of always having to rewrite the game scratch. Also, as the engine design was broken into modules, it's fairly easy to pick up where i left off the past week (since i work on it mostly at nights, sometimes a week or so will go by without having time or energy to do coding)

Next up will be Tetris! Yay :)

First sketch of the title screen:


Screen cap of the current game main screen state of the game:

Actualização Noticiosa - News Update

Jump to English Version

Boas, pessoal! Aqui vão notícias sobre aquilo que tenho andado a fazer.

Tenho estado a trabalhar num "motor" de jogos, que me permitirá produzir vários jogos partindo de um programa comum, reduzindo o esforço de reimplementar tarefas comuns para cada jogo. O motor aproximar-se-á mais de um ambiente de desenvolvimento de jogos completo, e menos de uma "framework" em código sobre a qual se implementa mais código, procurando oferecer o maior número de funcionalidades possível para desenvolver qualquer jogo (para já, apenas baseado em "sprites", ou imagens 2D, não suportando ainda 3D real, mas permitirá uma série de truques para simulação 3D).
Resolvi seguir uma abordagem de uma ideia que me surgiu depois de ler este post ("Three Hundred Mechanics - #004 - Environment Tree"), quando tiver avançado mais o desenvolvimento explico o funcionamento interno do programa em maior pormenor. O código está a ser desenvolvido em C++, utilizando a biblioteca de jogos "Allegro", e outras para carregamento de formatos de imagem.

As principais funcionalidades que oferecerá serão:

• separação entre lógica de jogo e código, para configuração desta durante o curso do jogo ("run-time")
• definição de toda a estrutura de jogo a partir de uma estrutura hierárquica (armazenando o "jogo" num ficheiro com estrutura baseada em XML).
• características frequentes em jogos:
  
• gráficas
• definição de modelos visuais de jogo ("side-scroller", isométrica)
  
• efeitos gráficos ("scrolling", zoom)
  
• aceleração gráfica por hardware
  
• gráficos "raster" ou vectoriais
  
• definição de GUIs.
  
• Acções úteis na implementação de inteligência artificial (linha de visão, navegação baseada em percepção do ambiente)
• Modelos para detecção de colisão/física simples ou newtoniana.
  

Algumas destas funcionalidades estão já implementadas, outras estão em curso disso, e algumas estão ainda a ser pensadas. Mas quando estiver tudo, vai ser bastante porreiro, e vão sair daqui uns jogos interessantes :) alguns dos quais já tenho pensados há bastante tempo e têm de ser feitos!

Ocasionalmente trabalho em pixel-art, ou faço uns modelos 3D (tudo nos tempos livres, o emprego não permite mais). Aqui estão algumas das coisas que posso mostrar (cliquem para ver ao pormenor):




(english version)
Hey guys! Some news on stuff i've been busy with.

I've been working on a "game engine", which will allow me to produce different games using a single program, reducing the effort of reimplementing tasks which are common between games. The engine will be more of a development enviroment than a code framework on which to further code upon, and will provide a large feature list, allowing to develop (almost) any sprite-based game (only 2D sprite-based for now, some 3D effects can be simulated, but "real" 3D isn't really in the plans right now).

The engine will follow a paradigm based on an idea that came to me after reading this post ("Three Hundred Mechanics - #004 - Environment Tree"), when development is further advanced i'll post more information on how it works. Right now, i've been coding in C++, using the Allegro game library, and several libs for image format handling.

The main engine features will be:

• separation between engine code and game logic, allowing logic configuration during game run-time
• definition of a full game using an hierarchy structure (storing the "game" on a XML language based file).
  
• frequently used game features:
  
• graphics:
• selection of the game's visual mode ("side-scroller", isometric)
  
• graphical effects ("scrolling", zoom)
  
• hardware acceleration
  
• "raster" or vectorial graphics
  
• GUI construction support
  
• Useful agent actions for Artificial Intelligence implementation (line of sight, environment based navigation)
• Collision Detection/Physics: simple or advanced (newtonian) models.
  

Some of these features are already implemented, others will be later, some requiring further thinking, but when it's done, it'll be pretty neat, and some interesting games will come out of it :) (some of which have been planned for quite some time, and must be done!)

Occasionally i'll do some pixel-art or 3D models for fun, all in spare time (my job allowing). Here are some incomplete 3D stuff i've been working on, click for bigger size: