What stops us from reusable code?

[Rick]

So many people are creating their own systems which are duplications, to some level, of existing or in the work systems. There are like 5 people doing pathfinding (I've even had something in the works but haven't posted anything yet), a number of people have 3rd person control code out there (guilty), and a couple are making GUI's (guilty just never posted).

 

Seeing and participating in this situation I can't help but take a step back and ask the question "Why can't we as a community share our code better?" This isn't me judging anyone, it's me simply thinking that things could be done better and more efficient if we were able to share things easier. Many attempts have been made to do this with failure, but has anyone looked at why these have failed objectively? I can't help but wonder if we did we might be able to see why it hasn't worked up until now and possibly come up with a solution.

 

I think as it stands most people are thinking LE3 will solve this problem, but I'm skeptical about that. I feel like one of the reasons we can't share code/components today is the vast amount of supported languages. It segregates the community, and from the sounds of it that's not going away in LE3 so why would we think the problem (I see it as a problem) will go away?

 

If your goal is to make and finish video games and you are a 1-2 man show, it would seem logical that the most EFFICIENT way would be to piece together commonly used code/components. Sure you might have to tweak the code some to make it work, but that basic interface that all the code plugs into together has to be there first. Once that's there, tweaking the code of some specific functionality is still possible and encouraged. Clearly you'll still have to code some components yourself because they'll be unique to your game and you wanting to share those or not is up to you.

 

So why can't we agree on at least a couple main systems if not just 1? Curious to hear your thoughts.

[Clackdor]

Good post. This is something I would definitely love to see from the community. I often find myself writing something that I know has been written countless times before. I will definitely be scouring the community for usable code for pathfinding and GUI. 3rd person character controllers are something I preferred to dive into myself and its not in any real condition to be published (though you may inspire me to do something like that). Here's a few thoughts:

 

Regarding Sharers:

 

1. Preparing code to be reusable for the community is a chore. Documentation, flexibility, etc are all things that you must consider when sharing your code, whereas when you write it for yourself, the lazy among us (everybody) can take shortcuts.

 

2. How do you share something? DLL? .h and .c++ files? What about everybody in the community that uses other languages?

 

3. We aren't a charity. This sounds somewhat selfish, but what's in it for me if I give out my code? For some, a stronger community is good enough. For others, making a few bucks or at least getting a credit line is better.

 

4. Testing. Can you rely on the community to test your code to make it better? This would seem an obvious answer to question posed in item 3.

 

Regarding Users:

 

1. No assurance that the code is complete. Gotta add this one little thing? Oh, well now you have to dive in and really understand what was written because everything you try breaks it. "It would have been easier to write this myself." comes up a lot, I bet.

 

2. Lacking documentation. This can range from outstanding to non-existant.

 

3. Where do I find things that have been created already? Can I know what others are working on? What state is the asset store code in?

[DaDonik]

I think Clackdor pretty much summed it up.

I'm a one man show myself (regarding the coding part) and the main things that stop me from releasing any code are:

1) Much of the code is interweaved to some point and it's not possible to give away just a part of it.

2) I really have no time to give much support for the ppl that would use my code

 

My personal opinion is, that LUA model scripts are pretty much the only thing we could really share with each other.

But then again someone might have set additional global objects (SetGlobalObject()) which not everyone has. That

leads to problems, especially for new users or programming newbies.

 

Someone should maintain some kind of game frame, where everybody can add classes, scripts, ect. that would then

get tested by that person and included to the game frame. That would be sort of a fulltime job...

[Rick]

OK so some common obstacles to overcome are:

 

1) Code generally/possibly not created in a modular fashion to be independent of other parts.

 

2) Creators of code don't want to spend the time to support it.

 

 

So if anyone wants to brainstorm with me on possible solutions to those 2 specific problems that would be great.

 

1) There is no doubt making your code modular is tough. Often times like noted above laziness will prevail and we'll break the modular design to get something to work because it's easier than finding a modular solution. I can't help but think that if a common design philosophy was encouraged it would help people think a different way to solve their problems. A way that could be more modular. I'm no means a design pattern expert but does anyone have ideas around this area? Another plus side to this is that reading code that all follow a certain design philosophy should be easier.

 

2) Maybe as consumers of the code we shouldn't expect direct support from the author? If the code is free then I don't think we can expect support, but if the code costs money I think it's fair to expect support. The downside to this would be if the code is bugged OR doesn't do exactly what you want you might have to get into the code and fix it yourself. The question would then come up around how do you push that fix or change to the asset store in a fashion that either overwrites the "bad" code or let people know about your fix. The good is that making said change should be easier given number 1 above.

[Josh]

The game framework sounds great but once you reach a certain level of complexity, others can no longer modify or extend the code. Remember my framework code? Then you are simply maintaining an open source game and taking feature requests. I'm putting all my hopes into entity scripts for future shareable code. C++ will never produce shareable code because the cost of adding code into a project is high. I don't think I have ever added a single c++ code file into a project. It's always a mass of interconnected classes. With lua in the new engine there is a predefined standard scripts can use to communicate and integrating new code is easy.

[Clackdor]

1. I think there needs to be an incentive to contribute to the community. Not just code chunks, but wiki articles on LW commands, tutorials, etc. One thought is to have the incentive be "recognition". This idea may require a little more hands on management of the community part of the LW project. Say, every two weeks there's a front page article (I think the front page is underutilized) that is a member feature. Highlights the LW user's story, their project, and contributions to the community. Feeding somebody's ego can get you results. Main point: incentives for contributing.

 

 

2. A key resource would be for somebody to write a guide for contributing code. What is expected from the contributor? ie:

• This is a player controller
  
• This was written in C++
  
• included are a .h and .cpp file
  
• link to tutorial for integrating into your project
  

or something.

 

As far as ongoing support, I think you can lean on the community for this. Those who have used your code will be able to help you support it. Original writers should not be stressed out about supporting their code. This has the unfortunate effect of meaning well written and documented code will be more popular and therefore have more support than poorly documented code that may do something really cool.

[Rick]

C++ will never produce shareable code because the cost of adding code into a project is high.

 

I believe the cost is only high because you haven't defined a framework to be followed in C++ like you are doing in Lua. The cost would be the same in Lua if you didn't have this framework because you run into the same problems.

 

I'm not saying a C++ framework is something that should be required for people to follow, but if it was there and robust enough I bet a good number of people would.

 

You've taken the giant complex task of game objects and in Lua you setup a system to have them broken out into small code snippets that can be combined via the editor. That doesn't have to be different in C++ just because it's C++. I can still make a class in C++ that JUST rotates an entity just like you'd have in Lua.

 

Would be nice if the framework system like this is available to all languages and the same or very similar with all languages. Might make code reuse between all languages easier as they would be in the same kind of "format".

 

This sort of plays into topic 1 of a common structure.

[Roland]

If I could stick in with a personal reflection. In order to overcome the troubles with different languages each contribution of a compoment in such a shared environment would have to be self-contained DLL with a C-API interface. How and in what language the content is written would then unimportant as long as its self-contained and exposes it self in form of a C-API. Such a DLL can then with suitable headers be used in all languages, C++, C#, VB, Lua and so on, without having to change anyting in the component, and the language or programming style used internally in the component is of no importance to the end user. Such components should be fairly limited in what they do (not a whole framework).So here is my view on what such a contribution should look like.

 

- Component name

- Author

- Description

- Exported C-API documentation

- Examles of usage

- Source code for generating DLL

- Additional headers for other languages (.NET, LUA etc )

- Revisions

 

Such components could the be used, reused and puzzled together, and imported to any language.

[Rick]

I believe each language would still require some glue code to get those working though. Which I think adds complexity and doesn't make it very plug and play.

 

I think the support of multiple languages helps individuals but hinders the community. It splits the community in more than just forums It does it with code sharing as well. We have 3 major languages for LE: BMax, C++, & Lua. People generally make their libraries or code snippets for only 1 language. That's not good, but you can't expect people to duplicate their code for 3 languages. We end up with either the same general thing done by 3 different people in 3 different languages (not very efficient) or something amazing in just 1 or 2 languages.

 

We are all fighting the same battle with different guns but we can't exchange bullets.

 

I don't see Josh dropping to 1 language because it'll most likely hurt his customer base, but it's a pretty decent problem that most other engines don't have. Unity supports 2, BUT you can use them together without doing anything special, which makes integration issues non existent.

[Pixel Perfect]

Its been an interesting read so far from Ricks original 'ask the question' to Clackdor's response which highlighted some key points to Rolands suggestions for a common DLL interface (almost DBPro style).

 

In my case, my decision to design my own game engine framework and components rather than go down some common framework type route has been for the learning exercise. If you really want to learn the art of game engine design then it's almost a prerequisite to read up on the current techniques, design your own component parts and write your own engine. Not because this is necessary ... it is possible to have a common framework and plug and play type functionality, but simply because to be a good games programmer in the future and get the most from your current engine you really do need to understand the concepts underlying the component parts and how to code that functionality. It gives you a foundation that is invaluable and allows you to interface with others on a level you would not otherwise be able to do.

 

There is nothing wrong with having a common framework and interface, in fact its almost essential for people not in a position to build their own. But it takes a lot of work to develop such systems successfully and people should be prepared to pay people for providing this. Open source software and the expectations it brings has to some extent degraded modern programmers into people who are almost expected to provide for others the things they are not prepared to do for themselves or prepared to pay for. I know of no other situation in life where people have such an expectancy of getting something for nothing.

 

I'm not against a common framework and component interface, but it will always have its limitations and the providers need to be suitably motivated to put the work in to produce it. It would undoubtedly bring about a much more productive community in terms of game output though.

[Roland]

 

I believe each language would still require some glue code to get those working though. Which I think adds complexity and doesn't make it very plug and play.

 

I think the support of multiple languages helps individuals but hinders the community. It splits the community in more than just forums It does it with code sharing as well. We have 3 major languages for LE: BMax, C++, & Lua. People generally make their libraries or code snippets for only 1 language. That's not good, but you can't expect people to duplicate their code for 3 languages. We end up with either the same general thing done by 3 different people in 3 different languages (not very efficient) or something amazing in just 1 or 2 languages.

 

We are all fighting the same battle with different guns but we can't exchange bullets.

 

I don't see Josh dropping to 1 language because it'll most likely hurt his customer base, but it's a pretty decent problem that most other engines don't have. Unity supports 2, BUT you can use them together without doing anything special, which makes integration issues non existent.

Rick

 

Of course I don't know every detail but ...

• 
   
  
• BMax can export to DLL's with C-API, it can also import such DLL's
  
• C++ well thats obvious. It can both export and import
  
• LUA can load C-API DLL's. It cant export such things though, but on the other hand C++ can call LUA routines.
  

 

That seem to me that my suggestion could be realized (of course with some work and research).

As I'm a C++ programmer I would be perfectly ok with just C++, but my suggestion would work with them all.

 

Well.. I will not argue. This was only my suggestion and probably nothing will be done until LE3 anyway because we don't have a clue if everything has to be thrown away then. But that would not stop intrested individuals to make some research about such a possibility.

 

Pixel

As I wrote a complete framework won't be any success. To be used it must be small components that can be used in any program or framework.

[Rick]

LUA can load C-API DLL's

 

It can but there is some glu code specific just to Lua that has to happen for lua to use it from my experiences. I don't mean to argue either and often the devils in the details, but it for sure is a possibility and probably the only possibility if multiple languages want to be supported.

 

 

It would undoubtedly bring about a much more productive community in terms of game output though.

 

At the end of the day for someone in Josh's position, that's all that really matters. I think he's shown his concern about the lack of games being made so he cares about it, but enough to make drastic changes to promote it? It's asking a lot and a risk, but how long without having a "successful" game title released with said engine is the engine not take "seriously" for game studios? This is a general question I would ask anyone making a game engine and in no way aimed directly at Josh, but hard questions have to be asked at some point. LE3's scripting attempt is probably the 2nd or 3rd attempt to promote something like this. If it works and solves all these problems then that's great. If it doesn't, at what point do you think separating the community because of language and lack of component framework is to blame?

 

 

Pixel's response is very valid and as it may have been assumed up to this point that this code would be free, I don't think it's the assumption that should be made. I believe people are willing to pay for code (I've gotten paid on this forums to do small code work). The LE community would be less likely to buy Pixel's hard work because he had to make his own structure and chances are to fit that structure into another structure is probably painful enough where people wouldn't spend the money to get his code. That's a shame and of no fault of Pixel's. If LE supported a robust design with all languages or just 1 supported language, Pixel may have been inclined to fit his code into that design, which would have the added benefit that he could sell his code later to the LE community. People would then be more willing to buy Pixel's code because they know it fits the LE design and can be plugged in without trouble.

 

If you provide a marketplace that supports structure and support, people are more willing to follow your rules to sell things for it and buyers feel more comfortable giving money to buy things. Think of a grocery store. A farmer wants to grow cows because he knows the grocery store is a place where a bunch of people come to buy his beef. The grocery store has rules, structure, and support around quality and such so consumers feel more comfortable buying beef from the grocery store than some random farmer. Topic 1 above is around this entire premise.

 

good game programmer in the future and get the most from your current engine you really do need to understand the concepts underlying the component parts

 

I would challenge that to understand the basic concept of the underlying parts doesn't mean you have to have actually coded them. Many of us use shaders every day in LE and many of us understand the basic idea behind them, but many of us have never really coded them. Clearly it would benefit us to know how to code them as we could do amazing things, but if someone else does that and we buy and use them, are we considered bad programmers or lazy? If that were the case we would all lazy because we are all using Josh's shaders. If someone wants to do the coding for learning then clearly nothing wrong with that but I won't fault or judge someone who simply wants to buy and use instead.

[Pixel Perfect]

I would challenge that to understand the basic concept of the underlying parts doesn't mean you have to have actually coded them. Many of us use shaders every day in LE and many of us understand the basic idea behind them, but many of us have never really coded them. Clearly it would benefit us to know how to code them as we could do amazing things, but if someone else does that and we buy and use them, are we considered bad programmers or lazy?

The context in which the quote was taken was very much the context of designing one's own engine and coding it in order to fully understand it and be able to refine and alter it with ease. Sure its not necessary to code the component parts, but what happens then when you need to alter something. It's a different approach that's all. We all compromise somewhere, I have not attempted to write any of the rendering code preferring to leave that to Josh's expertise, but then I'm totally dependent on that functionality and cannot easily change it.

 

I'm not sitting in judgement of anyone here or of differing approaches or techniques. But I have seen these same suggestions time and time again in many forums and they rarely succeed unless the vendor provides the framework for this themselves, unity being a classic example. In that I'm in total agreement with you Rick.

[Roland]

The game framework sounds great but once you reach a certain level of complexity, others can no longer modify or extend the code. Remember my framework code? Then you are simply maintaining an open source game and taking feature requests

 

After have reading though this thread once more I realize that Josh has a point in what he is saying. Its hard to give up personal styles in favour of some common shared one.

[Rick]

But I have seen these same suggestions time and time again in many forums and they rarely succeed unless the vendor provides the framework for this themselves, unity being a classic example.

 

I agree, the chances of a community coming to some agreement on such topic is most likely not going to happen. I don't expect we'll come to an agreement on a structure, I just want to explore the reasons why it's an issue and have them written in stone for everyone to think about, Josh included. I think it's always nice to have it in black and white in front of people to get their gears turning on the subject. I also agree the vendor has to be the one to support the structure. Note I didn't say force, just support. I would fully support LE still being open like it is, but I would also support a common game structure and component interface even between the 3 major languages although I'd personally say 1 language would bring more benefit for the community as a whole. Even if that language was BMax (which clearly I'm not a fan of but for me the realization of separation because of languages is bad).

 

 

After have reading though this thread once more I realize that Josh has a point in what he is saying. Its hard to give up personal styles in favour of some common shared one.

 

I agree 100% on this too. It is hard, but sometimes the right thing is hard ya know.

 

I recently ran into this. For GvB I was making my own GUI even though I knew Josh had a Lua GUI out there. I spent a ton of time on my GUI but because I wasn't doing gameplay programming my motivation was dropping for the project. I realized this and just yelled at myself and forced myself to use Josh's Lua GUI. It took some time to get used to it and I certainly don't agree with every aspect of how he structured it and I made enhancements to it and extended it with more controls and that took even longer to figure out because I had to figure out the details of his system. At the end of the day it saved me time though and was more efficient and kept me going from seeing results faster. It was hard, but it was worth it and in terms of seeing results and continuing with the game it was the right thing to do.

 

So maybe this is number 3 on the list.

 

3) It's hard to give up personal style. Or perhaps it can be thought of as ego. Good or bad.

[Roland]

You are a wise man Rick

[Rick]

I don't consider myself wise as I have many faults I just really want to see the community come together to share code (free or paid) so we can all get some games made. From my perspective this is a big issue for this community.

[Clackdor]

I don't know how to ask this.

 

Is it really necessary to conform to a rigid style as is being suggested? Everybody has a style, but that doesn't keep us from using LeadWerks, or RakNet or whatever. I would consider our code blocks to be much simpler forms of those libraries. Perhaps that assumption is where I error.

[Canardia]

I think the best libraries willl come when someone publishes some games (free or commercial) made with it. Then everyone will be like, omg how did you do it, and he just says "I used my library".

[Rick]

Is it really necessary to conform to a rigid style as is being suggested?

 

I don't think it necessary, no. I'm observing, more recently in the last 3 months or so, a huge number of people doing the exact same thing in different languages or slightly different ways. As a programmer you would never copy and paste chunks of code that do the same thing all over your project. You would make a function or class and use that instead. So when I see what has been going on and is going on in LE, and I see what some other engines do, and benefit because of, I know it can be done more efficiently and more importantly it promotes games to be completed.

 

There is so much talent in the LE community but it's being spread out. That does the community no good and it means games aren't given their best chance to be completed. So I raise the question to see what people think about the situation.

[Naughty Alien]

..sharing is good, best things in life are free things..im happy to see my bmax community here happy with small contributions i have made, and im going to expand it much more ..however, I also believe that there is no harm and that its good if i share for free my libs with no source code, so other people could make their steps easier...i dont think that absence of source in freely shared libs, is bad thing..far as im concerned, if anyone reach stage of development and using my libs, where is necessity to have a source of lib for sake of future game maintenance..Ill email it to that person..no problem..free of charge, and with maybe lil tiny place on credit list, but even that is not requirement..but before such stage is reached out, I see no reason to give away source anyway...simple as it is..

[Rick]

I don't fully understand where you are coming from with that but I respect it and so it seems a valid reason for number 4.

 

4) Don't want to give source code for components.

 

 

So in the form of DLL's for components as Roland suggests this would work and satisfy your requirement. I'm assuming you can make DLL's in BMax and use them in C?

[Naughty Alien]

..iii..im not sure what you mean, but yes, I can extract modules in form of DLL's and thats what Im about to do once finish my tutorials updated (right now few basic functionalities introduced) , Ill provide proper DLL counterpart of same lib with same commands as in tutorial, and it will be totally free to use by anyone (except selling it as independent product of course ) ..

[Josh]

I believe the cost is only high because you haven't defined a framework to be followed in C++ like you are doing in Lua. The cost would be the same in Lua if you didn't have this framework because you run into the same problems.

What I mean is that in C++, you have to include headers, add .cpp files into a project, then you usually have a lot of dependencies, macros defined in the project, and probably some other things I am leaving out...if it even compiles on all platforms, which most code does not. I have never once in my life included a single .cpp file in a project. The only times I have incorporated other people's code was as a whole library that performed some self-contained task, or very occasionally a single function I rename and change the syntax of. The hardest programming I've ever done was trawling through the Recast source code.

 

I'm not trying to discourage you. I think you have much better chances of achieving this with Leadwerks3D, since it has more built-in functionality everyone can count on acting the same. It's like graphics APIs. Without OpenGL, things would be a mess and no one would work together, but because there is a common standard that can't be altered, programmers don't have to keep implementing the same things and can actually share OpenGL examples.

 

Pathfinding and AI are normally a big system that interacts with lots of different parts. Guns shoot enemies, paths have to be loaded or calculated when a map is loaded, AI has to interact with the path data. Leadwerks3D simplifies that gameplay subsystem so now everyone can rely on those commands. If I can reduce the size of a Leadwerks3D C++ project, so you can do something like Left 4 Dead in a couple hundred lines of code, then we're going to see a lot more sharing and cooperation, notwithstanding the Lua aspect of it.

[Road Kill Kenny]

If I can reduce the size of a Leadwerks3D C++ project, so you can do something like Left 4 Dead in a couple hundred lines of code.

 

Lol. FPS Creator XO. hehe kidding