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.

Dungeon Grind – Update and a video!

I spent a lot of time working on Dungeon Grind this week. The main thing I added was the ability to save building you’ve created and to move or delete them afterward. The hammer is now the tool that allow to do this by right clicking. Also, it is now impossible to place a building if it is colliding. It will turn to red until it turn back green when it is in a free position. I also updated the quest from the Spartan in the village to fit with the previous updates.

The GUI in the current game is pretty ugly and doesn’t scale with window size. I tried to avoid spending much time on the GUI knowing I would eventually redo it with NGUI. Well I bought it from the asset store! I’ll make a total rework of the GUI that will scale with size and be much more efficient to use. I also have a better knowledge of what I want to be in my GUI, something I didn’t know when I started to work on it.

I also took some time to make a video to show the current state of the project. This will be useful to show feature and will be a good reference as the project evolve. Again, my video-editing skill are lacking and I am working on getting better result on the video. Consider that intro/texts are placeholder for now! Here is the video :

First try on a C++/OpenGL physic engine

Around 1 year ago, I spent a lot of time working on a basic OpenGL physic engine. This was my first experience with OpenGL  and I’ve learned a lot from it. The project was coded using Visual Studio 2012(C++) and Freeglut(OpenGL). The only external library used is for rendering text. All the physic has been coded by myself and all models/structure are procedurally created at run-time. This project isn’t updated anymore and still have bugs in its current state. The goal of this project was to learn OpenGL and prototype an engine.

Features : 

  • AABB collision detection for all boxes
  • Adjustable gravity
  • Interaction with moving platforms(Horizontal and Vertical)
  • Ability to shoot/drop boxes of different size/speed
  • Freeze the time, move around and start the time back to have a different point of view on something.

I figured video-editing would be a good skill to learn if I want to make trailers for game or video tutorial and gave it a shot with this project. Here is a video of my OpenGL engine:

*Note : This video was my first real experience with video-editing. Video quality should increases in the following videos.

To be implemented in next version

I’ve learned a lot working on this project and on the other project I’ve worked on since then. Here is a list of things I would make like to implement in a new version of this engine.

  • I would like to use a Test Driven Development approach to make it easier to maintain/scale the project. I’m considering using the Google C++ Testing Framework.
  • Use an entity/component system to have a better separation of the data and logic of an object.  I would be interested in using something like Artemis that already has 2 C++ port.
  • Implement or Find a library to use Quaternion instead of Euler angles to avoid any Gimbal Locking issues. Quaternion also easily allow smooth rotation between any starting/ending orientation by using Slerp. Quaternion workflow is really nice to use once you get the hang of it.
  • Change my integration method from Euler to a more precise integrator like Runge-Kutta4. This article from GafferOnGames(I would recommend reading all post from this blog to anyone interested in game development)  explain why Euler is an imprecise integrator and is a bad solution if you want to have a realist simulation.
  • Evaluate the best approach for Timestep management. The project currently use a completely variable time step that could lead to unwanted behavior in certain cases. Again, This Article from GafferOnGames is a really good resource for this question.
  • Use a more robust approach to collision detection and response to the collision. Use a vectorial approach that is completely independent from the gravity used. Gravity should become a vector to allow intensity as well as direction changes at runtime.
  • Evaluate the utilization of a bool for object that are grounded on something else for physic evaluation. It seems this would make some platform movement much easier.
  • Use a sleeping mechanism for objects that are not moving. This would greatly reduce the collision calculation.
  • When testing collision, use rough estimates to eliminate groups of object that are sure to not collide together, or far one from another.

This project was really interesting and I’ve learned a lot from the experience. Coding everything from the beginning (except for using C++/OpenGL)  is a different experience than using a featured rich engine like Unity3D.

Doing this gave me a better understanding of the way Triangles are rendered on the screen and the differents matrix used in graphical development, such as Model, Projection and Persepective matrics. This was also my first project featuring Procedural Generation and it got me really interested. I’ll try to push this aspect farther in my current game in development, Dungeon Grind.

Hope you enjoyed looking at the video and reading my thoughts on this project. I’ll make sure to post it on my blog if I make a second version of this OpenGL Physics Engine.