One Game Per Day – Day 3

It seems you’ve done well in yesterday’s game! You now have enough money to start your own company and manage a swarm of mech instead of driving one yourself. This might seems boring to some, but who doesn’t want to be rich? Lots of job ahead, get to it!

Day 3 – DigDeepInc

Buy and upgrade your robots to send the mining.   Don't mine at night, it's forbidden by the law. Ready to make some money ?

Buy and upgrade your robots to send the mining. Don’t mine at night, it’s forbidden by the law. Ready to make some money ?

Play DigDeepInc!! – WebPlayer

*(Game use a 1066*600 pixel size(16:9) webplayer)

Idea :

The idea for this game is to make a Tycoon game that heavily rely on the interface. It is some kind of spin-off of Day2’s game, DigDeep.

How I did it :

This game has been hard to start because I had trouble nailing the design I wanted to go for. I started by implementing a basic UI and starting to work on the time mechanic and it became a core system of the game. The game has 3 speed + a pause system. The game time is based around minute going from 0-1440 each day. The minute is displayed as standard hour(5h43) for the player. When the speed is changed, the real-life second needed to pass 1 game minute is diminished(currently 1sec=1min at Speed 1 and 0.0075sec= 1min at Speed3).

Every frame update, the time elapsed since last update is compared to the time needed for each in-game minute.  At low speed, many frame are needed for 1 minute and everything is pretty simple. However, when going at high time rate, a in-game minute take less time than a frame update. The amount of minute to be spent on the particular frame is calculated and  each minute are triggered one by one to test for event(Such as illegal mining at night) and give player money if its Mech are mining.

The rest is basically a lot of UI desig which always takes me a lot of time.

Lesson learned :

  • This game was highly UI driven and I greatly improved my workflow between Unity2D and NGUI. I tried to focus on making a clean project with a robust relation between the code and UI so it is easily scalable afterward.
  • It has been my first attempt at making a UI from a spritesheet taken on internet instead of simple buttons. This is somewhere where I can see my workflow improve. I’m still looking for the best way to take a spritesheet and make all sprite available. Unity2D sprite editor can be a quick way to do it but I can’t find a way to put each sprite in an NGUI Atlas afterward. I’ll keep looking into that.
  • I was having some problem getting a nice interface that would scale well with different size. I decided to make it pixel perfect and fix the size in the WebPlayer. Trying different solution for this gave me a good idea of NGUI’s option for scaling of the interface.

What’s Left :

The basic mechanic are there but the game would need more content to be interesting. Random event would also give a less monotonous gaming experience for the player. Rapid-prototyping also means more shortcuts and hardcoded value. Making the game to a more data-driven state would make it more scalable and easier to maintain.

There are currently no research available and the land size has no impact. The objective is to force the player in maintaining a good ratio between area and Mech forcing him to buy one or another he has too much of the other.

Conclusion :

The conclusion for this project is simple to me. UI takes a lot of time. I’m not sure if there are secret way to easily make good and robust UI but I would like to know them! Until then, I’ll keep trying different ways of building my UIs until I feel I’m really comfortable with it. I usually put most of the UI code in the same script. This time, I spread it around and let different script drive different part of the UI. It went well, but it’d be interested to see how well it scales.

This game looks really interesting to me. I like tycoons and I see many ways to improve it. I’ll definitely get back at it eventually!

Dungeon Grind – Quest and NGUI

With the basic mechanics implemented in the game, I realized player wouldn’t really know what to do when entering the game. I decided to update the Quest system to give user goals. I refactored a lot of code to improve the quest system and  I am really happy with the result. The quest mechanic will be much easier to maintain and scale. This also allowed me to try NGUI  by implementing an icon representing the state of a mission over the head of an NPC.

Three states of NPC from start to finish of a quest.

NPC – New Quest, Pending Quest, Quest Finished

This mechanic will be used for the main quest line. There are currently 5 quest that require tasks in the camp and in the dungeon. There are also secondary missions that can be obtained from different source and are completed automatically upon reaching the requirements.

Confident from my previous success with NGUI, I started to implement it for the in-game menu. It took me a while to get used to NGUI workflow and find a menu implementation I liked while maintaining my ancient GUI for testing purpose, but it works well now. Once all menu will be implement with NGUI, I’ll remove all the ancient interface that rely on OnGUI.

Here are examples of interface updated from OnGUI to NGUI. :

Comparaison of starting menu

New Game : OnGUI (Left) + NGUI (Right)

Comparaison of Skil List

Skill List : OnGUI (Left) + NGUI (Right)

Comparison of Mission Log

Mission Log : OnGUI (Left) + NGUI (Right)

Lastly, I implemented GameAnalytics in my game. This asset makes it easy to receive information from players trying the games out. I’m still figuring which data I want to receive and when, but I’m currently using this to receive an event everytime a quest is unlocked and finished. This will allow me to see when the player stop doing the quest. I also set it to send a lot of information when a game is Saved. I receive the number of monster killed for each monster type, the level of skills and number of building created. Once I’ll have a better setup and received more information, I’ll share more information on the devblog.