Just a little side project

Here's something I'm working on as a side project to Brian Storm.

As awesome as things like Hextech are, I'm afraid I don't have the 100$ to dish out for it so I'm building my own hex grid framework from scratch. Currently on the lookout for intuitive ways to access the grid's tiles through XY coordinates - there's got to be something more efficient than Bi-dimensional arrays.

Level workflow in Brian Storm

Here's how we're currently doing our Blender-Unity3D level design workflow for the Brian Storm project. This is a result of several experiments we've done and our experience with level design. We're open to suggestions and if you're trying it out yourself and have some doubts on how it's done, feel free to ask me.

This is meant to be short and isn't a Blender or Unity3D tutorial of any sort. Though I might go more in depth later if there's a demand for it.

Also, keep in mind none of these images contain final art and are mostly placeholders while we programmers are still figuring things out.

Here we go

First we make a level segment: some geometry for the player to see and some collision meshes.

The actual mesh we see and it's collision mesh, shown in wireframe

We make sure to add "_collision" to the collision meshs' name. I'll explain this in more detail later on.

_collision just means the mesh is just a collision and should not be rendered.

We then put both types of geometry into the same group. Usually we use the file's name for consistency's sake.

We then create a level.blend file which appends (links) the groups in the other files as building blocks to create the level.

Tip: if you hide a mesh in it's original file, it will stay hidden after you import it. Very useful if you don't want to see your collision meshes while previewing the level here.

Two LongCorridors making up a longer corridor

Now we just import level.blend directly on our Unity scenes and all the meshes linked in it are correctly presented in our level. However, we have no collision yet - adding it manually would be a lot of work for levels of even smaller sizes.

A custom script, extended from AssetPostprocessor checks if we're importing a "level" file. We then go through every GameObject that we imported and check if it's name contains "_collision" - in which case we remove it's renderer and create a mesh collider for it using it's own mesh.
Another option we have so far is "_canhide", which adds a box collider to the mesh and configures it in such a way that it can be hidden if it obstructs the player's view.

We then use the Unity3D editor to add waypoints (paths our characters follow during gameplay), along with other extras we didn't import from the blender file and we're set.

Voilà, a complete placeholder level

Issues

Here's some concerns we have with this method:

• Waypoints have to be setup after importing the level. We should find a way to automate this as it get's very annoying to update huge clusters of waypoints after even slight changes to level layout.
• The same is valid for enemies, player start position, checkpoints, lighting and other non-geometry objects
• Having the level split up in "blocks", each with their own collision meshes might make the game suffer performance wise.

Note: We disabled importing of animations for the level file, as unity has some issues with Default takes on Blender.

Post-Mortem: Space Vengeance

Here's the long awaited (cough cough) second of the quick post-mortems I promised way back.

The main menu. Nothing fancy here.

What was this game about?

Space Vengeance was mostly a silly excuse to do another video game for a college project. The true (academic-wise) purpose of this project was mostly to showcase our OpenGL skills. The name was our attempt at picking the most generic thing we could name our old-school space shooter. If I recall correctly I think we had a list of generic-sounding video game adjective (like retribution, vengeance, rebellion, etc) and we just added space before it.


Again, no artists to be found here so it looks like shit.

The ships actually rotated a bit when moving up and down.

What happened?

Well I'm sure any of you experienced programmers can imagine what happens if someone jumps into C++ and OpenGL rendering after previously making a game in flash. We spent most of our time trying to figure out "boring" things like why our ships weren't being drawn and why when they did so, they started flying sideways. It all went mostly fine tough and we kept to our schedule. We dropped some features like visually attaching "gun" modules to ships due to a mix of factors like our lack of 3D modelling skills and the .3ds importer we were using giving us enough problems as it was.

We gave up on the project after that class because it was too difficult to add new ships, levels, guns, etc, as everything had to be hardcoded and compiled and we didn't feel like our game would add anything to the genre.

How was it made?

• Plain old C++
• OpenGL for rendering, mostly
• SDL for input and sound
• lib3ds for importing 3D models
• freetype for font rendering (I think, it's been some time and I'm feeling lazy)

Step right up for the final boss. He's big. He's (not) scary.
 And he moves up and down menacingly.

What did we learn?

That we should probably learn how to create cool shaders one of these days.

That simple things can make the game more enjoyable. We noticed huge improvements in the fun factor once I made ships blink white after being hit.

The more steps it takes to do something, the more half-assed the result tends to be and the easier it is to find reasons to put it off or just give up. This happened during power up creation (weapons for instance, had to be hardcoded and required creation of bullets, particle effects, etc) and level creation (levels consisted of several instances of a "wave" class that had to be compiled to a binary file and read by the actual game later).

Post-mortem: Cosmic Hunk

 This will be the first of a series of quick post-mortems of all the games I've participated in so far.

 

What was this game about?

Cosmic hunk was a turn-based tactical game with rpg elements, which took quite a bit of inspiration from games such as Space Hulk. It was meant to have a storyline that followed the adventures of a small team of soldiers which had to cooperate in order to defeat an alien invasion of their warship. The soldiers were supposed to gain experience by accomplishing objectives and use these to develop their existing skills or unlock new ones.

An image of the "remake" before it was dropped.

What happened?

The original version was a college project but we later started a "remake" to make it more polished and fix the remaining issues. Development of the remake took so long we quickly lost all interest in the project and soon I found myself to be the only programmer, but more on that later.

How was it made?

Using Flash. More to the point, it was originally made for AIR. We were all quite new to the technology at that time.

What did we learn?

A lot!

Planning is important. We went in blind with what we thought was a simple concept but most things were not clearly defined: like how many characters, how the aliens would behave, etc - this resulted in a few arguments which made us waste a lot of time.

 An early gameplay shot. The text was meant to use a custom font,
which had to be installed. You can see a small glitch in the resizing of the
 pictures which only got fixed when the GUI was redone.

Don't overdo the planning! During the remake we had real life meetings to decide most concepts of the game: this turned out to be an amazing waste of time as some people in the team had no interest in things like the implementation of the sound engine. Soon we had a lot of people inexperienced in game design voting on things that wouldn't make the game any fun, non-programmers suggesting things that would make the programmers' jobs hard, and programmers deciding on features that would have made the artists' work a lot more complex.


Most importantly we learned the importance of keeping concepts simple. What seemed like an easy game concept we could use to learn Flash as we went, quickly turned into a bit of a nightmare as we struggled to meet our deadline. Some things, like the main menu, had to be reworked several times in order to function with new features we were adding. We should have started with just a small playable prototype and then added features on top instead of trying to implement them all at once.

  Another early gameplay shot. In this one you can see a recently
 spawned alien and the second soldier the player could control.

A funny story regarding the above paragraph: our "hit probability" and "damage" functions were based on a 3 dimensional mathematical function - we never found out if they worked as intended as they were just too complicated to even understand. 


Version control: we didn't use any sort of VCS at first. Yeah, huge mistake. Nothing too serious happened but it was an incredible hassle to keep the code coherent - not to mention most of the time only one person was able to code.


The original GUI was very annoying to use and relied on repeated clicking of arrow icons in order to move the soldier. As mention before, we hadn't planned it and just limited ourselves to making it up as we went along. In the remake we created a new "overlay" system that would not only let you move directly to a location, but also show contextual skills (like "use") only when they were needed.

 A briefing screen. The voice acting and dialogue
was incrediblycheesy but added a lot of fun to the game.

Artists are important! We still haven't fixed this in our future projects, but development of both versions of the game was severely stalled because we had no dedicated artists. As such, the programmers felt like there was no need to rush and development slowed down considerably even though the engine and design was progressing nicely. We had several artists throughout the story of this project but none of them produced consistent work or were interested in the game itself (or game development in general). Soon we found ourselves with more promising games ahead of us and decided it wasn't worth the hassle to keep looking for artwork.

Hello there

Welcome to my blog. This is where I'll hopefully start posting about my adventures in programming, design and just game development in general.