Jump to content

  • Log In with Google      Sign In   
  • Create Account

Leadwerks Developer Blog

Merry Christmas, and a look at our new headquarters

Posted by , 23 December 2012 - - - - - - · 614 views

I hope everyone is having an awesome Christmas week. I'm taking a break from coding to show you our new office we moved into in November at the Sacramento Hacker Lab.

All decked out for Christmas:
Attached Image

Chris is pretending to work, but he's not fooling me:
Attached Image

So we changed the arrangement to make a reverse mullet. (Party in the front, business in the back):
Attached Image

The kitchen provides energy, both in the form of food and alcohol:
Attached Image

The common area:
Attached Image

The room-temperature beer flows freely:
Attached Image

A closeup of our lovely tree, topped with the stuffed figurine Intel gave us (they're one of the sponsors here):
Attached Image



Leadwerks 3 Progress

Posted by , 21 December 2012 - - - - - - · 632 views

Here's my list of things left to do:
  • Documentation
  • Undo system
  • Get character models for Darkness Awaits
  • Prepare the super secret special surprise for deployment

Undo functionality is my absolute least favorite thing to program, and I also want to get some more real-world testing done before implementing it, so it comes last. This evening I will start on the docs, in earnest.

I hope everyone is having a good near-Christmas week.


Import Model Scaling

Posted by , 19 December 2012 - - - - - - · 824 views
Import Model Scaling I got tired of rescaling some models every time I created a new instance of them in the Leadwerks 3 editor, so I added an option to resize the model file itself to the proper dimensions. Double-click the model thumbnail in the asset browser to open it in the model editor. Then select the Tools > Resize menu item. The Resize Model dialog will appear with options to scale by a percentage, or fit to a specific size. For convenience, you can choose the units to use, including centimeters, meters, inches, and feet. Press OK, then save the model, and you will never have to rescale it in the editor again.

You can also drag a material into the model editor and drop it on the surface you want to assign it to. When you resave the model, that material will be saved in the new model file. This makes it really simple to assign any pesky missing materials you might encounter when importing a new model.

Leadwerks 3 begins closed beta test

Posted by , 15 November 2012 - - - - - - · 887 views

Leadwerks 3 begins closed beta test Leadwerks 3 is a new game engine purpose-built for mobile. By building the entire platform on pure native code, Leadwerks aims to bring a new level of performance and flexibility to 3D mobile games.

After two years of development, the team is now beginning a closed beta test. Select members of the community will provide feedback and testing so that final bug fixes and refinements can be made.

You can sign up to our mailing list for up to date information as we finish up development of the new Leadwerks. Visit www.leadwerks.com to learn more.

On the Naming of Things

Posted by , 17 February 2012 - * * * * * · 924 views

The design of the Leadwerks website involves organizing a lot of different kinds of data that are continually growing, including forum posts, blog entries, gallery images, videos, and downloadable files.

All this information was organized in categories, and sub-categories, and in some cases, sub-sub-categories. The depth of categorization made it impossible to follow all the information that was flowing through the site, and users frequently posted in the wrong place. We recently underwent a restructuring of this information in an attempt to make all categorization only one level deep and streamline the viewer's experience. In this article, I will share with you some ideas I learned from this process that were not immediately evident to me.

Programming Forums
Originally, we had one main "Programming" forum for general programming discussion with several sub-forums which were meant to be used only for discussion of issues specific to each language, like compiling or editor problems. It didn't work out that way, and the community was fragmenting along programming language. Each group tended to participate in only the sub-forum of their language of choice, and I found myself answering the same questions repeatedly, for different languages. I don't know if this was related, but there was also a lot of territorialism among the various factions, with many arguments over which language should "win". Arguments occurred over which languages warranted their own forums. I also felt like the forum had grown beyond my ability to absorb, and had stopped reading the programming forums some time ago.

With the arrival of the tagging feature in our community software, I felt it was time to merge all the programming forums into one, using tags as a 'light' way to sub-categorize posts. I chose to leave the Lua "Script" forum separate for two reasons:
  • If we do an "indie" script-only version of Leadwerks3D in the future I want separate permissions for that forum.
  • To protect beginners from intimidating low-level programming discussions. Which isn't to say anyone using Lua is a beginner, but beginners tend to prefer script.
Although there was initial protest against this plan, I went ahead and closed the programming sub-forums for new discussion, without losing them just yet. I also made the Lua sub-forum a top-level forum and renamed it to "Script". My job is not about promoting other technology's brand names, and the user doesn't care much about the underlying technology, so I felt this was more appropriate than "Lua".

Other Forum Categories
We also had forum categories for sound, materials, modeling, and shaders. All of these sub-forums were merged into a single forum called "3D Artwork". Calling game sounds "3D artwork" may not be terribly accurate, but I'll get to that later.

Gallery and Videos
At the same time, I was working to simplify the entire contents of the Leadwerks website. Previously, we had gallery images and videos divided up by product. The gallery had four sections for Leadwerks Engine, 3D World Studio, our upcoming game development software Leadwerks3D, and a fourth category for miscellaneous pictures and photos. The videos section was also divided into three categories, by product.

I decided to merge all videos into a single category, and replaced the gallery with a custom implementation that simply displays all images in chronological order, with no attempt to categorize them.

Asset Store
The Leadwerks Asset Store too was broken up into many sub-categories. The code section was subdivided by programming language, and we had similar issues as we experienced with the programming forums. Although Java was not an officially supported language, there was a lot of material available for the language, so a sub-category was created for it. I felt odd having all these "brand names" scattered across the Leadwerks website.

We moved everything into a single "Code" category, using tags to specify what language a file was for.

Additionally, I implemented a community portal page which shows all recent forum posts, images, videos, status updates, blog entries, and asset store files. Items are displayed in chronological order, with no sub-categories.

Attached Image

The new face of the Leadwerks community.

The Result
The reorganization of the programming forums was the most drastic change, and I think the community has generally agreed the change was for the better. I am once again active in the programming forums, and it's easy to keep up with current discussions. I made the final change and merged all posts from the programming sub-forums into the main programming forum, then deleted the sub-forums.

The site overall is much easier to follow, especially the videos and gallery images. A chronological stream of recent items trumps sub-categorization, any day. Because there are fewer sub-sections to check on, it's much easier for me to keep up with the flow of content. Although I don't have any statistics to back this up, I feel like the community is more active now than before the change.

Choosing Titles
I have learned that slightly inaccurate and specific titles are better than encompassing but vague titles. For example, I removed the "Sound" forum and moved all posts into the "3D Artwork" forum. Is it accurate to include posts talking about video game sound and music in a forum that is mostly devoted to discussion of 3DS Max and Photoshop? Probably not exactly. Would it be better to call the forum "Game Assets"? You might be inclined to go with this suggestion, if you are an analytical type, but consider the following:

iTunes is Apple's online music store. It was originally built as a program to purchase and sync music for iOS devices. Movies were added to the program's features, and the title "iTunes" was no longer exactly accurate. Would it have been better for Apple to rename the application to "iMedia" like "Windows Media Player"? It would be more accurate, but no one would have any idea what it did. When apps were added to iOS, iTunes gained the ability to manage applications as well. Should the program be renamed to "iContent"? It's a more accurate description, but it's so vague it loses meaning.

Attached Image


The name "iTunes" is catchy, and it describes the main point of the program, even if it doesn't encompass all functionality of the program. This is a weird idea to me, because as a programmer, my inclination is always use a broader and broader term until I reach one that encompasses all characteristics of the thing it describes. However, I am certain that a catchy title that describes the main point of the thing it describes is superior. With this idea in mind, it makes perfect sense to include game sounds and music in a forum about 3D game artwork. It is exciting to me to learn something that is illogical but self-evident.

When you categorize things, choose fewer categories with descriptions that encompass most of what they contain. Never get too analytical about the categorization and naming of things. Instead, just go with what feels more natural and catchy, even if your nomenclature is slightly inaccurate.

We still have one big contradiction of this idea on our site, the use of the term "Asset Store". Leadwerks3D actually uses a class called "Asset" as a base class for textures, materials, shaders, and other objects, but about 40% of total files, and 100% of paid files in the store are 3D models. Additionally, the term "Asset" still isn't broad enough, because code files and games are not an extension of the Asset class. It would not be out of the question to rename the Leadwerks Asset Store to the "Leadwerks Model Store". The analytical (and much worse) extreme would be to call it the "Leadwerks Digital Goods Store".

Keep your titles short and catchy, and don't try to broaden them to encompass every aspect of the thing that they describe.

Why Small Companies Succeed

Posted by , 26 November 2011 - * * * * * · 1,400 views

The development of Leadwerks3D seemed like an impossible task at first. Not only did I need to write a new 3D engine entirely in C++ mostly by myself, but I had to make it run on four platforms (Android, iOS, Windows, and Mac), with a scalability all the way from the fixed-function pipeline up to the very latest hardware tessellation features. All logical sense told me this was impossible. Even large companies with 100 programmers or more haven't yet been able to put out a 3D engine with the range of platforms and scalability I am targeting. What makes me think I can do it?

As we approach the initial release of Leadwerks3D, what I thought was impossible seems much more feasible now. During the course of development of Leadwerks3D, I've learned some important ideas that give a lot of hope to me and to indie game developers everywhere.

Systemic Interdependence
When managing complex tasks there's something called systemic interdependence. This refers to the idea that when you have many people working on one project, they are rarely isolated from one another. They often have to stop and wait for another person's job to be done before they can continue with their own, and programmers often end up stepping on each other's toes when they work together.

Even though only Aria and I are working on the source right now, we have experienced this. It's very important we keep busy with separate aspects of the engine. Aria works on platform implementation issues, I work on the core engine design, and we try our best to keep the source code repository in sync. So far this works well for us, but I could easily see a lot of problems arising if we had more people working on parts of the engine that aren't so easily compartmentalized.

Think about your own game. What if I told you I was willing to give you as much money as you wanted to hire programmers, (as long as your final project gave me a big return on my money). Sound great, right? So you go out and hire ten programmers. They come in every weekday, 9 to 5. They're willing to work, but you have to instruct them and keep them busy and productive. Don't have anything for them to do at the moment while you finish one little part? Too bad, they're still on the clock and you still have to pay them.

With ten programmers, would your game get done ten times faster? Almost certainly not. In fact, as you add programmers, your work output will probably look something like the graph below. With one programmer, we have an output of 100 arbitrary units. We gain efficiency with the first few programmers, but the effect lessens with each additional worker. They have to wait for another person to finish something. Now the code repository is conflicted, and you have to figure out how who added what code. You also have an increasing number of relationships and communication between individuals.

Attached Image

Once we get past five programmers, additional programmers actually have a detrimental effect to our output. If we continue adding more workers, we can reach levels of output that are below even that of a single programmer. Imagine if 30 people were working on your game. It would be chaos, and that whole time you would be burning money as they came in every day. Meanwhile, your investors would be sitting impatiently, expecting you to get back a lot more money than they put in.

My chart above isn't precise, and the number of programmers a project can support will vary based on its ease of compartmentalization, but the overall idea stands: Software development does not scale very well with additional manpower. This is why small companies are continually springing up and outmaneuvering larger ones. Android came from a small company. It was bought by Google, but only after a small team had built the foundation. Minecraft came from a very small company. Kinect originally came from a small company. Small companies with focused goals are able to compete with much larger companies because of the effect of diminishing returns.

Performance and Motivation
Another problem big companies have is motivation. In a professional software development environment, managers like to have measurable performance metrics to evaluate employee efficiency. These are used for performance evaluations, and are the basis for salary increases, promotions, and disciplinary actions. Managers set goals and milestones that can be easily measured after a period of time. Workers respond to this by doing exactly what management tells them because they get rewarded for it. If a worker has an idea for a new technique that might or might not work, they're not as likely to spend time on it in this environment. If it works, the company gets to keep their idea and they get nothing. If it fails, they've wasted time on something that doesn't fit into their manager's ideas of measurable performance. Now, a lot of tech companies do try to encourage innovation, but if a worker has an idea for something they really believe in, they are more likely to form their own company where they can be in complete control of their vision. The professional software development environment does not encourage risk-taking and innovation the same way small companies do, because they need easily measurable metrics to assess performance. They only get out of employees what they reward, and it's hard to measure the value of new ideas and attention to detail.

These ideas I've learned during the development of Leadwerks3D are directly applicable to your own game projects. Don't get discouraged when you run into a tough problem. Even if you had more help, you would still have to figure out a solution, one way or another, and you wouldn't be able to shift that responsibility off onto employees. You can do it, just be wise about where you focus your efforts and plan carefully.

March Milestone Mayhem

  Posted by , 05 March 2011 - - - - - - · 377 views

Leadwerks Engine 3 Art Pipeline


Milestone Mayhem

  Posted by , 05 March 2011 - - - - - - · 400 views

Leadwerks Engine 3 Art Pipeline


Leadwerks Engine 3 version information

  Posted by , 25 February 2011 - - - - - - · 900 views

Attached you will find a document detailing my tentative expectations for the features in the first two minor versions of Leadwerks Engine 3. There are no expected dates yet, but you can judge the speed of progress as I post. This may be subject to change as development progresses.


2.41 Update

  Posted by , 24 February 2011 - - - - - - · 392 views

A new update is posted for version 2.41. Run the update tool to get it. Here are the changes: