Josh

I have never heard of Maestro so I'm afraid I can't give any advice.

What should I call the root type for both the TServer and TClient types? TNetworkNode? TNode? TTerminal? THost? What seems like a proper name?

Chat 20 is up. This uses locally controlled clients. You own controller will respond instantly, though other players may be more laggy than before.

I am stating that no engine is immune to driver issues. They all use either DirectX or OpenGL, and ATI periodically releases drivers with problems with either API.

Sounds like maybe you need to install graphics drivers?

The new networking features might help you here.

Every game has issues with ATI drivers from time to time, whether it uses DirectX or OpenGL: http://forums.amd.com/game/messageview.cfm?catid=279&threadid=118892&enterthread=y http://forums.amd.com/game/messageview.cfm?catid=279&threadid=125717&enterthread=y http://forums.amd.com/game/messageview.cfm?catid=279&threadid=125385&enterthread=y

I think you will find the knowledge you gain in the C++ videos will transfer almost 100% to Lua, since the commands are the same.

I am looking into this...

There is extensive documentation of the Lua implementation here: http://www.leadwerks.com/files/Tutorials/Lua/Getting_Started_With_Lua.pdf See pages 10-14 for information on class scripts, especially starting at page 12. On page 18 it shows how to make an object turn each frame in the editor, using a class script. The command documentation is all in the wiki. Start here: http://www.leadwerks.com/wiki/index.php?title=Entities We're also in the process of getting an example character animated, so it can be used for a "make a game" type tutorial.

Actually, the FPS example has both of these, I believe. If it doesn't have a muzzle flash, you can just... 1. Add a quad mesh where the end of the gun is. 2. Paint it with a muzzle flash material, with an additive blend. 3. Show the muzzle flash mesh when the gun is fired, then gradually darken and then hide it. The smoke is already programmed in that example. It just uses an emitter that gets turned on when the gun is fired.

If you're not in a hurry, a new demo will be out within four weeks. You could look at that when it's available, if you like.

I think you should use the physics system because it will interact the best with other physical objects. None of the methods you listed will have any bearing on performance.

This link will work: https://www.paypal.com/xclick/business=orders%40leadwerks.com&item_name=Leadwerks%20Engine%202.3%20single-user%20License&amount=200.00&no_shipping=0&no_note=1&currency_code=USD

Adjust the mass of the object. It's actually working correctly.

I think most major companies have to focus on the XBox. The problem is you have to already have at least one successful published game to even get the development kit for the XBox. There are also lots of successful games that are only published on Windows, like STALKER and a lot of MMORPGs. Hopefully we'll have support for Mac and Linux relatively soon, too. I agree with that.

That's what I am saying. You still have to do the hard work of making a game. But if you are willing to do that work, your results now and opportunities for publishing are much better than they were a few years ago.

I agree a new evaluation kit is needed, and we'll have it out within a month. Please forgive the suspiciousness of some forum members. Piracy used to be a big problem for us, and the private forums have solved it pretty effectively. It seemed the pirates were often the ones asking really dumb questions, so they ended up consuming support resources that could have gone to helping actual customers. You can ask any questions you have in the general forum, and we'll do our best to answer them.

I think conditions have never been better for independent developers. People routinely post screenshots that look as good as AAA games, there's a large amount of good quality media available to buy from various sites, and we have Steam for publishing. That wasn't always the case. Remember, until recently independent developers were always a generation behind the technology the big game studios were using. When they had Quake 3, we were still struggling with basic lighting. When they had Doom 3, stencil shadows were a cutting edge feature no one had access to. Since the pace of technological advancements has slowed, we've been able to catch up, and in some cases, overtake the large developers, who are constrained to working with console hardware. Lightmapping and visibility processing use to be a huge time-consuming task, taking hours or even days to process a scene. Now it's all done in real-time. We no longer have to use separate materials for lightmapped or vertex-lit surfaces. You can model a scene in any modeling program, instead of being forced to use a special BSP editor. Of course our Lua implementation allows a sort of real-time programming that has never before been possible. We used to have to launch the game and wait for a map to load if we wanted to test a script, in Quake or Half-Life or something. That would take at least a minute. Now, we just save the script and it is updated instantly. Some people might not want to make a game at all, and that's okay. Many people only want to tinker around with technology as a hobby, and that's fine. To make a game, you still have to do the hard work of deciding what you want, and sticking to that as you execute the plan. You may find that by the time you get halfway through the execution, you no longer have any interest in the game. At that point you either keep going and finish it, or you abandon the project in favor of something new. Ultimately, that is what determines whether you finish a game or not. The mistake developers often make is that they would rather dream of new and ever more impossible features than to live with limitations of their plan. I have seen hobbyists obsess over details AAA games don't even worry about. How many times do we see a beginner come on the forum and announce their plan for a game "like World of Warcraft, but ten times bigger". I think it is more fun to make grand announcements of groundbreaking new features than it is to develop a game using a decided set of features. With the former, you can get positive feedback without doing any work. With the latter, you are stuck doing the boring work of figuring out why a gun isn't shooting in the right direction, or something like that. You spend your time solving problems no one will ever know of or thank you for fixing, and you don't get any positive feedback from that, only complaints when it doesn't work right. Penumbra is the best example of a successful independent game. You can see decisions they made, like using an intercom system for communication with the player. This meant they only needed voice acting, and no animated speaking characters. Although speaking characters are technically possible, it would be a big consumption of art production resources. When you play the game, you realize all the hours they must have spent testing the game and making sure the gameplay worked correctly. A lot of the development was probably very boring work. It might have been easy to get sidetracked and say "this is boring work, let's add a sidekick who fights with you, or let's add a third-person view like the game _________ has." Instead, they worked on the game steadily using the rules they decided on, until it was done. It's not that new features kill projects. Refusal to do the boring work of production is what kills projects, and this often happens when the developer runs away from the hard work so they can go play with new ideas. When you are undecided on the feature set, it's fun because the possibilities are infinite and you can imagine anything. Deciding on the feature set and game design can be boring, because then there are no new surprises. And creating something out of nothing can be draining work. All you see before you is what you have decided on and created yourself. Even professional companies can fall prey to this problem, as in the case of Duke Nukem Forever: http://www.wired.com/magazine/2009/12/fail_duke_nukem/ A small team can produce a game that looks as good or better than major commercial games. This was an impossibility a few years ago. If you want to make a game, the time has never been better than now.

The OBJ format does not support hierarchies, so it is already merged before the converter gets the data.

The resolution times the x scale is the width.

No, but it is possible to set it up in script so that you can always drag the object into the scene and have it work, once you write the initial script.

The way the class scripts is set up is not simple or easy to understand, but fortunately it is not necessary that you understand the structure. If you just copy the basic template and expose whichever functions you need, you can add your own code to make the entity behave. For a more in-depth look at tables, go to www.lua.org. To explain the table/class code, I would pretty much have to explain the whole Lua tables system.

Lightmapping has some problems. Let's say you have two cars on a street. One is in a shadow, and one is in the sun. You lightmap the scene, so now each car has it's own unique lighting. Now you can't render this scene with instancing, because the cars have different secondary UV coordinates and may even use different lightmap textures. You would never be able to lightmap an outdoors scene at the same resolution our shadowmaps use, or anywhere close, because the texture memory required would be enormous. The best way to do any precalculation like this would be to render an ambient occlusion map in Giles or 3ds max, and then use a special shader that just treats the AO map as part of the shader. You won't have unique lightmapping based on actual light positions, but it will blend nicely with the dynamic lighting, and you will still get fast instanced rendering. Here is a good example: http://forum.leadwerks.com/viewtopic.php?f=7&t=3599

The private programming forums ensure that the registered developers can have privacy, can post files freely, and get the best attention from support. If you have any specific questions you can ask them in the public forum here.