Josh

Start with a root widget, then draw its children recursively.

The problem is people with programming questions who use C++ will never get seen by someone who might know the answer who uses C#, etc. We have a "general" programming forum, so people have to choose whether they want their question asked in a sub-forum that is more specific, or in general programming, where they might get more views. Or they might get fewer, if everyone just sticks to their own language sub-forum. Here's Macklebee posting in the wrong forum: http://www.leadwerks.com/werkspace/topic/4135-animationlength Once the programming forums got split up like they are now, I just stopped reading them.

The problem is we have too much categorization, and people end up not visiting sections, myself included. I am trying to make everything one level deep, across the site.

I won't do this quite yet, but keep it in mind. Also, in LE3 the syntax all matches between supported languages, so that should make things more cross-language friendly.

I'm moving 3D World Studio into the tools section of the Asset Store, and focusing the whole site on the engine. (The new version merges 3DWS and the engine together.)

Sign in is still on the left. You can sign out by going to the Account drop down menu, then Sign out is the last item.

I fixed the artwork forum, thanks for pointing that out. Yeah, that proves my point. Too many subforums.

I want to merge all the programming forums into one. There are too many forums, and the sub-categories get confusing. Most programming topics don't revolve around only one language, as they are all pretty similar once you get over the syntax. I know I just stopped reading them all once they were split up into different languages. I think the most recent topics in programming are more relevant to most people than having them divided up so you don't have to see something in another language. What do you think?

I have found it isn't polygons that matter so much. Bumpmapped surfaces are far more demanding. These devices seem limited by pixel shaders for the most part.

I like where this is going.

This will make sure the light's local position is kept, which I assume is 0,0,0: EntityParent spotlight,cam,False

I look forward to your bug reports!

Of course, my article was not meant to declare a hard and fast rule that was accurate 100% of the time. Everything else being equal, a larger team will have a lower per capita efficiency than a smaller one. When developing a complex application with many interwoven systems (like a game) this loss in efficiency can be very significant. This article was written to explain some of the advantages people working in small teams have, so they can better understand their own strengths. In the past I sometimes found myself engaged in wishful thinking that if only I had more manpower I wouldn't have to figure out some complex task...but more workers doesn't make design challenges go away. You still have to make all the design decisions, describe to your employees exactly what you want them to do and how they should do it, and verify that it was done correctly. Often times it's much easier to just do it yourself than try to assign, monitor, and evaluate someone else's work.

Why wouldn't it be?

You might try downloading new drivers from www.nvidia.com. However, I don't think the engine will run very well on your card. I didn't even know there was such a thing as a GEForce 7050.

And who enjoys the benefit of that? Is your definition of success to be a shareholder of a company that produces "Call of Duty: Modern Warfare 3", 4, 5, etc.?

A pep talk is an emotional story that makes you feel good for a couple days. The effect wears off, because nothing was really learned. I explained in pretty scientific terms two significant problems a company faces as they grow. The purpose is to make you aware of advantages you have that you didn't realize. If you are forming teams and collaborating, this will also help guide your decisions on how many people you need, and what you can expect from others. I'm not sure the definition of a "modern" AAA game even makes sense anymore. AAA games are targeting five year old hardware, so they've already given up on pushing technology forwards. RAGE on the PC looks about the same as RAGE on the iPad. Exactly what makes them AAA? Advertising and having a popular franchise, and not ever doing anything new? Look how many large studios are striking out on the consoles. If it's not "Call of Duty" or another well-established franchise, it's going to struggle. Meanwhile, Minecraft is selling like crazy, and it's not even finished. Casual and mobile make up a bigger and bigger percentage of gamers, so are they really "casual"? No, the days of the giant game studio are at an end. Indie is the new AAA.

What I'm saying is the core of almost any complex technology is designed by one or a few people. You can expand and add more workers into the mix later, but they won't be anywhere near as effective as the initial team, and you can't very well split up the work of designing the overall system.

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 InterdependenceWhen 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. 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 MotivationAnother 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. ConclusionThese 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. --Edit-- I posted this article on GameDev.net and got a few interesting responses:

Just download the Lua library, include it in your project, and call the Lua functions directly.

That's pretty amazing.

That's why they call him macklebee...

I think you'll get the best results with BlitzMax + Leadwerks Engine, but everyone has their own preferences.

Yep, Objects in BlitzMax are like a memory-managed pointer. I had trouble with this concept when I started with C++.

I spent most of today getting the Android library more polished, especially when handling application switching. It's a little tricky because Android doesn't automatically manage your sound channels and OpenGL resources, so these need to be reloaded when an app regains focus. Here's a video, which I obviously had way too much fun with in iMovie: