Jump to content

Suggestions


L B
 Share

Recommended Posts

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.

  • Upvote 2
Link to comment
Share on other sites

Wall-o-text!! :)

 

Made it through the first paragraph anyway, but adding the scripts in the shaders.pak file might not be ideal as not every game made with LE would require those scripts. I know some people were not using Lua at all and it's not really a requirement "yet" I think (I think ini files are still possible, but I know Josh said he was going to take them away at some point). Also, I know when I was working with Lua I would often want to view those files to see what they were doing and I would often do it with an external editor because it wouldn't crash like the Editor would on me many times in a session (maybe that's been fixed?). So having them in a .pak file would make that slightly more cumbersome.

 

I think ideally there would be a packager (maybe you said that in your test, but I didn't read the entire thing) that does all this for you once you are ready to deploy.

Link to comment
Share on other sites

Nice suggestions Lazlo.

 

- Scilexer.dll doesn't need to be distributed as it is just for the scripteditor and not needed for the engine itself.

- Currently i notice that a lot of bmx users also distribut engine.dll --> not needed in bmx.

- I remember a chat with Josh about having Scripts in a pak file and I also rememer that this should be possible with > 2.32. @Rick he means the model scripts, not the general script folder.

- I have a Batch Asset creator in the works. I have already converted > 300MB Packages from Arteria and Dexsoft in less than 5 minutes.

Currently it is just a prototype, but it already let you convert from GMF, FBX, Obj to GMF format. Rescaling is implemented and it autogenerates materials if it can't find proper materials.

It also generates normalmaps and simple scripts. Currently the pipeline is not that easy as it sounds, but this is what i'm currently working on. Least it packs the converted models into a clean

ordered Folder.

 

Otherwise +1 for the other things.

  • Windows 10 Pro 64-Bit-Version
  • NVIDIA Geforce 1080 TI
Link to comment
Share on other sites

Nice suggestions Lazlo.

 

- Scilexer.dll doesn't need to be distributed as it is just for the scripteditor and not needed for the engine itself.

- Currently i notice that a lot of bmx users also distribut engine.dll --> not needed in bmx.

- I remember a chat with Josh about having Scripts in a pak file and I also rememer that this should be possible with > 2.32. @Rick he means the model scripts, not the general script folder.

- I have a Batch Asset creator in the works. I have already converted > 300MB Packages from Arteria and Dexsoft in less than 5 minutes.

Currently it is just a prototype, but it already let you convert from GMF, FBX, Obj to GMF format. Rescaling is implemented and it autogenerates materials if it can't find proper materials.

It also generates normalmaps and simple scripts. Currently the pipeline is not that easy as it sounds, but this is what i'm currently working on. Least it packs the converted models into a clean

ordered Folder.

 

Otherwise +1 for the other things.

 

Yeah, I talked with Josh and figured some of the suggestions out already.

By the way, why do people always say +1 and never give rep. I give rep. Am I the only one to do so?

  • Upvote 2
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...