Leadwerks "opengame" project?

[Guppy]

Inspired by this update by the user "marcus" I had an idea.

 

 

Development of new features in blender is driven mostly by the openmovie projects ( http://www.blender.org/features/projects/ ) the advantage of this approach is that blender gets new features that are not only needed but thoroughly tested and works in a way that makes sense to the users - thus sidestepping the flaws usually associated with interaction designed by programmers . I wonder if it would not be worth doing something similar for leadwerks.

 

The basic idea being you select a group of leadwerks developers who knows their way around the engine / have shown published something with it ( henceforth "the team" ). The team will then decided upon a project eg. a RTS game, and then report any problems or shortcomings in the workflow and/or engine.

 

The leadwerk developer(s) will be monitoring on the sidelines fixing problems as they occur and helping integrate patches.

 

 

Two problems I see with this is that LE being closed source I don't think the team will be able to contribute much in the way of code, and secondly I think there is only one LE developer which could turn out to be a bottle neck.

 

I'd love to hear what you think about this suggestion, even if you just think it's a horrible idea ( but do be specific about the why )

[Rastar]

Actually, there has been something similar for Leadwerks 2.x (I think it was simply called "the Leadwerks community project). I wasn't part of the team at the time, but looking from the outside I think both sides were benefiting from it, and it seemed to influence Josh's priority list. So, in short: I actually think this is a very good idea!

[codeape]

+1

 

Good idea indeed

[Einlander]

Count me in as interested.

[YouGroove]

Not for me, i already beta tested too much LE3 (and continue), and i have my own project elsewhere.

 

+1 for idea and initiative.

[Naughty Alien]

Great idea...I have had such thoughts, based on hope that le2.x will turn to be open source, after le3 was released, so some of us with large codebase around le2.x could push it further, and even extend it as a cross platform, open source comunity project...good dreams..

[cassius]

I would love to see le2 as opensource. Such a waste seeing it lay dormant..

[Rick]

I would love to see le2 as opensource. Such a waste seeing it lay dormant..

 

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.

[Einlander]

If we go through with this, how would we organize? Would it be done by committee? Would people need apply for positions? Or would it be open for anyone to contribute? Can we get away with just having a wiki for it, or do we need to create a forum too? Also how will we share the code? Svn, CVS, git is all nice and stuff, but the map itself does not lend itself versioning. Would everything need to be made out of a prefab and placed into a map so the map parts can be edited externally. And creating standards. There is a minimum square size that the have mesh/csg needs be before the navmesh works, and a minimum hight that can be used for a doorway.

 

We have alot of things that we need to figure out before we start the project and after we start it, but count me in.

[beo6]

There was a Leadwerks Community Project. Not sure what happened with that.

[Rick]

The premise of this project seems more built around Josh fixing issues the team has making the game. This isn't much different than Josh fixing issues anyone has today.

[Guppy]

The premise of this project seems more built around Josh fixing issues the team has making the game. This isn't much different than Josh fixing issues anyone has today.

 

The difference lies in that Josh is closer to the process than normally, a lot of bumps and bruises the is perhaps really easy to smooth out is normally not reported ( automating workflow, etc ).

 

So what's in it for the different parties?

 

Josh/Leadwerks: Shiny new promotional material; production blogs, and a simple ready made game licensees can pick apart and study - also the game it self if released on steam or the like could attract new developers.

 

The team: Self promotion, more direct developer contact and pushing your issues to the front

 

 

Already in this tread something has been uncovered that may not have been thought of before - how do you share a project between multiple parties, other than having a project lead that merges everything manually I don't see a way, so clearly here is some room for improvement.

 

at any rate it's just an idea

[AggrorJorn]

I can only admire if people want to have a go for a community project. Previous projects may not have been the most sucessful, but they did contribute to finding and resolving problems that you would normally not come across.

 

What I learned from the community project from LE2:

• Many people are interested at first but this interest slowly fades.
  
• Not everyone agrees on decisions that are made: game play genre, gameplay mechanics. Sure brainstorming is good but in the end: someone has to make a decision.
  
• No matter the skill or the amount of contribution a person can make: if that person has too much work to do in his personal life and starts failing to deliver, the project starts to break. These person either need to step up themselves and say that they wont be able to deliver or a leader has to be really strict and give the task to someone else. (that is not something very easy to do btw, as this often results in conflicts, arguing and a lot of frustration. Not to mention the work that has been made, often gets lost).
  
• The motivation to keep the team going is crucial for the project to even reaching a playable state.
  
• We started with 30 and ended with 5 people. Too many people makes it uncontrollable to handle.
  
• Preventing lack of documentation, task planning and keeping that planning up to date is really important.
  
• Keeping track of your files: The assets, the code and the scene often got mixed up, were broken or simply were removed. Defining a clear project management system is essential. GIT, Mercurial or Subversion are tools that I would reccomend, but try and keep everything together. We used Subversion with Assembla servers, which worked fine for the code, but was awfull for the assets. Since the assets folder quickly exceeded the 10 GB we needed something else. In hindsight, a private server would have been the best solution, but you do need to have the money and time to maintain this.
  

Anyhow, you can always try and see what comes out. Maybe it works and maybe it doesn't, in the end all that matters is either if you learned something from it or whether you had fun doing what you wanted to do.

[Rick]

The LCP I was leading and didn't advertise all that much was going pretty well until the guy responsible for the map bailed on us. People don't want to let you down and so you get the response of "I think I can get time next weekend" a lot. The question is at what point do you pull the plug.

 

The way I lead the project was:

• I didn't let people vote on what the project was. Not because I was an egomaniac but because I wanted to run it differently than Aggror just to compare how things go.
  
• I broke out the scripting tasks the best I could and made it so people weren't tripping over each other or waiting for each other to do their task. I defined the interfaces they needed to have to all fit together. People didn't know what other people were working on. Again, I wanted people to focus on their task and their task alone. Some found this hard and wanted to know about the other scripts but I felt I kept them just focusing on their script.
  
• I assembled the scripts on the main project.
  

 

After a month or so of being told the map would be done all motivation was lost by myself. It was required of me to make the call to get someone else for the mapping but I failed at doing that trying to give the benefit of the doubt to the guy. I thought things were going fine up until that point. I assembled the scripts everyone made and they were working great with little to no modifications from me. People weren't tripping on each other or waiting. Some people wanted things to be perfect at first but I was more looking for the basic scripts to get things going (rough drafts) but I found programmers had a hard time with that. They wanted to make their first script very detailed and try to get it working perfectly the first time. I feel like artists understand rough drafts more than programmers do.

 

Once the planning is in place the hardest part will be the person/people who fade out and what happens to the tasks they were doing. Since I'm a programmer if a programmer faded I would pick up their slack, but since I'm not an artist or a level designer when that guy faded I wasn't really able to pick up his pieces and by the time that happened my motivation was so low anyway.

[beo6]

Even though i can understand you Rick.

But this is the first time i hear why it got silent about the LCP.

So maybe if you would have gone more open in communication as to why there is trouble we probably could have found a solution and maybe someone else could have been found doing the level mapping and possibly also someone else leading the project when your motivation got so low.

 

i liked scripting for it and at least the asset store benefited from it.

 

What i liked most is the limit you where giving to the people. That prevented featurecreep in the scripts i think and made the release of the scripts faster.

 

So if you ever want to make a new LCP count me in.

[Rick]

Thanks beo6,

 

 

The thing you liked about limiting feature creep is because, I think, I didn't have it so open. The more everyone knows about the project the more ideas they come up with. Ideas are good, but not when you just need to get a certain set of things done. It takes great discipline to ignore ones ideas and focus on just the smaller task at hand. The lack of this can also derail a project.

 

People have opinions and often love to express those and if they feel things aren't the way they like they can and often will bail. I was trying to combat that by giving each person a very specific set of instructions as to what they needed to do so they could focus on just that and not let their work wonder into other things. This worked great for the programmers! They got their tasks finished and I just hooked up their scripts and it all worked great! However, level design, I found out, is something very different. Because level design is not my strength I underestimated it and how to best get it going. I gave the person free reign of the design because I wasn't sure of the design myself like I was with the coding. The design got rather large and I think the idea of doing all that work sort of scared the person away.

 

If I was to do another LCP, good to hear that someone else didn't hate me for how I did the last , I would probably focus first on the level design and getting that going before I'd even talk to the programmers. LE 3.x makes it so easy to separate programming tasks with the scripting system, but level design is just a different beast in itself.

[Josh]

Not that it replaces team projects, but some of the problems described here are things I am trying to solve with this: http://www.leadwerks.com/werkspace/blog/1/entry-1176-building-a-collaborative-content-production-pipeline-part-one/

 

The idea is to break the entire "value chain" down into bite-sized pieces through the use derivative works. If I provide the right environment, I think people will just spontaneously self-assemble into working groups based on merit. Even if they never communicate or even realize they are working together.

 

It will be interesting since this is completely different from looking at things on an individual user basis.

[Rick]

I still think level design is a different beast. The programming and modeling is pretty much well separated so that you can have many different people working on their specific thing and not have to know about what each other are working on. However, with level design that's much harder to do. Only 1 person can be modifying the map in LE at a time so you have to have 1 person do the level design or else you run into issues. This creates a big bottleneck because level design can be big and take a long time. That breaks the small task idea. I would love to have multiple people in a map editing it at the same time and able to see each others edits. This is obviously a large task to get something like that going, but it would allow breaking out the level (that hopefully is on paper first) between multiple people, limiting that bottleneck.

 

I guess one way to do something like this would be to have each level designer work on their own map making only their small section and having them save all that as a prefab, that can be assembled into the final map by the LCP lead. As long as they understand the dimensions for the connection areas this should work. I guess I never thought of that before but that would help break it out and might work.

 

That might work really well actually as when they save their level section prefab each time, the final level that has them all combined should reflect this on open. No refresh needed. This is how I should have structured level design.

[YouGroove]

Uncharted 2 level design : Google Sketchup

Better visualisation than 2D drawing , caus 3D space, scaling- Increadibly easy to use and fast

 

 

 

 

 

Explaining sketchup advantages in Uncharted 2 :

[Josh]

I still think level design is a different beast. The programming and modeling is pretty much well separated so that you can have many different people working on their specific thing and not have to know about what each other are working on. However, with level design that's much harder to do. Only 1 person can be modifying the map in LE at a time so you have to have 1 person do the level design or else you run into issues. This creates a big bottleneck because level design can be big and take a long time. That breaks the small task idea. I would love to have multiple people in a map editing it at the same time and able to see each others edits. This is obviously a large task to get something like that going, but it would allow breaking out the level (that hopefully is on paper first) between multiple people, limiting that bottleneck.

 

I guess one way to do something like this would be to have each level designer work on their own map making only their small section and having them save all that as a prefab, that can be assembled into the final map by the LCP lead. As long as they understand the dimensions for the connection areas this should work. I guess I never thought of that before but that would help break it out and might work.

 

That might work really well actually as when they save their level section prefab each time, the final level that has them all combined should reflect this on open. No refresh needed. This is how I should have structured level design.

I break level design up into props and then map design. You're right that maps don't work as a collaborative thing very easily. This is because objects in maps reference other objects, and there is no clean way to separate them. Even if the Leadwerks map format was ASCII and you merged two versions on SVN, you would have so many errors that would break map logic. Unreal tries to solve this by basically grouping objects into self-contained "worlds" that can't relate to one another, but it's still not really a solution. I remember you guys were using Blender for LCP, and there was a lot of waiting for small things that could have easily be fixed by anyone using CSG brushes. (Of course, LE2 did not have this.)

 

If we're talking about a large outdoor scene, then perhaps storing separate buildings and areas as prefabs is the way to go. But the people working on those sections would lose the ability to easily playtest their work.

 

I think by the time the mapper starts, their job should be pretty easy because they are just sketching out walls and placing pre-made detail props. That's always been the stage that I really enjoy, and it's the only one I can actually participate in with my limited artistic skills. (I did most of the CSG brush design in the AI and Events tutorial map.)

 

3D notations you can use to communicate with other team members are something we've thought about implementing for a while, but of course there are other priorities right now.

[Einlander]

This could be an opportunity for someone to make an entity digging tool that works on the mapfile. Thus is a very little used feature of the source engine. I don't know how valve implements it but I have an idea, provided someone can read the map file and extract all objects/entities from the scene. You would have a master map file. The tool would find all references to models, csgs, scripts, materials and compares them to a new file. When an object in the new file is not exactly as referenced in the old file both objects are flagged and someone needs to approve the change. When all changes are approved a new map file is created with all the changes.

 

I can only propose a solution and not actually work on it currently. I have a bit too much on my plate. And my barricade model pack is almost a week overdue.

[Rick]

The Hero Engine allows for real-time editing of a scene by multiple people without any check-ins by a master person. No clue how they do it. I would think you only let the person who made an entity be able to delete that entity while that person is currently editing the scene, and if anyone deletes an entity and anyone else has it used in any scripts it would warn before deleting.

 

I still think prefabing sections would be a good way to handle this currently in Leadwerks 3. They can play test their area easily enough because they will be working in a separate map file with only their map, in which they could place the prefab of the player in to test. They could even do the overall play testing by opening the master map and playing it, but be sure not to change anything in this master map.

 

Honestly, this is what I would do today if I would have thought about it back then. It seems like a great way to handle the separation. Would just have to find good split points in your map and get the dimensions right for both level designers.

[Josh]

It does sound like you may overestimate the difficulty of map design. With the example map in Leadwerks 3.1, for example, the map itself was probably 1/10th of the art production time. I literally drew the whole thing in 15 minutes, and then Rich dug out that elevator shaft in the main room. Using SVN locks can prevent team members from stepping on each others' toes.

 

If you are using a modeling program then your props and scene are all one big mash of geometry, but with the CSG approach you have props that can be reloaded any time. I remember in LCP1 you guys found out the subway was too narrow and you had to wait for the artist to send another copy. If you had CSG modeling available at that time, any of you could have easily just stretched the hallway out a bit, then checked the map back in to your repository; like a five minute job instead of waiting an extra week.

[Rick]

The map that comes with 3.1 is about 30 seconds long. It's a nice map but way to small. Level design for single player games is a big topic.

[Josh]

True. I wonder if we could load other maps and sort of have them grayed out and locked in the background. Then you could split scenes up into separate chunks that can be worked on.