L B

It is extremely easy to code a project management software (at least, one that would fit a game project's needs) in PHP. 1 programmer can easily do it.

+1. These three categories could fulfill all needs. People who are not confident enough to offer the warranty of finishing a project could opt for a "Donation only" plan, while others could enable "Donations and financing".

Dang, beat me to that concept. Will still post mine eventually.

I will maintain the team space suggestions and middleware.

Alright, I think I owe to bump that one, apparently we all got used to it, but there are always some times when you would like at least a 1-level undo.

Bump on this. I have more than 50 instances of the same object, scrolling is utterly annoying.

http://leadwerks.com/werkspace/index.php?/topic/2477-suggestions/

http://localhostr.com/files/f17bd9/Suggestions.txt DEPLOYMENT -I remember your latest reviewer to have said the deployment was hard. First of all, I always thought the hardest thing to remember with LE was the dependencies of the engine (i.e. what is abstract and what isn't, which folders and files to I absolutely have to copy, etc.) This could be helped by merging the required folders (light and environment scripts, water textures) into Shaders.pak, maybe rename it "Dependencies.pak" or something similar. Then, put these files in a "redist" folder in the SDK directory: C:\Leadwerks C:\Leadwerks\redist -Dependencies.pak -Engine.dll -Netwerks.dll -Newton.dll -JointLibrary.dll -SciLexer.dll This should highly simplify the distribution process, perhaps even the update process. -Another important aspect of deployment is the asset and code protection. Proprietary projects will in no way want to have their assets or code stolen. Protected pak files used to suffice this need, because all of our models and resources could be hidden and protected in them. (Note: this is an actual legal clause in many resource distributors such as Dexsoft, the resources you use can only be redistributed in a protected EXE, DLL or other format). However, since Lua arrived, it has to stay out of these files, for a reason I haven't quite figured yet. There has to be a way of protecting these scripts, notably because you cannot protect your art assets in the pack and leave the Lua out, since the engine attempts to find the file of the same name in the same directory. You could probably extract the scripts to a cached folder before running them, if that is necessary. Or look into a way of compiling and encrypting them, using a virtual machine or similar system (i.e. Themida-like, but much simpler and cheap would do). -The last deployment / team suggestion you could have is to integrate a project section to the website. Ideally, Werkspace members could register as a project members and collaborate. A subversion system could be used for collaboration. Then, having entered the public description and information of the project, the team could include the related screenshots. These last parts would be made available to the public from the Leadwerks website, in a properly-designed and attractive web-page. Serious projects, determined by the Leadwerks team (usually not hard to recognize), could be featured and put in evidence. Furthermore, Leadwerks could act as a redistribution platform, in the way that Leadwerks games could be purchased (when completed) from that very project page, (or simply downloaded if they are free), easing the team from having to contact game-distributors such as Steam or Direct2Drive. A project page could be located at, for example: www.leadwerks.com/projects/aerora If the team has more than one project, an overview, displaying team members, description and trivial information such as creation date, goals and the like, as well as showing their ongoing project, could be located at, for example: www.leadwerks.com/teams/third-initiative I think this system would be highly appreciated by all developers, especially considering the fact that they do not have companies with public relations set up. This would get them coverage and organization, as well as an easy contribution setup (SVN). In terms of marketing, this could either be per-month, per-project, or per-team. It could alternatively be included in the engine price. You probably know better than I do about the possible pricing plans. DEVELOPMENT -Middleware is an important part of any software development kit, whereas the engine, apart from the editor, is limited to more of an API. -The engine's art pipeline has a good start with its own model format and available converters. However, all converters are inofficial or lack consistency. When adding assets into your game from external sources, the last thing you would want to worry about is if you will be able to use it with the engine without purchasing additional software. I think a unified converter, in a central application, converting from FBX, 3DS, OBJ, BLEND, X and B3D (and more, if you see fit) to GMF is a must-have for a proper art-pipeline. Again, please do not see this as a negative critic - I simply think that seeing the quality of the engine rendering and possibilities, its usability shouldn't be undermined. NOTE: An application, with a similar UI, should be available for converting JPG, PNG, and BMP to DDS, with the proper settings (selectable). Suggestions could also be mape (i.e. predefined terrain texture settings, predefined alpha texture settings). This application should not export material files, as experience has proven the automatically generated files to behave improperly. The material editor should have the whole responsibility of doing this. NOTE 2: Batches or queued operations should be implemented in both these converters. -Adding to the art pipeline, a last piece of software I think is useful when organizing your texture and material files to give them generic names is a model surface editor. For instance, have it organized this way: textures_buildings_brick_a.dds textures_buildings_brick_b.dds textures_terrain_grass_a.dds Instead of dexBRIK01.dds dex_BRIK2.dds terrain_g1.dds Is quite useful for organization or your files and folders. However, since the GMF format cannot be edited after having been exported, and since exporters all behave differently, you end up with the GMF file looking for different material names, and you cannot edit them. The Surface Editor should be able to edit the material names in any GMF file, allowing you to change dexBRIK01.mat dex_BRIK2.mat terrain_g1.mat To textures_buildings_brick_a.mat textures_buildings_brick_b.mat textures_terrain_grass_a.mat And therefore let you organize your files properly, both for team-work and final distribution. -Finally, one thing a use had done in the previous forums, under the name of MeshBox, was a model rescaler. Particularly useful considering the editor cannot properly scale items. As you can see, all these middlewares remove the need for a developer of acquiring a 3D modeling program. They can rename and rescale directly from the GMF, without having to edit the original file, which can be troublesome without any knowledge of 3D art. Also, they can convert with ease without any 2D or 3D art program, and with confidence that they will be able to use all their external resources with the engine. In short, 4 additional middlewares: -Model Converter -Texture Converter -Surface Editor -Model Scaler -(Optional, easy-to-do fifth: Particle Editor) All of which I will personally write for myself (Windows only) unless an official support is in the making. Tell me if you are interested in having these officially integrated, in the event that I make them. LAST NOTE: Consistency Consistency is an important part of any company's image. It is a field in which Apple has succeeded whereas Microsoft has blatantly failed. Not only does it simplify the interaction with the company, add to the design and image, but it helps redirecting users to the appropriate support and software without requiring human support. -Web I noticed the website is somehow in a permanent redesign, but has recently stopped changing. The template is disparate between the home and IP pages, and the menus link to many areas that are either dead or unknown. For instance, I just discovered today that tutorials were online. On the other hand, many links I clicked were dead. Finally, some theme elements remain of the IP blue and green, whereas others have been changed to reflect the Leadwerks colors, orange and black. There also seems to be 1 overload image in the gallery header, making it overflow to a new line. As an advanced HTML and CSS developer, as well as a 2D interface artist, I would like to offer my help on consolidating the various sections of the website design (for free, of course). Please tell me if you are interested. -Middleware In all middleware, considering the additional middleware suggested, graphical consistency is suggested. It helps the user to feel integrated into his/her development environment. Therefore, similar icons and form layouts should be used where applicable. I remember having previously suggested the Silk icons, for their quality, variety and licensing. -Tutorials and Documentation I'll come back to this later when I get more news I recognize this is an extensive list of suggestions, but it should not be mistaken with feature requests - please understand that they are all aimed at the quality of the engine, and not towards my personal benefit. I personally have found workarounds around most if not all of the situations. However, since you asked to suggest how to further improve a developer's experience when developing a game with LE, I instantly tried to enumerate the things that would have made me use Leadwerks from A to Z. For instance, I created my own website for project description. I used a custom paid script for the comment box. I use an Assembla subscription for my SVN repository. I registered domains for both my game and eventual company. I wrote lists for the files I have to copy and made a custom installer for my game. I have used various 3D software such as Milkshake and SILO to do my model conversions. I have used various 2D software such as GIMP and a custom DDS plugin to do my texture conversions. I have taken hours to carefully rename my materials before exporting. I have used the unnoficial MeshBox application to rescale my models. I have made my custom Editor skin to keep the graphical consistency I strive to see. Keeping me from having to do all these things manually would have saved me hours of tedious work, accelerated and eased my project development and certainly would make me pay more for Leadwerks, seeing as it is now a service instead of an engine.

Wow, I never saw that button before! Thanks for the tip, it will do

Can't stress how smooth that would look with AA. Awesome work, I love it.

I could, but then how do I import the PNG into the editor?

Mm. Too bad I can't go from Editor to pureLIGHT, remaking my scenes will be extremely time consuming, considering I choose to do so. Is the pureLIGHT scene format plain text? If so, I could attempt an exporter. I think I'll just wait for a better integration, even if that means LE 3.5. Here's a more direct comparison for those who want it:

+1 for Before/After shots.

I will test looking through the SBX file (as text) to see if the parameters are set correctly soon. As the lighting of these scenes is extremely important, I can't afford to lose the settings.

Lumooja, don't you have source access?

Many thanks to the 2 persons who donated right after this post, it wasn't meant as a plead but I really appreciate it. Edit: 3 persons

Scene 1 (directional light shadows gone, but point light shadows work) Scene 2 (all working) The more I think about it, it has to be a problem with the SBX file, since all other variables are constant. Any wild guess is appreciated

You had me there, I indeed hadn't. I updated the Lights and Environment folders now, and can indeed see the option. But I still have my problem.

This sentence from the Particle Shadows tutorial made me wonder if I had my files right: "The last step to make this work is enabling colored shadows on the directional light. Select the directional light and open the properties editor. In the light properties you will find a checkbox to enable colored shadows. Set this to True and press Apply." I do not have a "Enable Colored Shadows" checkbox, only a Range option (which is new, as far as I know?). Is it me who is outdated (I just updated 5 seconds ago from LESDK.exe), or is it the files for this tutorial that are not ready yet?

Since I can't isolate the problem, does that imply posting my 740MiB of data, unencrypted and not ready for distribution? Isn't there a simpler way?

I copied the shaders.pak from a clean installation of LE2.4. Also, since I see shadows in scene 2 but not in scene 1, with the same code and dependencies (exe at same location, same abstract path), I doubt it's a shaders problem.

2.40. I could send you the SBX personally, but not publicly on these forums.

Ah, as in "Buy it now and get a rebate", not a 1-month paid-trial. That might be good. This technology is important for my fantasy style game, but I am out of budget. Over 2000$ have been spent on this project, out of my 17-year-old pocket. Although I strive to maintain quality, I will have to stop spending so much. Many comments on Aerora.com said they would donate, but never did. (Except ZioRed, who donated $5. Thanks, it has been my only income for the last year and a half). I know I should adopt a financing model, but it isn't feasible legally at 17. Next year for sure.

@pureLIGHT: Ah. I won't pay 500$ for it.

Of course I can, I think it is simply bothersome for a new user to wonder why water is the only framework effect that doesn't work in-game, simply because he hasn't copied the texture folder. I can use my own workarounds for many feature requests, although it is of more benefit for the community if it gets implemented by default.