Models and Animations!

With the Alpha release of Solar Lockdown coming up, the character model needed to be finished and rigged for animation. Since the player just needed to look like a person, I just needed to make a stick figure. This wasn't too hard. Although when I was applying the armature to the mesh, the player's limbs kept getting twisted. The player looked very morbid. After untwisting the player's limbs, The player still looked odd, but everything was working. I wanted to upload the player so Alex S could add them to unity, so I finished off the walking and turning animations. They aren't as smooth as the T-Rex's animations but it will do for now. I'll redo both player animations later.

Stick figure player

I want to finish another enemy character by tomorrow night. Right now I'm working on a triceratops, and I hope to be finished the model by tomorrow evening. Making the head is a lot harder than I thought, especially compared to the T-Rex who's is like a giant oval. The triceratops' body looks simpler but regardless, I definitely have some work to do.

Triceratops model

Dealing with Randomness

It's hard for anyone to wrap their minds around the idea in the first place, let alone capture the essence of it for a video game.

Due to the "Rogue-Like" genre of our game, it feels appropriate that one of the challenges faced by the player should be traversing terrain that always is semi-familiar yet never the same. This is usually done by what they call "procedurally generated level design". This is a fancy term to state each level is created by an algorithm, which pieces together prefabricated rooms in an order that appears to be random. For some unknown reason I have tasked myself with creating the level generation for our game. It is a daunting task, especially when one's experience with Unity3D's Engine is limited and time constraints have it due in a week's time (well, at least the basic level design anyway).

Searching online on this topic yields many different answers, and almost all of those lead to more questions. Depending on what one wants to do with the level generation, randomness always seems to be at play. Our group ended up deciding on making our levels tile-based. It is basically placing tiles (or in Unity3D, cube game objects) in a grid side by side to make a board the player moves on.

For example, a level grid could look like this, where x = tile:
  x, x, x
  x, x, x
  x, x, x

I found a starting point for level generation on the Unity website, under the learning archives (for those interested, the link is here: http://unity3d.com/learn/tutorials/modules/intermedia/live-training-archive/2d-dungeon-generation). To summarize the video briefly, there are rooms and corridors, which start near the middle of a grid. An initial room is set, and a corridor is made off of it in a -- you guessed it -- random direction. At the end of the corridor another room is made, and the process continues until all rooms are made.

Sounds simple, right? But as with simplicity, the idea to make things more complex quickly takes over, and soon the simple becomes the complex and the complex becomes a headache.

My head still hurts trying to understand what I made "work".

From the tutorial, the basic level generation was done, and it made some interesting results. In addition to altering room and corridor sizes, I began modifying the code to make the tiles of each room random. It made quite a spotted mess of pixels in Unity3D's scene view. I needed a way to make things look neater. This is where tiles came into play once again.

I've been messing around with tiles ever since. Which tiles can be placed beside other tiles, 2x2 tiles and 4x4 tiles stuck together, tiles with properties that the player cannot step on, etc. I have made progress, but not as much as I should when other issues need attention and the deadline is around the corner.

Moral of the story?

Don't deal with randomness outright. It's too... random. In addition don't make things so complex when dealing with randomness. Not only is it difficult to implement well, it takes a lot of time to sit down and plan how it will work even remotely reasonably. That being said, I am time restricted and I tend to over-complicate things.

I'm sure, with time, my headaches on this topic will subside. I will probably attempt another go at the level generation somewhere down the line, but as of right now the time constraints on this project's completion keep me moving forward. This blog post is not to discourage people from trying to work with randomness. It hasn't beaten me yet either. I just need a break from it by working on something else.

Week 1, Back to Basics

This blog is here to document the struggle of creating a game for a fourth year university course. We are using Unity to create a Rogue-like/RPG game. Last week we needed to present a proof of concept game...

For our proof of concept game we used an online tutorial as the base code. The idea was that both games are "Rogue-Like" so base functionality will be similar, and it would be much easier to add on top of the pre-made scaffolding... After a week of coding for the proof of concept, it has brought about a lot of changes to how the game looks.  But actual game play was not changed in the "proof of concept" scope...

A new week is a new challenge. This week we believed we would be able to do bring forward lots of new and exciting features... Turns out we were limited by the original scaffolding.  Instead of making new things we went back to basics. With a help of a white board and a pack of markers we were able to come up with a Object oriented design.

Trying to salvage the current code didn't work out too well. So we decided to remake the whole thing... (We were glad to see that majority of the custom code we added was easily portable. Silver lining) 12 Classes later (a bit over 1000 lines of code) we have the scaffolding which will be able to support the whole game. (We think...)

Looking forward to the next week being as productive as this one :) Keep the ball rolling!

Thx for reading