The Other Sky Alpha – Technical Reflection

26581-shot1

You can play my jam entry for Ludum Dare 30 here: The Other Sky

This game was a semi-ambitious idea, but I generally enjoyed developing it. One of the most important things to implement was for the first person controller to be able to support flipped gravity.

I tried to get this working with Unity’s CharacterController, but it wouldn’t be feasible for my purposes. Unity’s CharacterController only works best assuming gravity is always pointing down (with respect to the scene’s world coordinates). When gravity flipped upside down, the CharacterController would not consider itself grounded, even if it landed on a flat plain.

To remedy this and other problems with gravity, I looked for a custom alternative to CharacterController. I found something on Unity’s community called RigidbodyFPSWalker, which acted like a character controller but had Rigidbody properties. The fact that this script didn’t require Unity’s CharacterController allowed me to customize the behavior of things like gravity more easily.

RigidbodyFPSWalker does not support the flipping of gravity automatically. I don’t know of anything out there that does. So I implemented the gravity flipping functionality myself by modifying RigidbodyFPSWalker.

Unfortunately, I spent so much time implementing and tweaking gravity-flipping that I was not able to have too much time making interesting levels for the game. If I continue making this game, I will definitely make interesting puzzles and make gravity flipping a very important mechanic.

Advertisement

My experience making a game with SFML

HedronSpace_Screen2

For three weeks, I was doing C++ game programming to further increase my skills. This resulted in the game I call HedronSpace. My first time making a game in C++ was BlockDodger, but there were a few challenges with the engine code. BlockDodger used SDL for the low-level application code and it was very tricky to find a way to get audio to play and to get HUD-style font drawing to work out of the box.

That was one of the reasons why I made this new game in SFML. SFML offers an easy-to-use and object-oriented interface to make desktop applications. However, not everything was a walk in the park. SFML uses OpenGL for its low level graphics needs, but only offers a user-friendly interface to create application with 2D graphics. Fortunately, you can make 3D applications with SFML, but you’ll be mostly on your own.

That prompted me to make a little engine (I use that term loosely here) that wraps around SFML and offers easy to use 3D functionality for games (but only for simple abstract games). It’s called SF3DEW (which stands for SFML 3D Engine Wrapper) and took up most my 3 weeks doing C++ game programming.

Continue reading

BlockDodger – My Second Ludum Dare Post-Mortem

Image 003

You can download BlockDodger for Windows on its Ludum Dare page, or watch a quick video showing the gameplay. It also open-source, so anyone can see the inner working on Github.

You are a green block that must dodge red blocks by either moving around or shooting blue bullets. You can only shoot one bullet at a time. The game goes on forever until you lose or quit.

The game is really simple because it was made in C++ using Visual Studios 2012 and OpenGL. Before the 28th Ludum Dare started, I was working on a graphics wrapper that was an object orientated enhancement to the OpenGL tutorials at open.gl. You can download the graphics wrapper in a zip file here.

The libraries I used for the graphics wrapper and the game include GLM (for vector and matrix math), GLEW (for OpenGL extensions), FreeImage (for loading texture files), and SDL 2 (for windowing and program management).

I’ll keep this brief. These are the things I am proud of with this game:

  • I made a GameObject system that makes it easier to create entities in the game with common properties like position and color. Each GameObject also has an Update and Draw routine, which are called by a GameObject Manager (called GameObjectCtrlr in code).
  • The graphics wrapper I mentioned earlier (in code it’s called GraphicsCtrlr). It makes using modern OpenGL functionality (OpenGL 3 or greater) much easier and a little more object oriented. The alternative was to have a bunch of procedural function calls but that would be infeasible for drawing multiple objects.
  • I made a little wrapper class to basic SDL functionality called ProgramCtrlr which really cleans up the main function.
  • Actual game logic gets a class of its own (called GameLogicCtrlr). The good thing about this is that it prevents another manager class such as GameObjectCtrlr or ProgramCtrlr from having too many responsibilities.
  • I also made a really simple collision detection algorithm that treats the blocks as spheres and uses the squared distance. Using the squared distance prevents the computer from using square root functions. Both of these features make collision detection relatively fast.
  • I learned a few tidbits about class design and a lot of intermediate C++ concepts while making this game. Concepts I dealt with include friends, static members, polymorphic storage of objects, statically allocated singletons, a user case for protected virtual destructors (they’re usually public), dynamic dispatching (using virtual functions), and other such concepts.

These were the things that gave me trouble:

  • My texture management isn’t the most versatile implementation, so I had to hack a temporary solution to choose different textures.
  • SDL’s event system is currently implemented in my code to process one event at a time. Because of this, the controls are very bad (you can only use one key at a time). I did not have time to find a solution.
  • I was encountering several access violations when iterating lists because of semicolons that were accidentally placed right after the for-loop header. (ex. for(...); {}) The compiler never gives a warning about this. Took a few hours to find out.
  • It took me forever to get my head around random numbers and time functions in C++. It limited my “level design”.
  • My current implementation for resetting the level involves too much cleanup.
  • An object pool would have been very useful for the red blocks, but I didn’t have time to implement or use one.
  • I should have implemented factories for GameObject, but didn’t have time to.

That about wraps up my experience in my second Ludum Dare jam. Thanks for reading.

**Update: I made a slightly better version of BlockDodger with better controls and interesting spawning pattern.  It’s avaliable on it Ludum Dare page, or download the zip directly.

Moved Yxi from GameSalad to Game Maker Studio

The choice for GameSalad to make a game might sound strange, since I’m a programmer student and GameSalad has no coding. The story behind that is a little long, but I’ll explain anyway:

On October 19, 2012, two people from Microsoft came to DePaul’s College of Computing to talk about app development for Windows 8. They setup a workshop for people to make a Window 8 compatible game using GameSalad. I think the choice for GameSalad has something to do with how it currently supports export for Windows 8.

Considering how simple (perhaps too simple) GameSalad is, I wanted to make a game that was also simple. Unfortunately, GameSalad wasn’t delivering what I wanted. It doesn’t support sophisticated logic, nor does it support a changeable sprite anchor point.

Long story short, I started a new project with Game Maker Studio and reproduced every feature that was in my Yxi prototype from GameSalad. I even added a nice debug display you can toggle (see the screenshot).

Yxi Prototype in Game Maker

Yxi Prototype in Game Maker