The Struggle is Real

CSC490

This long journey has come to an end but the lessons learned well last. During the past week I had the chance to struggle on working the Level Manager Menu. This was to be a menu in which there was a map of the "galaxy". It would display all the worlds and you can explore the "galaxy" using the mouse. You can only start at the initial planet and once that level had been completed you can move to the next world. From earlier experiences I decided that simplicity is the best model. I based the idea of the map off Donkey Kong Country.



All the planets except the initial one would look dead. Upon successfully completing the mission on that planet it would change from a dead world to a more lively looking glowing world. The player could also see how well they did on a three star rating system. All of this was meant to be hooked up later to the rest of the game. Unfortunately we never had a enough time to do this. I also took time to create some art for the main menu. Again, due to time we didn't have time to put it in.
 

I took great satisfaction in making all of this but it took a great deal of work, learning and persistence. I must admit, it's not easy making something, anything in Unity for the first time. It gets frustrating at times. Sometimes things fail, but patience is a virtue that I feel I have learned as well as gained through this experience. I feel like initially there is this phase of frustration and confusion. Then eventually some momentum starts building up as more and more successful additions are made. So looking back it, the process that I enjoyed the most because when something does work well, it feels really good.

Final

Final Report:
https://www.dropbox.com/s/hajcr8sqm2jdhnh/PostmortemReport.pdf?dl=0

Final Game:
https://www.dropbox.com/s/3mofs4gnwj30pjq/Final%20Game.rar?dl=0

Final(Finally There)

Fortunately and unfortunately our journey has  come to end .Fortunately , because it was a big pleasure taking this courses,  prior to which I  had zero background on game development. Unfortunately, because the class has come to end , which means no funny Tuesdays , testing your game with teammates and with other people anymore. Throughout the course I learned an important things of game development , which is not only about writing game , but also working in a team , setting goal  and achieving  your targets  slowly but surely. Worth noting that my skills on making a game got improved as well. Constant searching for various solution of problems, associated with Unity (game platform on which our game was based on) and C# language helped me to gain huge amount of knowledge in these fields. Now lets shortly go through this 2 month journey and talk what I managed to finishing , what I tried and what I failed on. This , are mostly things that I did not talk in my previous blogs and also final paragraph includes what I did in the final week.

First two weeks were mostly spend on learning Unity and C# language itself and gathering with team and making plans of the project. A  few enhancement on Ui were added  to the game 2d Roguelike  such as making enemies to look in 3d format and attempt made on improving ui on health ended up with epic fail.

Further weeks, some times were  working on AI of player.  At first we considered using A* algorithm  using which enemies would be able to catch a player.  A* algorithm required  three classes  such as Priority Queue , Node class and GridManager. The node class would have handled each tile object in our Grid,representing the maps. A priority Queue class was meant for handling of the nodes,arrayList easier.A Grid Manager was used to manage all the properties of the grid representing the map. Finally , the main class Astar was created that would utilize previously mentioned classes.

Skipping weeks in between , I would finally move to what I worked on for the last week. The inventory class, was created , the player would have items that he could consume and  pick up from the floor. The inventory class would toggle with button I , that is every time user  would click it , it would appear. Inventory class had three buttons, which would classify items according to usability, weapon and all items together. Now the only problem we encountered was connecting it with health bar and other UI buttons of the player.Since ,the inventory was a day before presentation , we did not wanna take a risk of crashing game. So for the final presentation Inventory  of player would possibly be absent.

Final push

In the past week I did a bunch of cosmetic changes.

I added damage visualization. Each time a monster or a player attacks a number appears over the target showing how much damage the target took. The number shows up right over top of the target and slowly moved up over the course of 2 seconds. After that the number disappears.

To go with the last change I also added a "health bar" over all the monsters. The health bar shows "current health / max health". This lets the player keep track of the damaged monsters.

If the player escapes the world without completing the objectives the monsters health starts to increase. The monsters health increases by 10% increments.

I also fixed minor bugs and issues. The player path was highlighting at the start of the turn but now when a player would use an action point. So changes were made to toggle the path on each action point spent. This was clashing with pass button functionality. The tile under the player would toggle on and off when passing turns. If you pass turns quick enough you could see the action points GUI go down in to negative numbers.

Over all a lot of time went in to debugging and testing the existing functionality.

One last step left to get there

Finally finished creating  Inventory for user, inventory contains 4 items , sword, armor, and two bows one for increasing users life the other probably for increasing his action point , still on havent decided on that one.It is night before , final presentation and we are looking forward to finish last minor fixes that we had left from previous week.

Objective Complete (?)

It's been a little over two months since we've started working on this game.

I have added objectives added to the game and they were played in the testing session last week, along with another group member adding AI for the enemies. The game is challenging now, and almost complete. I still need to round out the UI for the game and different world types.

So while objectives in the game are complete, the list of objectives I need to do still goes on.

Almost there ..

Inventory class if finished. We can now store items there .Items are stackable and they don't overlap.There are still small things need to be fixed , however  main goal is to make items consumable and be helpful for player in defiting enemy. Overall  there are 4 items  for enough in inventory .We are thinking about adding more.Right now items are equipment type and usables. Usable help to increase life and action movement of player .Equipment will help in giving more attack power and armor for protection.

Second Play Test

Check the Game out... More features...

https://www.dropbox.com/s/kfvjokqp59y5ex6/Last%20Game%20Test.rar?dl=0

Summary of past few weeks

I'll describe what I have done in the past few weeks working backwards :)

Past week I have been working on creating a "smarter" AI for the monsters. Currently they are randomly selecting one of the available movement direction. Even if a player is right next to the monster there is a good chance it will walk away from the player instead of attacking. So I worked on creating an AI that will start chasing and attacking the player once the player enters a specific area around the monster. If the player runs away form the monster, aka moves out of the chasing area, the monster will stop chasing the player. In the begging of this week I modified the UI code such that it works on all screen resolutions. The UI code was mode with a static UI so depending what your screen resolution it would render differently, so I made it consistent by using screen percentages.

A week before that I added a mini-map by putting another camera that follows the player, but looks at the player from top down. Added a place holder for the player health. Added a basic AI that allowed the monsters to walk around one square at the time and occasionally attack the player. The AI was straight forward but I need to make sure that all the monsters get to move and get animated. The basic AI was described previously in the blog. Because of AI the game now also has the devision of player and monster turns.

A week before simplified some of the existing code and did bug testing. Made the monsters smaller, so they fit one square simplifying the code for now. Made it possible for the player to kill a monster in one hit. The player was hitting for such a high number that all monsters would die in one hit. Changed the code that was changing the highlighting of the tiles, made sure that the the tiles don't get modified all the time.

A week before that, Added the code for player movement. Hocked up the animations to the player. Made sure the movement is reflected correctly both in UI (player model moving to the correct location visually) and movement was correctly tracked on the board that keeps track of all the tiles on the board an their population. Also fixed the bug with wrong addresses being considered valid.

This is a quick summary of the major changes in the past few weeks.

Adding Scenery Objects and UI -- Late Blog Post 3

The following week after I learned the basics of Blender (the 3D Modeling tool, that is), I started making scenery objects within our game. The code for scenery objects is similar to enemies, only these objects don't need to move. To make them fully destructible they needed to have a health bar and the player has to be able to attack them. Everything was going great until I came across a big issue.

Once scenery objects are on the board, how can I click on the tiles behind them? Or better yet, what if the player is behind scenery objects? Or Enemies? Or Tiles? I needed to find a way to make the trees and rocks I was creating "invisible" to the player when she/he hovers over them to keep normal gameplay intact.

The trick was using Unity colliders for the scenery objects. Colliders register the mouse hovering over them. Incorporating that knowledge with my idea of transparent scenery, I could turn the scenery objects invisible by altering their material. The problem that came with this was a Collider also blocks the mouse from clicking on anything behind the Collider; I could not click a tile behind a scenery object because the scenery's collider was stealing the mouse input away from the tiles behind it. I had to turn the collider off in order to access the tiles behind, but then that made the tree reappear because the mouse was no longer hovering over the collider! The result, as one could imagine, was a strobe effect of scenery objects (appear, disappear, appear, etc). The flashing was happening 60 times per second! It was a bug that needed to be fixed quickly.

The temporary solution was to buffer the times the scenery objects would appear, disappear and reappear again so as not to have it flashing like crazy.

User Interface (UI) was desperately needed after our first play testing session (one of the major terms of feedback we got). I had enough time this week to also create the simple UI we have now. It still needs work, but for now it shows the health of the player, the action bar, and the start of our objective tracker.

Making Tiles Look Less Plain -- Late Blog Post 2

    Now that I had level generation "working" (I use that term lightly, since I am sure it really isn't), the levels started to look empty. Everything was flat shiny tiles and there was nothing to do (we had enemies, but at this point they just stood there and didn't move). While someone else made the enemies come to life, I looked into making the levels a bit more populated, but with scenery.
    The tiles themselves were just plain Unity Materials, so I thought about adding sprites to the top of the tiles to try and make them appear like Grass, Dirt, Sand and Water respectively.

    I drew some grass and stuck it on the Grass tile and the result kind of worked. I needed to keep consistent with the rest of the tiles, so I came up with some other drawing to place on the tiles while I tweaked the level generation code some more.
    Since I had no idea how to use Blender (the free 3D Modeling tool, not the appliance -- I definitely know how to use the appliance!) and another of our group members was creating our enemy and player models), I took some of this week's time to teach myself a few of the basics of making objects using the program. Not much progress this week, but at least the tiles aren't plain looking.

Perturbed about Virterbi -- Late Blog Post 1

    The week after I posted "Dealing with Randomness", our prof brought with her a guest who is working in artificial intelligence with the downtown prof. In the hopes of finding a solution to the level generation problem, I and another group member asked if there was anything we could do to solve our issue.
"This sounds like a Markov Model," was the reply.
    I didn't know what she meant by that, other than it had something to do with artificial intelligence (I later discovered it would be covered in a course I was not taking). So I had to go search on the topic online, hoping I would find the cure-all to our problem.
     After researching for a full day on Markov Models, I finally found something similar enough to our problem to work with. From what I gathered a Markov Model usually deals with determining the next state of something from the state it is right now and not from the states it was before. Upon looking at the algorithms I knew I would be beat; using linear algebra to calculate something I thought would be as simple as tiles just added to my headaches.
    The models did not seem to have any correlation to what I had in mind for level generation until I found out about Hidden Markov Models (they really were hidden from me for a while!). One Hidden Markov Model is called the Virterbi Decoding Algorithm (VDA). VDA doesn't know or assume the actual state of something, it instead relies on the previous sequence of states the something had to calculate the most likely state it should be in now. That seemed more on the lines of determining which tile should be placed beside which! The challenge now was to translate the VDA formula into code I could use to make the level generation.
    It took the remainder of the week to learn from YouTube videos VDA and write similar code needed to do the job of level generation for our game (though it is not perfect by any means). All I have to do now is tweak a few variables and I could make a water level, a mountain/grass land, etc.

    The code eventually came down to four percentages, based off the four tiles that make up each level. If I wanted more Grass, for example, I would increase the Grass percentage and the map would shape differently. It isn't perfect, and the results are not always as expected, but that is the way with randomness, right?

This weeks report : https://docs.google.com/document/d/1d4VkZoqh-7yqSm6Yjd5iEm0A-44Nn61JWLAuVyUzQGY/edit?usp=sharing

This weeks game demo: https://www.dropbox.com/s/3i9yh51su05fm3n/SolarLockdownDEMO.rar?dl=0

Getting There

So far finished Astar algorithm ,got priority queues,.Finished inventory class, now fill start working on items to add to that inventory

People versus dinosaurs? Preposterous!

After some team deliberation, we decided it would be best to change our character. A person fighting a dinosaur has been done before, *cough* Mario *cough*, but we thought it would strange to have a person fight a T-Rex. We decided on making the player character a mechanical robot, the size of a T-Rex. The mechanical robot is piloted by a person that has a high tolerance to the virus plaguing Earth, called a "Junker".

So this week I created a mechanical robot from a tutorial I found on youtube

https://www.youtube.com/watch?v=_trnU-KTkqg

However I added a few things to the robot from the tutorial like arms, a sword, and a shield.

This is the mech so far, however expect changes to be made. :)

DEMO PLAY!

Today we are doing a play test :) Come play Alpha 2.0

Download the game : https://www.dropbox.com/s/3i9yh51su05fm3n/SolarLockdownDEMO.rar?dl=0

Short Survey : http://goo.gl/forms/EbUjNhlXNq

Playable Release And Video

Alpha 1.0.0

You can play the game here: https://www.dropbox.com/s/69p1gfynacbdtgw/G3AD.rar?dl=0

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