BLaBZ

It's been 15 days since the official launch of my first software and so far it has been an incredible learning experience. You can't predict the future, but you can learn from your mistakes, and with that I'd like to share my number one discovery. When your product releases it reaches a number of unique people who each have a unique age, position and disposition of your product. There will always be a myriad number of reasons a person might want your game or product but it's rare that this has been their dream product or something they've been following for awhile. What I've discovered is that the users who have purchased and taken their time to understand the product are the users that have always wanted a product like this or dreamed of the results they could create through using this product. There is an educational curve that, unfortunately, surpasses the attention span of the average downloader curious about the product. The lack of instant gratification deters a trial user from moving any further into discovering the products capabilities. It's a lost opportunity. What's obviously essential in creating games is finding that perfect combination that keeps players interested and hooked. They play for hours on end and can't help but tell their friends about it. Then you have a game that's becoming viral. I never thought to truly apply this concept to software. To me, software development has always been about creating a useful tool to solve a particular problem. Designing a software in terms of instant user gratification has always been an afterthought. The lesson: Most users want a magic bullet that gives them instant gratification, do you best to give it to them. -Ben

In the midst of my late night insomnia set on by inspiration and excitement, I read the talk “AI is possible .. but AI won't happen: The future of Artificial Intelligence” by Mark Humphrys. http://computing.dcu.ie/~humphrys/newsci.html This is a great read for someone interested in the current state of AI. It’s far less impressive than someone might hope, but far more realistic. In summary, when computers were invented people generally believed we had the tools to create brilliant artificial intelligence. What we misperceived was that the simpler things, such as walking and spatial navigation, have proven more difficult to create then an unbeatable chess AI. If we can create AI that has the ability to perform fundamental tasks, like that of a toddler, it may provide the foundation for the advanced AI we so often imagine in movies. Why I believe this is such a great read for game and software developers as well as technologist is that it also identifies the large gap between where we are today and where we’re going to be when we have true AI, which the author believes will be another one to two centuries. If you take the time to creatively imagine what technology might need to be in place to produce true AI you could see there’s a huge opportunity for innovation. New software’s are abstracting and automating processes that were once difficult, Leadwerks is an example of a tool that now makes tens of thousands of lines of code easily usable and accessible. As we continue to abstract and automate more complex things, we become that much closer to creating a learning machine. The point I’m ultimately trying to make, is there’s a lot of opportunity for innovation if you can see the sky, and one of the highest goals we can hope to achieve is true AI.

A focus that's received a lot of attention in the world of productivity has been motivation. What motivates people and how people are motivated in turn results in all of the worlds output. By boiling down motivation we can separate all types of motivation into 2 separate and opposing psychological sources. "Away from" motivation are ideas and situations a person is trying to avoid. For example, you don't have a job, you're running out of money and you're unsure how you're going to continue to put food on the table. The fear of not surviving motivates you to get a job and ensure your survival. You're trying to get away from the idea of not being able to survive. "Toward" motivation consist of ideas and situations you're trying to attain. If you have a game or software, and distinct vision that inspires your motivation, every time you work to attain this vision you're working towards an idea. What I've found fundamentally instructive about these distinctions is the quality of output based upon the inspiration for our motivation. Another word choice for these opposing forces could be "Fear" versus "Inspiration." RTS Creator was founded on Inspiration from day 1. Every day before I put code into the machine, I take the time to recognize what I'm doing and why I'm doing it. What's the vision for this software, why is this vision great? How do I want people to feel when they're using this software? The feelings and ideas I get from asking these questions fuels excitement, and motivation. I want to enable people to bring their ideas to life, to get excited about the new possibilities that are now at their finger tips; to experience the awesomeness of making a world of war that consists of factions and armies of their own imagination. This is the inspiration RTS Creator was founded upon and I hope to inspire that same inspiration in the users of RTS Creator.

This is great news! I haven't used Noesis, but based on everything I've seen it looks like you guys are on your way to becoming the Gold standard in game UI. Great work and wish the best for you guys!

A quite insightful post. I wonder if this was largely due in part to the fact that Leadwerks was Greenlit which the user base primarily consist of PC users. Discontinuing mobile sounds like it's ultimately good news. You have momentum in a particular direction and now it's all about feeding that momentum. If you can dominate the PC indie game dev market segment it will then be easy to bleed into other market segments, when it could become profitable to support mobile. Impressive stuff Josh!

From what I've experienced there's a huge performance boost by both not supporting prior OpenGL versions and the newer OpenGL api. Not supporting legacy means no structuring or checking for mitigation, +1 for performance. The newer api reduces latency and communication between the app and the gpu +1 for performance.

Great work Josh! I'm sure there's a very rewarding feeling finally getting to use Leadwerks for its intended purpose. What are the limitations of Leadwerks for steam vs the kick starter backers? Looking forward to playing the demo

You could serialize your game data as well. There are a lot of benefits to this technique.

This would give you the ability to reflect! Could come in fantastically handy if you ever wanted to wrap a GUI around your engine to make edits.

There have been a lot of lessons learned now that I’m finishing my first large project. RTS games continually push the limit on unit and structure counts and with the latest OpenGL features I would argue it’s now possible to have hundreds of thousands of units. The strategy is simple, the implementation can get tricky. Keep all movement and calculations on the GPU and use textures as data structures (optional). The concept borrows a similar idea of a lot of modern particle systems in that each unit is treated like a particle. The limitation is communication between units. An example would be one unit firing upon another or a unit searching for the nearest unit. This can be timely and may require multiple draw commands or shader logic updates. A rough high level overview looks something like this – Create the following textures to represent the corresponding data. CurrentPosition CurrentRotation CurrentDestination Use the textures RGB values to represent xyz and Yaw, Roll, and Pitch. Pass1 update each objects position and rotation to get nearer to the destination and store each units new location in the textures. Use OpenGL’s glDrawElementsInstanced command to draw lots of units very quickly, using gl_InstanceId to represent each units information in the textures. If you strictly plan on deploying to a PC you can disable the Rasterizer in the pipeline, use transform feedback, as well as texture buffers to improve performance even further. Using these technologies can be tricky but exemplifies a strategy for computing mass warfare. My intel laptop with a Passmark benchmark score of 340 can update and render about 50k units. The GTX 780 with a score of 7,952 theoretically could handle 1.1 million units. (Units were pyramids consisting of 4 vertexes, no textures and nothing else drawn or updated)

How many simultaneous projects can you manage until your productivity begins to drop? This has been inspired from my own decisions and mistakes of over dedicating myself to numerous projects ending up ultimately being very unproductive. If I have 4 projects and I split my available time evenly across these 4 projects the productivity is not split evenly. Additional time is taken closing previous projects and opening and prepping other projects. Will power, state of mind, and vision for each project requires a mental shift when shifting projects. The simple lesson in this experience is dedicate yourself fully to as a few projects as possible for maximum productivity.

As a single developer on a relatively large project that has taken much time to develop, the progression of technology can prove to be quite an enemy. 4 years ago the technology considered cutting edge is now legacy and the dependence on such technology can prove to be quite a headache when attempting to upgrade. A common practice when the underlying implementation of particular technology is expected to change is to create interfaces that act as contracts all implementations must abide by. This is a phenomenal technique if you want your "engine" to withstand the test of time. If your project scale is fairly large and you plan on upgrading from Leadwerks 3 to Leadwerks 4 in the future I highly suggest doing this. I didn't start with Leadwerks, but if I implemented contracts my game would currently use Leadwerks. The ultimate point is if you want your code to stand the test of time write it in a way that anticipates technological change.

lol this guy...

Coincidentally I was just building a pc for the first time in 2 years yesterday. I last built my pc 3 years ago, and while the benchmarks are still relatively good by today standards support for the latest OpenGL drivers is no longer available and I'm stuck at v3 I'm also hesitant about the assumption that more cores means better performance. Not all games\applications take advantage of all cores, and you'll always have you main thread managing the rest. But at the same time, a lot of modern games are far more GPU intensive then they are CPU intensive. Are you using a SSD hard drive?

I love the idea of SteamOS taking a punch at the traditional "console" market but I fail to see how this is truly "better" than using a Computer or and existing Console. It seems like this is basically "Steam on TV." I'm excited about it, but I don't really see it competing with Xbox or Playstation. I feel like only extremist gamers will be using SteamOS. Releasing a console every 6 years is really beneficial for developers and users. Games are highly compatible with the hardware and users will know which games will run on their console. I hate reliving the nightmare of purchasing a video game only to find out your computers specs create ungodly lag and poor graphics. The deferred renderer looks fantastic! And what the heck is a blur kernel? Is that native OpenGL?