Jump to content
  • entries
    944
  • comments
    5,899
  • views
    929,487

S-M-R-T


Josh

8,839 views

 Share

I've made more progress on the model editor. I needed it to be able to resave models after making changes. First, I started with an Entity::Save function that would save all entities in the GMF format. "But wait", I thought, "I can save all entities in the GMF format!" Then I thought, even better, I can simply write a Serialize() virtual class function in the base object and extend it for each class, so that instead of writing this:

stream->WriteFloat(position.x);
stream->WriteFloat(position.y);
stream->WriteFloat(position.z);

I can simply write this:

position.Serialize(stream);

"I am so smart! I am so smart! S-M-R-T!"

 

Wait a minute, if I write a World::Serialize function, I could save an entire world with all entities in a single file, so that another person can just open the file and recreate everything that was happening! Amazing! :huh:

 

Of course, serializing every instance of every texture would be terribly wasteful. Should assets still be loaded from files? What if they were missing? What about models that were loaded and then modified? Can I use this for sending entities over the network? How does this all fit together?

 

It was around that time my conscience started kicking in, or whatever that feeling you get when you know you're doing something dumb is. So I stopped what I was doing, imported the GMFSDK code into the editor, and wrote a SaveModel() function, which is all I needed in the first place. <_<

 

I changed the default background color to dark gray (0.25). It makes thumbnails more easily visible, and is dark enough to not kill your ability to see dark pixels. The thumbnail generation uses the last rotation you had in the model editor, so it's very easy to adjust the thumbnail. The thumbnail renders use an orthographic view, which makes it easier to make better use of the available pixel space, and seems to look good. Thumbnail renders for materials and models use 2x antialiasing, which looks great blended against the background color.

 

The thumbnail icon view we use for assets is one of my favorite parts of the editor. Having used this and a few alternatives for a while, I think this gives you much faster and easier access to all your files.

 

blogentry-1-0-20523500-1325041579_thumb.jpg

 Share

35 Comments


Recommended Comments



@ Rick

I never ever touched LE editor..I created my own set of tools/editors, based on requests from artists im working with..in fact, Im not even using LE completely (no newton), just renderer..

Link to comment
This is a nice thought but if the tools aren't sufficient then most people won't be able to make their games. Which seems to be the consensus with LE2.

Leadwerks Engine was never designed to be a visual game design tool. It was conceived as a programming SDK for BlitzMax. It didn't even have an editor when it was first released.

 

Leadwerks3D is being developed with a completely different approach.

Link to comment

This is a nice thought but if the tools aren't sufficient then most people won't be able to make their games. Which seems to be the consensus with LE2.

..from requests i was able to see by now, most of the folks here, doesn't asking for tools actually, but for plug n play components require none or a very little bit of coding to get up and running...thats why LE2 is 'not popular'..for instance, many times I saw people talking about 3rd perspective cam control, as a 'feature' in LE3..while i agree that such script/code or whatever you call it, be included as an EXAMPLE, i cant possibly understand such requests as a something whats falling in to a MUST category as part of feature set..its bloody 30 lines of code in LE2, and few examples floating already around, and still its an issue...reason why I mentioned this particular example is because, if 3rd person cam is a problem, I could list massive amount of several magnitudes more difficult tasks waiting out there, during actual gameplay structure creation..and im wondering are those things going to be required as an feature too ?? Are such requests going to slow down LE3 dev cycle and possibly bring LE2 dev cycle to stall totally? Bottom line is, if you wanna make your game, then, best approach is teaming up proggy-artist..if you going one man show, then do some effort and get hands dirty with programming, because at the end of the day, you are building computer application- program..simple as it is..

Link to comment

From what I can tell a decent amount of people asking for these tools have left for other engines that have them until LE3D comes out. Niosop would be an example as such a person. Sure there are artists asking for things like 3rd person camera and I'm with you in that it shouldn't be part of what Josh creates but he's not really promoting us programmers to make things easier for the artists either. Adding a Lua system was a first good step but by supporting so many languages and not having a game system built into LE hurts it when it comes to those people, but helps it with the programmers to reach more people.

 

I have a small marble game I'm making and I'm using only (for the most part) basic, reusable entity scripts that I'm creating. Joining them together via the targeting system and property settings to make more game functionality. I'm hoping this will show that you can make games using such a system. If LE2 had a better game component system this would be easier and most likely adapted by non programmers and promote programmers to make components that everyone can use in a visual manner. Some things to use this way can come off awkward because of the lack of extendability by the editor.

 

 

On a side note, one issue I find again and again which hurts these kind of components is the ability to create bodies in Lua AND have collision callback be called on it. This would allow volume triggers which is a huge gameplay component in a good number of games. Currently a model has to be created and then you have to code specifically for that model. That's not very user friendly at all and will generally shy artists away unnecessarily. It's so many little things like that which hinders the engine to be user friendly to artists. BUT the biggest hindrance is Josh not supporting a game/component system by making the system and promoting the system. This has no effect on the programmers who don't want to use it and a big effect on the non programmers. At the end of the day there are more non programmers than programmers out there who want to make a game and will pay for an engine that makes it easier and looks good too.

Link to comment

This has no effect on the programmers who don't want to use it and a big effect on the non programmers. At the end of the day there are more non programmers than programmers out there who want to make a game and will pay for an engine that makes it easier and looks good too.

 

..that is very true..and at same time, most probably reason why from my side, commercial use of LE in general, will stop with LE2.x(maintenance of projects done with LE.2.x), because more and more im reading talks about LE3, more and more it looks like a bunch of 'black boxes' with 'input/output' wires you just need to plug and whooo..you have done it all..and if people finding LE2.x unfriendly, I assure you that they should rebuild their programming skills, because LE2.x is an easiest rendering system i have seen so far, commercial or not..as for people who left LE at this moment..i know few folks and i keep in touch on regular basis, and from what I can hear is not directly system itself but way things are developing/supporting, not actual use of system..

Link to comment

because more and more im reading talks about LE3, more and more it looks like a bunch of 'black boxes' with 'input/output' wires you just need to plug and whooo..

 

I think you are reading into it wrong. The pure coding that you know sounds like it'll still be there, but for the people who want to use the Lua system can too. But I don't agree with your thinking of not thinking a game/component system won't make commercial games. Unity has a similar system and many commercial games are created with it.

Link to comment

...i never said that game/component systems cant make a games...I was talking about dragging development of system on to side where game components are required by developer (while such components are more - less trivial), rather than flexible, powerfull, bugs free system, instant response to bug fixes and so on..

Link to comment

The programming component remains in Leadwerks3D, and in fact will be better supported. But we have learned by now a programming SDK alone can't survive. For every programmer, there are a hundred non-programmers who have just as much money to spend.

 

Making an easy to use visual tool was never a consideration in the past. I can't be accused of failing to provide that, because I was never attempting to. Until now, I have focused solely on performance and features, and was able to develop some nice technology. With Leadwerks3D, I am making the art pipeline and ease of use top priority, which is why I don't like hearing that people are already planning their own ways to work around the default pipeline.

 

Your experience with Leadwerks3D will be completely different, because all those little tasks that are left to the end user in Leadwerks Engine now have a supported documented way of accomplishing them. That also has the benefit of lowering my support costs because people can just look up in the docs on how to fix a model, adjust a light, etc.

Link to comment

With Leadwerks3D, I am making the art pipeline and ease of use top priority, which is why I don't like hearing that people are already planning their own ways to work around the default pipeline.

 

For some strange reason you're still believing that the goal of a custom editor script is a workaround to the editor itself or the pipeline or both, which is absolutely not. The only reason why custom editor scripts exist in any piece of software is to extend the features to a very specific need, it's not a workaround to the software's developer pipeline or such.

 

Take this as example (even if Niosop already made it clear in his first post): some days ago I changed many times the structure of my scene while prototyping (in another engine, I don't want to advertise it), I changed it so many times that the result was that I created an editor script where I set a couple of parameters to automatically and randomly create the map at all from walls to floors in an indoor scene. This was so specific that of course couldn't be thought or developed by the engine's developer (in terms of development cost against the amount of times/users would use it), but luckily the engine allowed me to completely extend the editor so I could achieve my own needs for that project.

 

It's only an example, but many others could come in mind, not mentioning the chance of business that a customizable editor could bring to a capable licensee who make scripts for editor to help make things easier while prototyping or scene/entities creation. There should be something I'm missing in your reluctance...

Link to comment

Let's say someone wants to make a flowgraph editor for the engine. Allowing them to tap into things directly into the editor would help. When making a flowgraph there are things you would want to have that closeness with the editor for. You want to be able to query all the objects in the scene in the flowgraph editor, be able to right click on objects in the editor and do a "Show in flowgraph" etc.

 

There will be other things we all aren't even thinking about.

Link to comment

Guest
Add a comment...

×   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.

×
×
  • Create New...