Moved to New Site

Sorry for the long hiatus. I have officially moved to my new blog (jisyed.github.io), which is hosted on GitHub Pages and built with Jekyll.

The reason why I chose this method was because it allowed better customization of the blog (although harder to do now), and I can format the “content” however I want.

I will still keep this blog open, as long as WordPress.com continues to exist. I just won’t update here. I will also not reply to any further comments on any posts here.

You can reach me on Twitter as @Jishenaz or email me at jibranisyed@outlook.com.

The Other Sky Alpha – Technical Reflection

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.

How to correct scale and rotation of static Blender models for Unity

Lately I was learning how to use Blender to make 3D models (mostly because it’s polished and free). As a programmer, I wasn’t attempting to be a professional artists, but I did want to learn the basics in order to facilitate game development.

Blender is a pretty cool program if you learn the shortcuts and interface (I found a great tutorial here at “Games From Scratch”). However, if you want to use models made with Blender in Unity3D, the scale and orientation will be not be set in a way you would expect. This tutorial attempts to teach how to fix the scale and orientation of the Blender model so it shows up correctly in Unity.

Take note that this will be a manual orientation and scale fix. This doesn’t utilize scripts in either Unity or Blender. This tutorial assumes that you are at least a little familiar with navigating the interfaces of both programs (I consider myself a beginner in Blender, so hopefully Blender-beginners should be able to follow along). This tutorial uses Unity 4.5 and Blender 2.7.

My experience making a game with SFML

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.

BlockDodger – My Second Ludum Dare Post-Mortem

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.

Unity3D Camera Movement Revisited

>>Get the revised camera movement script with inertia from Github Gists<<

Some several months ago, I made a much visited tutorial about rotating, panning, and zooming a camera in Unity3d. I was asked if it was possible to make the camera movement more smooth. While I thought the movement was already smooth, no one can ignore the fact that if you let go of mouse when moving the camera, it will suddenly stop.

A more desired behavior is for the camera to smoothly stop after letting go of the mouse. In order for this to work, the camera needs to have some inertia, thus physics properties.

In the link above with the revised camera script, I implemented a version of camera movement that will stop smoothly. You can even control this smoothness from the pubic variables turnDrag, panDrag, and zoomDrag.

Internally, a RigidBody component would be required for this to work, but I made the script take care of that, so that you don’t have to. In other words, if you’re using this script on a camera, do NOT add a RigidBody component because the script will do that automatically.

Playing around with audio in Unity

When I was putting audio into 10 Seconds in 10 Seconds, I found it annoying that certain sounds would only play partially. This was happening because the sounds in question were being played by objects that existed for a very short amount of time.

When a GameObject gets destroyed, it’s AudioSource also gets destroyed. If that AudioSource was playing a sound, it will stop immediately when destroyed.

The usual solution to this problem would be to create a new GameObject just to play the sound you want and destroy it when done playing. There are a few problems with this solution:

1. It’s creating and deallocating objects too often, which can cause memory fragmentation.
2. From my experience, it’s not flexible because I could only get it to work if I made a different prefab for every sound to play.
3. Implementing sound effects in this matter might confuse other programmers who are expecting a call to play audio as opposed to a call to instantiate a prefab.

What I wanted to do in for audio playback in Unity was to play sounds in multiple channels in the same way an audio work station used mixer software to mix audio from multiple channels. The bad news: Unity does not give you this kind of control (directly anyway). The good news, Unity can mix audio together, as long as they are being played from multiple instances of AudioSource.

With this in mind, I wanted to make a mixer that can be called from anywhere to play sound to a specific channel. The idea is you can make a call to this audio mixer to play a sound in a specific channel and label the sound as a specific audio type. The audio types would include sound, music, jingle, and voice. I also wanted playback controls based on a specific channel, all channels, or channels label with a specific audio type.

After messing around for a few days, I would like to present the AudioMixer. It’s a Unity script that allows mixing of sound in multiple channels. This can be very useful for playing reoccurring  sounds, loop music, or other audio tasks.

You can read about the AudioMixer on the AudioMixer page, or you can go straight to Github and get it. Documentation and instructions on how to use AudioMixer are provided on Github.

The Motivation behind XboxCtrlrInput

The motivation to make XboxCtrlrInput came about from a problem I’ve encountered a few times in Unity3D.

It started with my team capstone project, Fortress Fiasco. One of the important features the team wanted to implement was local co-op play with multiple Xbox 360 controllers. I remember the programmer in our team who was implementing Xbox input was complaining about how awful Unity is about handling multiple joystick input. And he’s not the only one. I looked into his input code and realized that Unity was probably treating joystick input management as an afterthought. Of course I love using Unity, but I think Unity should improve the handling of multiple joysticks.

Flash forward to my Ludum Dare entry 10 Seconds In 10 Seconds, I wasn’t thinking about multiplayer at the beginning of its development. I did implement joystick input with an Xbox 360 controller, but my focus at the time was to make a single player game. Joystick input with just one joystick isn’t terribly hard with Unity. Towards the middle of development, I realized that it was possible to make a multiplayer version of the game because it became a top-down duel. I had to decide between either an AI opponent or a human-controlled second player. I didn’t have two Xbox controllers at the time so I chose to tackle with AI.

When I submitted my game on Ludum Dare, I got a lot of feedback saying that the game would be great with multiplayer, and I agree with them. Considering the control scheme of 10 Seconds In 10 Seconds, I thought using multiple Xbox controllers would be the best way to go, instead of having two players share the keyboard. Since I released a Mac, Windows, and Linux version of the game, it only made sense to me that a post-Ludum-Dare version of the game should continue to work on all those platforms with multiple Xbox controllers.

I know it sounds a little naïve, but I always figured that one of the goals of Unity was to allow people to develop games they can release on multiple platforms. Ideally everything should work on multiply platforms, including joystick input. It’s obviously not as simple as it sounds.

There are two major problems you have to face when implementing such a system. First, you have to get button mapping and axis mapping to “just work” on every operating system. For that, I won’t put much blame on Unity, since that’s a platform-dependent ordeal. But I will put much blame on Unity for the second problem: multiple joystick input support is lacking and difficult work with.

There appears to be a few attempts that exist out there on the internet to try to solve this problem, but none of them are perfect. Somebody with the domain name “uberdruck” showcased a web build that seems to be pretty good at handling multiple controllers, but uberdruck does not explain how the demo’s input system works. It’s only useful as an observation for what is possible. Deciduous Games made a C# input wrapper for Xbox controller input. It’s similar to XboxCtrlrInput in terms of being a static class, but the input mapping was implemented with Windows in mind, and thus will not work on other platforms without tweaking it. The last and most popular solution was a Github-hosted project called XInputDotNet, which is an XInput wrapper to allow XInput to work on .NET and Mono frameworks. This allows XInput to be used in Unity, which will allow for much better Xbox controller input. Only problem is that XInputDotNet relies on DirectX, so it will only work on Windows.

My goal with XboxCtrlrInput is to make a C# wrapper for Unity that makes it easy to get input from Xbox 360 controllers on multiple platforms (Mac/Windows/Linux). The included C# class XCI should be interfaced in the same way as Unity’s Input class. It sounds like a lot, but I’ve made fair progress. I invite anyone to contribute to the project on Github here. It’s free, open-source, and public domain, because I think Xbox controller input should “just work” with Unity. If you want to know the current issues about getting the input to work, be sure to take a look at XboxCtrlrInput’s Issues page on Github. If you don’t use Github, you can download a zip file containing the latest code from Github. Demo project included requires Unity 4.2 because I make use of text asset serialization (which became a free feature in version 4.2).

Game Maker: Gradually rotating an object towards a target

You can get the GML script here. This post will explain the code.

When I was developing enemies in Yxi, I was trying to get turrets to aim at you, but I didn’t want them  to possess “instant aim”. I wanted them to rotate towards you given a maximum rotation speed. If you move too fast, it should turn towards you gradually, not instantly.

It seems that it wasn’t as simple as I thought it was. I had the basic algorithm down, but because of the way Game Maker handled angles, the turrets would behave strangely when you would hover around the 0°/360° point with respect to the turret.

I figured a tutorial would be necessary for something that isn’t so obvious to implement. This only pertains to Game Maker and thus uses the GML language.

There are three steps involved when gradually rotating an object (let’s call it a turret for now) towards a target object:

1. Calculate the target’s direction with respect to the turret’s position.
2. Calculate the angle difference between the direction derived from step 1 (let’s call “target direction”) and the turret’s facing direction.
3. Apply angular rotation towards the target so that the target direction is the facing direction.

Yxi – Alpha Demo Video

Here’s my progress on Yxi so far. I lot of work has gone into getting physics right and also making bosses with random parts.

As of yet there aren’t that many boss parts, but the system will randomly choose parts to build the boss. When the player blasts one of the arms, only that arm gets destroyed; the rest of the boss is still alive.

Other things this video demonstrates are how the player gets pushed back upon contact with the boss, how coins follow the player, what player death currently looks like, how shooting the main body will kill the whole boss, and how turrets slowly turn towards your direction.

Yes the graphics are very ugly, and the boss is currently boring. It’s a work in progress, so this will hopefully turn into something fun. 🙂