Posted by on September 25th, 2014

Zach, wizard coder, took some time off to write about the Integrated CEGUI for today’s Dev Blog. We want TUG to be completely moddable and that includes giving modders the ability to create their own UI. 

You may have noticed a phrase in the latest patch notes “Integrated CEGUI”. For those that do not know, CEGUI is an open source framework for user interface that we have decided to use so we can present modders with an easy way to make changes to TUG’s UI. In an upcoming patch we will be pushing out the beginnings of moddable UI. One of the reasons we picked CEGUI is because of it’s exposure to Lua, each CEGUI element can be created, modified and destroyed directly through CEGUI’s own Lua interface, which you can access in any TUG script. In addition to CEGUI’s Lua interface, I have also written some short Lua wrapper classes to help with some of the more abstract or mundane tasks. If you’re a programmer, that means you can create your own custom UI elements and tie them to just about anything you have script access to. For those that are more interested in the art side of things, we haven’t forgotten about you. CEGUI comes with it’s own layout editor and we were careful to maintain its functionality during the integration process.


In the above image you can see TUG’s Survival UI layout in CEGUI’s editor. With this tool you can rearrange the UI elements to be anywhere on the canvas, and those changes will be reflected the next time you run TUG. But what if you want to make your own art? CEGUI has that covered too.


CEGUI’s editor also lets you modify imagesets, their name for a texture atlas. Using this tool you can load a .png that you created using your software and section it for easy access to your own UI images.

In both cases, layouts and imagesets, you are free to alter the assets that come with TUG or, if you’re feeling adveturous, create your own. At this time, the UI framework is only partially complete, so while we continue making modifications, there may be some UI elements that are locked from modification, including the Bag, Beltbar, and Equipped item slot. These elements will become available as soon as I can finish writing and testing the new inventory system.


This is just the first step in the UI overhaul, hopefully with much more to follow, including tutorials on best practices and how to get the most out of CEGUI via Lua script.

If you have any questions, feel free to contact me on twitter @Zachisalsoking

Posted by on June 26th, 2014

Hello there! It’s-a me Auti0, Programming Lead at Nerd Kingdom, again. Last time I discussed a brief overview of our modding systems and how they will play a role in TUG in the future. I’d like to talk about something a bit different this time. Leading a programming team in game development or Programming Programmers.

At Nerd Kingdom, we are still a small indie studio with less than 30 people. 7 of which are programmers(including myself). Although the programming team is “small”, it isn’t without its challenges. It is a constant juggling act of many responsibilities, including but not limited to…

  • scheduling and keeping track of everyone’s tasks

  • ensuring code quality

  • frequent meeting with other teams

  • commenting on forums

  • understanding and meeting requirements for features and tools

  • creating shippable builds

  • explaining the why’s and why not’s of the tech to other teams

  • planning infrastructure for future features and tech

  • balancing the desire to perfect tech and working on fun features

  • understanding and utilizing each individual programmer’s talents

  • testing features

  • vetting, hiring, and training new programmers

And among all this, trying to find time for myself to actually code. These are just some of the responsibilities that I have to deal with on a daily basis.

One of the critical points in any project, which games are not exempt from, is timelines. Being able to accurately create timelines is an invaluable tool. In the real world though, this is one of the hardest things to do. When building an engine and game simultaneously, there are just a ridiculous amount of variables that come into play. Although I could make excuses all day, the truth is it still falls on the lead programmer to make sure our timelines are as accurate as possible and we do everything we can to make sure they are met. A simple rule I learned from one of my old programming leads is to take your original estimate, multiply it by two, then add 3. It isn’t perfect, but it adds a good amount of padding for prototyping, feedback, refinement, testing, and cleanup.

A major strength/flaw of programmers is an unnatural desire to make everything perfect. At first glance, this seems like a good thing. We all want perfect, right? The issue is that is it easy to go down a rabbit hole of finding the cleanest, most efficient, most robust solution for even the simplest problem. We want to architect a beautiful system for the simplest of features. So part of the lead programmers job is to know where to draw the line and when to intervene to create a balance. It is important to find time for both building infrastructure and implementing actual gameplay features. Often you simply have to say something is “good enough” and move on. This doesn’t always sit well with some programmers, but it’s all part of the big picture of making a kick-ass game. After all a perfect engine with no game is no fun at all (unless you are into that kind of thing)!

Every programmer is unique. Some are very talented in a specific field, like rendering, while others are competent at most systems and can bounce around as needed. Learning each of your programmer’s skill sets is crucial in developing the project as efficiently as possible. This takes time and it isn’t always immediately apparent what an individual programmer’s true skill set is even if you have a general idea from the interview process. Besides their actual expertises it’s  important to know the two things about the programmer we discussed in the previous sections, estimating tasks and time management. Both of these are usually things that improve with experience.

One more thing you will have to deal with as a lead is interacting with other teams. This can mean interacting with them on a daily basis to make sure content is in line with tech development to managing expectations of features and tools that are coming online. You never know what your art director might throw at you that day so you always need to stay sharp and be ready to roll with the punches!

Leading a programming team is a ton of work. Some days can be a huge stress ball and all I want to do is go to a corner and code away, but overall I love my job and wouldn’t trade it for anything.

Thanks for reading again! I hope you got a better understanding about our programming team from this. I’m always down to answer questions so just shoot me a PM on the forums or twitter and I’d be happy to answer any further questions regarding being a lead, TUG, Nerd Kingdom, or the Games Industry all together.


Andrew Davis

Lead Programmer at Nerd Kingdom