Josh

A world does have to be created before any entities, but I would like to see your entire script so I can run it myself.

If your body is parented to the camera, you will need to transform its position from local space to world space to get the correct position for the call to TerrainElevation(). See TFormPoint().

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. Portal 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. 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. iStuff? 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. Conclusion 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 names short and catchy, and don't try to broaden them to encompass every aspect of the thing that they describe.

I agree it will not have as good of visibility, but we can't have all these Doc, Powerpoint, PDF, etc. files. What's wrong with the built-in text editor?

I decided to make articles/tutorials all one section. Previously I have been guilty of micro-sorting things on this site, and I got better results with broader categorization, which is another idea I want to blog about soon...

The current version of BMX will work with some combinations of modules, and not with others, so it's partially fixed. Since I would have to send additional examples to Mark, describe the problem, test his results on Windows and Mac, and no one else seems to be even doing this, I am not going to pursue it. I am just writing here because this is an example of knowing when to quit something that isn't important. The benefits of using a module namespace are not overwhelming, and continued testing would eat more resources than I want to devote to this. It works fine now with the "le" prefix on everything, and doesn't require any additional effort, so I am moving on.

Exactomundo. Of course, I expect 95% of the content of the articles section will probably be tutorials.

That's just the way Lua works. It stops on the first error. This actually annoys me about C++ because one syntax errors causes a whole cascade of errors, and you end up with 40 error messages because you forgot one semicolon. One of my design rules is not to rely on or try to integrate third-party tools I don't have complete control of. This is slightly different, but recall all the problems that arose when I relied on the third-party Newton serialized format. That's correct. I think a global script is always needed for a Lua game and attempts to abstract that away end up being more confusing. The ability to debug the Lua state of a C++ program is a new idea you have not been exposed to before, but I think it will end up being very useful, especially for professional studios. Think about when your game code is done and artists are producing maps for the game. They'll want to be able to easily launch the game with the current map, and they will want to be able to inspect the Lua state to see if something goes wrong.

If you're describing problems you ran into that are specific to your own project, I would make it a blog entry, unless it was a sort of post-mortem thing, "this is what we learned", etc. that is written to help others who are likely to encounter similar problems. For example, I wouldn't submit an article to GameDev.net that is shameless self-promotion, but if I put it in the context of a more academic discussion, then an article about my project would be acceptable.

An article contains information that helps other people, either with technical, business, or other matters. A blog is more of a self-promotion thing, where you can talk about yourself in whatever way you want. There could certainly be some overlap there, but that's up to you. Tutorials are appropriate for this section, and in fact will probably form 95% of the content, but they should be in the format as described above.

I don't think this has been explained very well, because people are posting anything but articles in the articles section. An article is formatted text. You can include images, blocks of code, a download file, and one or more videos, but if there isn't a few paragraphs of text, it isn't an article. This is what articles should look like: http://www.gamedev.net/#articles This is an example of an article that includes images, a download file, videos, and code: http://www.leadwerks...o-animation-r11 The articles section is not a place to post a single file, video, or bit of code with no discussion. If you have a tutorial in PDF or another format, you may post it in the general discussion forum, but I do not like having a bunch of tutorials in disparate formats, which is why we don't offer a place for these. The articles section provides a place where they can all be readable online, in a consistent format. Do not post links to external files or images in articles, because they may becomes dead links in the future. You have the tools to include everything you need in the article contents. I'm very happy when people contribute to the community's knowledge, but I am going to have to start enforcing some standards in the presentation of the material. It's really a mess right now. Of the four community articles that appear on the front page here, not a single one is an actual article: http://www.leadwerks...e/page/articles

I don't see any point in setting up Leadwerks3D to launch command-line compilers for C++ or other languages (though you could). It gets very complicated for so many languages and platforms, and the feedback would be inferior to just using the real IDEs for that language. I just see it as launching either the script interpreter, or your own executable that you define. I've been using C++ so long, that I am used to a big wall of text whenever I hit F5, but I think the feedback when Lua loads a file is just a single error line if anything goes wrong. Therefore, there is no need to print out a bunch of compile information. If you press F5 in the script editor, the Lua file can be evaluated, and if any syntax errors exist, a message box can pop up and the line in question can be highlighted. This is simply evaluating the syntax of the script, not running anything. Now when we want to launch a scripted game, I can either launch it from the script editor, using the script in the selected tab, or I can do it through a "run game" dialog where you define whether it's a scripted game or your own executable. The advantage of the "run game" dialog is you can launch script and C++ games and debug their Lua states in one interface. However, I feel like it's more natural and easier to launch a script by hitting a hot key in the script editor, which is my main point of conflict in this design. Should the debugger and game printed output dialogs be built into the script editor window? That seems logical, but what about C++ applications? Am I going to make a separate script debugger and output window for those? It's a bad idea to have two versions of the same interface.

There's no technical problems. The problem is one of workflow. What is the best way to design this to work? (The UDP socket is actually exactly what I am doing. It allows the debugger to communicate both ways for code stepping.)

Getting the printed output of the program is not a problem. I can just create a process and read the output directly. I'm thinking more about the workflow and ease of use.

Sometimes I run into situations where I don't really know how to structure things. I don't mind this, because it usually results in some really elegant design once I figure out what to do. I just play with ideas and try not to force anything, and when the right idea arises, I will recognize it. Explaining a problem to someone else can help facilitate that process. How many times have you solved a difficult problem right after you posted a description of it on a forum somewhere? The procedure of explaining it logically to someone else can help you think more clearly about it. And so, we have today's blog topic. Below is a very rough start to the script editor. The syntax highlighting system was written about a year ago, and works beautifully, using the native text widget on both Windows and Mac. In the Leadwerks3D source code, there is a base class called an "AssetEditor". From this class the material, model, shader, texture, font, and script editor classes are derived. Like the other asset editor windows, only one instance of the script editor window will be allowed open at any time. Unlike the other asset editor windows, which display only one asset at a time, the script editor will use tabs to display multiple files. Scripts aren't a typical asset like a material or a model, so it's fine for them to behave a little differently. Any Leadwerks3D application can have its Lua state debugged. The engine uses networking commands to communicate with a debugger on a specified port. This means the engine can communicate with a debugger whether it's part of a C++ program, C# app, or standalone Lua interpreter. The debugger can display the Lua callstack and shows all variables and values in the Lua state, including full examination of C++ objects and members! I do not intend for Leadwerks3D to "play a game" in the editor. We've tried that approach and there are a lot of problems. I want Leadwerks3D to be a very solid and stable level editor, with a visual interface to do everything you need. I also want better consistency between Lua and C++ programs. Therefore, Leadwerks3D will use a run game system more similar to 3D World Studio than the Leadwerks Engine editor. A dialog will allow you to choose the application to run, command-line parameters, and other settings. These will be saved between sessions, so you can hit a key to do a "Quick Launch" and run your game. It would be possible to hook the Lua debugger into any application as it is launched, which could be very helpful. Let's go back to the script editor now. My inclination is to have F5 launch an interpreter and call the script for the currently selected tab. However, I don't think it's a good idea to use multiple game launch modes, I already described a uniform game launch mode for both Lua and C++ applications, but that seems sort of counter-intuitive if you are working in the script editor and just want to run something really quickly. There;s also the question of whether we want to provide a standalone script editor and debugger outside of Leadwerks3D. Or should the debugger be a standalone application as well, since someone might want to use it with a C++ application? You see there are a lot of options and a lot of possible ways to set this up. What about Lua compile errors? I can print that out in the engine log, but how will the editor display it? If a compile error occurs, should the program pause and display the line it occurred at? What if the user just doesn't care, and wants the program to keep going? Alternatively, the user may want to just hit F5 in the script editor and check for basic syntax errors, which the command LuaL_LoadString() will detect. That's pretty much all my questions at this point. I don't expect anyone to come along and solve my problems, but the process of describing and discussing the issues will help me come to a resolution.

In the near future we will gain the ability to add tags to articles, so the language can be specified with a tag.

You can attach a zip file in your article, just like a forum post: http://www.leadwerks.com/werkspace/page/articles/_/programming/introduction-to-animation-r11

Explorer.exe crashes randomly in Windows XP anyways. I notice it often hangs when copying more than a few megabytes of files. Yep.

I want this on my iPad!

That does seem to be where all BMX's troubles originate.

I'll be interested in this if you get a working example of the messages thing.

Preferably nothing. This is an example of what it looks like when you specify a video ID in the article: http://www.leadwerks.com/werkspace/page/articles/_/business/interview-with-michael-betke-of-pure3d-r85

Cool, so you can make your own task manager? There's a predefined BlitzMax tag you can specify for your posts, FYI.

I was getting a reliable crash on GCCollect and finally traced the problem back to this. Never store externed C objects in a resizable array.

I generally prefer tutorials to be self-contained and not link to external resources that may become dead links in the future. You can attach a zip file in the article contents itself.