Leadwerks "opengame" project?

[YouGroove]

Another idea could be to work like standard software developpement team and SVN or GIT.

 

- Like Josh said : Broken into several maps or level chuncks , each people would work in a group of chuncks that could be sub maps assembled at final to make the map : this way noone would overlap other people work or caus physic problems placing static object over dynamic ones.

So LE3 should have the ability to split a map in chuncks, make group of chuncks, import and replace group of chuncks map.

UDK uses Perforce and can work with their streaming system also :

http://udn.epicgames.com/Three/LevelStreamingHome.html

people able to work in same level at same time :

http://forums.epicgames.com/threads/967905-VIDEO-CODE-Proof-of-Concept-A-Multiplayer-Level-Editor

 

- Another solution : one shared whole map file in clear format : XML like or another clear notation

This way all people could work anywhere on the map and merging with their work, they would see warnings like they have modified position or colour of one object another people have also modified.

And it would be some tool or process to transform the map file in a binary format for publishing.

 

I didn't find lot of info on how works World Of Warcraft : WWowEdit ?

 

And appart from that indeed LE3 should provide the possibility to work with SVN or GIT, so all people could easy import a project in their local PC and commit/update a project.

[AggrorJorn]

And appart from that indeed LE3 should provide the possibility to work with SVN or GIT, so all people could easy import a project in their local PC and commit/update a project.

What do you mean with 'provide the possibility'? You can already do this. Just instal Git extensions (for example) and make your repository. You can use a free account on sites like Bitbucket.org or github.com to manage your project. Why would Josh invest time in tools that have been around for years which also work perfectly on their own?

 

I use Git, Mercurial and SVN all the time when working with Leadwerks. Whether I have added a texture, changed the map, tweaked a script or compiled a new exe.

[YouGroove]

Yes, you are right , i just meaned perhaps like Eclipse having some Commit/merge/update buttons or have some tool to see with specific colors map changes by you and others ... but like you said it's more work and not needed.

 

What could be bring in the future for LE3 team work is to have map divided into chuncks or multi map files, replace/add/remove chuncks as you want, people working on chuncks or group of chunkcs, because with one map file only it won't work in SVN as you'll commit all map so overwrite all others work.

[Rick]

From what I've read source control has issues with merging binary formats. Aggror, I'm assuming this all works well for you now because it's just you modifying those files and so no merging is required?

 

This feels like one of those things that you have to experiment with to see what works best.

[AggrorJorn]

I often work on my laptop and computer. Since I switch between these two workstations, I need to make sure the data is up to date. I use Mercurial mostly because it seems to be smarter on auto-solving merging conflicts.

 

Assets, scripts, CPP files aren't the problem. I haven't had any trouble with prefabs, but then again, I barely use them. The .map file is the real issue. I always make sure that I have the latest map file updated to the repo when I am on a different workstation. If not, I have to make the choice to either lose the work I have done on a map, or wait till I have pushed the map changes to the repository from the other workstation.

[Rick]

The .map file is the real issue.

 

Right, and that's what we're trying to figure out here on what would be the best way to handle letting multiple people editing maps at the same time. With Boulder Boy myself and scrotie were in the same file when the project was in drop box and modified different things and lost work. It really seemed like it gave strange behavior as it ended up deleting things that neither of us even touched. Things that were there for a couple saves already.

 

These limitations make it impossible right now to have multiple people working on a map. Relying on, "Hey, I'm working in this map so don't come in" just doesn't work (that's what we tried with this Boulder Boy game).

 

I still think the prefab method would work for now. Each level designer works in their own map file making their section of the map and saving it as a prefab. The "senior" level designer works in the final map by simply combining all the prefab parts to where they are supposed to be but not doing anything inside this final map at all. This way when a sub level designer modifies his map section and overwrites their prefab, the main map would reflect this when reopened. For maps on terrains, each sub map would import the same terrain so they are all working with the same scenery. This would be a little harder as the terrain wouldn't be able to be modified in each sub map. They would have to make sure the terrain is set before working on the other stuff, which is pretty limited in that area.

[shadmar]

if the .map file could be textbased, you could merge the diff only.

Having support for both binary and text based mapfiles would make it more git/svn/merc merge friendly.

Use textbased in developement and binary in release.

[AggrorJorn]

The prefab idea in combination with a master level designer would be the most pratical in this situation.

 

I agree with Shadmar that an open format would be useful for developers. While the binary format is useful when publishing the game.

[Rick]

We should test the prefab idea to see how that works. Would be interesting to see if that works out.Someone would need to make a design of a level on paper. Not it!

[AggrorJorn]

If any, we should make a seperate thread for it.

[Josh]

So LE3 should have the ability to split a map in chuncks, make group of chuncks, import and replace group of chuncks map.

UDK uses Perforce and can work with their streaming system also :

http://udn.epicgames.com/Three/LevelStreamingHome.html

The reason they do that is because of the severe memory limitations of the last generation of consoles. And the minute you have a button on one side of a map that interacts with an object somewhere else, the whole thing breaks down.

 

Valve makes Left 4 Dead maps and doesn't have any problems. Binary data cannot be merged. Even a text-based map format cannot be merged, because objects reference other objects. The map isn't just a list of self-contained objects. This is like complaining that two people can't work on a 3ds max character model at the same time.

 

My point with Unreal is they have a half-solution that still doesn't solve the problem, but it does successfully create more complexity and confusion. I think the normal mode of work should be open your map, make your changes, save it, and commit your changes. If you plan on having it unusable for long periods of time, do a lock on the file so no one else can modify it.

 

Anyway, we've totally hijacked this thread.

[Rick]

Even a text-based map format cannot be merged, because objects reference other objects.

 

Why does that break merging? All entities have unique ID's, which can be referenced anywhere. The map editor can know about all the references of any entity when used as a script parameters. If an entity is deleted it would/should warn that there are references that exist and are they sure. If they delete an entity then it needs to remove that reference as well. Yes, that'll break the map at run-time but I can do the same thing with code so that's not any different.

[YouGroove]

And the minute you have a button on one side of a map that interacts with an object somewhere else, the whole thing breaks down.

 

And that's level designer job to not separate things that must keep together in some Area chunck like some mechanism and it's door.

 

Or he can do safe code programming

Take a mechanism in some chunk and it's door in another :

MyDoor= FindNearEntities("MyDoor")
if MyDoor~= nil and  MyDoor.isVisible() then 
  MyDoor.script:Open()
end

 

Streaming is also to be able to load and unload objects in the fly depending on the chunkcs that are used and diplayed.

Skyrim uses terrain chunkcs with LOD and texture mapping also.

 

 

 

 

 

...

[Michael_J]

Just to interject here,and this may be a tad long as I start to ramble on, as I have experience with this (I was a lead environment artist/Director by profession before moving full time to Rogue System). The "typical" workflow that I've seen used to great effect (if you have the manpower) is to have level "teams". A team is made up of a level designer, an environment art lead, a prop artist and/or texture artist.

 

The level designer lays out the level and builds a very rough, but playable, 3D version of it. When done that is passed off to the lead artist who begins to build out the environment (if you have a concept artist then they get it first, obviously) and the designer begins working on a new area. The team's lead artist starts to assign prop tasks to the prop artist, who sends each finished prop back when done.

 

At ALL times the only person allowed to alter the level itself is the team's lead artist. Versions will be submitted for the designer to check daily. Any changes will be addressed immediately by the lead artist.

 

We even used this approach on rFactor 1 and 2 when it came to track creation. In this case the lead artist (me) doubled as the designer. Once the track ribbon was laid out and placeholder objects put down for buildings and such I'd hand those props off. When the model was done they were passed to the texture artist for mapping and texturing.

 

Point is, in my experience, sub-teams with a clearly defined art and design lead are the way to go. Each is responsible for their section, they manage the assigned sub-tasks, and you only ever have one set of hands messing about in version control.

 

As for using prefabs--3D MAX has something called Xref's. These are other MAX scenes that are linked into a main scene. When an Xref is updated it updates in the main scene. Hence, you can have multiple people working on the same project without stomping on each other's toes (as long as you don't have two people trying to work on the same Xref). In this sense, the prefab idea should in theory work the same way. You have the "lead" artist and designer work on the main scene, and they pass out prop work to others via a prefab.

 

The most important thing (and typically the hardest to achieve) is communication. The lead has to be able to effectively delegate and communicate with the prop artists, and the art and design leads NEED to communicate constantly. There is absolutely NO reason two people should stomp on each other's toes IF they have good communication. If you want to make a change, DON'T do it until you talk to the other person/people who also work in that area. As a lead artist one of my biggest jobs was making sure everyone communicated effectively and that new hires fit within the team. I had no issues in firing someone who disrupted that communication...

[AggrorJorn]

[/font][/color]

All entities have unique ID's, which can be referenced anywhere.

If you both have the same version of a map and both start adding new items to it, those items might get the same ID's upon merging. one way to prevent it would be to prefix the ID's with a hashed username.

[Rick]

@Michael Good info on all of that thanks! I do want to test out the prefab method once I get my PC setup from the move I did. I feel like that'll work and is a good alternative to requiring anything new from the editor. However, there might be some gotcha's with LE prefabs and level design.

 

@Aggror Yeah, I remember Josh saying the entity ID he uses is the memory address that was assigned. ID's, IMHO, should be GUID's to avoid any possible duplication.

[MilitaryG]

How about the risk of it taking sales away from the original creator? I know you aren't saying it should be free, but if it's open source it doesn't stop competitors from seeing how Josh maybe did something to better help their product out which could hurt Leadwerks. Seeing how code works and then adopting it is a pretty gray. Maybe after LE 5 is out Josh will make LE 2.x open source since it would be so old that it couldn't pose issues.

 

Let's be honest.

first of all if community did tell directly to the Unity team they simply ignored them.

 

tell me if they aren't interested in the solutions on the plate why would they be interested in hard digging in code how does it work?

 

I'd say open source would do a gr8 job, meabe create 1000 of new Game editors witch will die and thrive just like Linux.

 

Also not to mention the benefit Josh would get from opensource as if he's interested in getting better code he could easily get it.

 

just like Linux had many features before M$ took them for him self and people claiming it was M$ first, ...

 

well Game Engine development would go even further that way in the world.

 

Open source is the future.

[Rick]

Open source is the future.

 

As long as money is around and the majority of people are greedy, open source will never be the future. I agree that open source "can" create a great product, but it also introduces complexity in picking a product. The masses don't care about the differences between the Linux flavors and don't want to put effort into thinking about it. Can you blame them? They just want to get stuff done, not screw around with the technology.

 

 

I'd say open source would do a gr8 job, meabe create 1000 of new Game editors witch will die and thrive just like Linux.

 

That sounds horrible. People would be spending many hours learning an editor that will just die off in a month or so. Then they have to pick another with the fear that it'll die off eventually too. We already have to worry about this with the game engine itself, I don't want to worry about this with many editors for 1 game engine too. Why would you want that? From a consumer standpoint it's too much choice.

 

http://en.wikipedia.org/wiki/The_Paradox_of_Choice

[MilitaryG]

[/font][/color]

 

That sounds horrible. People would be spending many hours learning an editor that will just die off in a month or so. Then they have to pick another with the fear that it'll die off eventually too. We already have to worry about this with the game engine itself, I don't want to worry about this with many editors for 1 game engine too. Why would you want that? From a consumer standpoint it's too much choice.

 

http://en.wikipedia.org/wiki/The_Paradox_of_Choice

 

actually no it wouldn't be a horrible idea.

and sorry I ment GameEngine editors, ....

 

in Linux you too have to get used to it to know your self around it.

and if Linux isn't stable or people can't get used to it it'll just die.

 

but if engine is sucessfull and made a good move than the engine will thrive forward.

 

also people that get used to engine that dies in a month they don't need to switch they can still use it and make a fork of that editor and make it an improved one that could lead in to heaving the best engine in the world even if it's highly unlikelly.

 

also look around you have so many woman and not even 1 is same witchone will you choose? I guess heaving many engines is same horrible idea as is the reality how many different people exist.

 

If you still think that's a horrible idea than you are living in a hrrible world and I'm sorry that you must lieve among us.

[Rick]

but if engine is sucessfull and made a good move than the engine will thrive forward.

And how much of this thriving translates to money in Josh's pocket because at the end of the day he needs to eat and there is a portion, if people like to admit it or not, of money that drives someone to do something.

 

 

also people that get used to engine that dies in a month they don't need to switch they can still use it and make a fork of that editor and make it an improved one that could lead in to heaving the best engine in the world even if it's highly unlikelly.

 

They could, expect they want to make games using an engine not make an engine themselves

 

 

also look around you have so many woman and not even 1 is same witchone will you choose? I guess heaving many engines is same horrible idea as is the reality how many different people exist.

 

And look at the divorce rate and how big of a pain dating is . If it wasn't for the natural urge to do the nasty, then we wouldn't care about the selection. Programs aren't people so the comparison is vastly different anyway.

 

 

If you still think that's a horrible idea than you are living in a hrrible world and I'm sorry that you must lieve among us.

 

I live in the same world you do where open source makes a fraction of the amount of money as closed source does. Perhaps you don't need money for some reason but I have 2 kids, a wife, myself, and 3 dogs to feed.

 

The main point being there is intellectual property in source code that might just be giving Josh an advantage over his competitors to drive his business. He has every right to make money because of this and to protect it. If it's open source all that is thrown out the window because it will become impossible for him to fight all the people that would steal it as he's just 1 person.

[MilitaryG]

And how much of this thriving translates to money in Josh's pocket because at the end of the day he needs to eat and there is a portion, if people like to admit it or not, of money that drives someone to do something.

 

well that's a different story.

Today as there's non good Opensource GameEngine he can get allot of money for little work.

 

but if he opensource it and he is leading in knowledge and absorbing knowledge from others that did some things would or could even double his profit.

 

BUT if Josh shows he's not that good than the rest of the community people would leave and donate their money elsewhere IF they get good engine enough for them selfs.

 

so how much will he get does depend on him and comminty.

 

They could, expect they want to make games using an engine not make an engine themselves

you mean except?

 

Well I don't want to write my OS either neighter does most of the Linux users but even so 1 new linux is published per month I think.

It's about contribution I would contributre a bit while some others would contribute entire engine to world while reading this software and rewriting it in to totally different perspective.

 

 

And look at the divorce rate and how big of a pain dating is . If it wasn't for the natural urge to do the nasty, then we wouldn't care about the selection. Programs aren't people so the comparison is vastly different anyway.

 

you are probably right, ...

 

I live in the same world you do where open source makes a fraction of the amount of money as closed source does. Perhaps you don't need money for some reason but I have 2 kids, a wife, myself, and 3 dogs to feed.

Well there's only a fraction of open source in the world I think - not entierly sure about that.

We - people do understand other people - devs do need to eat and live just like we need to.

But we won't support garbage.

 

The main point being there is intellectual property in source code that might just be giving Josh an advantage over his competitors to drive his business. He has every right to make money because of this and to protect it. If it's open source all that is thrown out the window because it will become impossible for him to fight all the people that would steal it as he's just 1 person.

You are complettely right there.

he's only 1 person and it would be most unlikely that there wouldn't be found 1 smarter than he is and change the engine in to better opensource one.

 

BUT the community is what does mater and if Josh does help community build troubleshooting stuff and get good graphic stuff from opensource than he would gain win win scenario.

 

His fear shouldn't be today's competetors because there are allmost non.

if he's afraid to make it opensource his fear should be of future's competetors witch will apear.

 

My strategy is to make an opensource game somehow I'll see how will I implement that in future.

[YouGroove]

Well there's only a fraction of open source in the world I think - not entierly sure about that.

We - people do understand other people - devs do need to eat and live just like we need to.

But we won't support garbage.

 

There is only one established : Ogre 3D, it's the same success as Blender, Open source established software, but it took lot of years to grow and become what they are today.

I already seen some gamecreator style 3D engine proposing people to pay to bring features, it has been a failure.

LE3 open source will have lot of chances to go same Torque 3D road, product loosing lot of interest.

Sometimes pricing shows the product really worth something, open source just make engine somewhat abandonned like Id Software open source engines : there is no big AAA coming out from these open source engines, only people playing with them.

 

BUT the community is what does mater and if Josh does help community build troubleshooting stuff and get good graphic stuff from opensource than he would gain win win scenario.

I'm not sure open source to be the key at all ; if Unity works strong with 3D artists specially this is for some solid reasons, if UDK is established and begin to grow in indie games that's also for some reasons.

Graphics only is not the key to good 3D engine.

 

His fear shouldn't be today's competetors because there are allmost non.

if he's afraid to make it opensource his fear should be of future's competetors witch will apear.

LE3 advantages will be full engine features small indie price, LE3 have not ot be afraid as it plays in different areas, like FPS Creator or Dark Basic pro plays in other areas. I think LE3 success will be based on continue bringing awaited features , open editor to plugin system , bring external solution integration like GUI system .... why not lighting system one day ?

So in my opinion only, i would say, open soruce will not be the success point here.

I would even see LE3 rising price to some 400-500$ per license the day it would have solid features/tools/performance.

 

My strategy is to make an opensource game somehow I'll see how will I implement that in future.

Good luck.

[Guppy]

The masses don't care about the differences between the Linux flavors and don't want to put effort into thinking about it.

 

You must be new to linux, the major reason people switch distros is for technical differences - such as default/supported DE, package system and release method.

 

Usually the first reason they switch is the DE - having seen somebody else using something different they liked or simply having too much trouble adjusting to their current.

 

 

As for the whole "omg the software I'm using is dying" - that's the beauty of opensource, you can simply buckle up and maintain it your self ( or use money to make somebody else interested in doing it ).

 

(and yes you can make money off of opensource, there are plenty of companies doing this - hell my dayjob is working for such a company )

[Guppy]

As for competitors stealing the source code, UDK4 has full sourcecode on git hub for $10 - so clearly that's one company that thinks the potential feed back outweighs the risk of theft

[AggrorJorn]

It is a lot easier if you have a multimillion dollar business with more than 160 people behind it. Josh has to do most of the work by himself. I think is pretty amazing how far he has gotten on his own.

 

How about partial opensource? For instance purely the rendering and leaving the editor closed? Or the other way around. Would love to be able to create my own logic for the editor itself.