Forth demo 1

[aiaf]

Hello,

 

Forth demo 1 (community project):

forth_demo_1.zip

 

Below you can read the story.

About the end of 2018 i started a community project (forth).

We got 10 people join, we used this forums to organize , discord, git etc.

Some people contributed only at beginning , so there are actually 3 main contributors: mdgunn, slastraf and me.

 

Organizing was hard and trying to keep a focus.After much discussion a theme + game idea was chosen.

3rd person game with a combination of sf and fantasy theme.

Anyway tried my best with this and things moved along.

In retrospect using voice comms would have been a better solution.

 

Project can be seen here:

 

 

Slastraf was doing character controler and modelling.

mdgunn made a really good design document, and working on the first levels (cryo room etc).

Game drifted into a more sf setting and first person.

 

I learned lot of stuff and different workflows then i was used to , especially on modelling side and editor.

Even with the ruff edges and problems for me it was good times working on this project.

You learn so much more then working alone, so many thanks to mdgunn and slastraf.

 

Some work was done, then slow times also , lack of time and maybe a lack of communication at the moment is semi abandoned.

But the project has really good stuff in the git, so much work went into it.

 

So im releasing a demo with some of the levels for the community.

Its only parts of what we planned in the design document

.I linked the levels in a way it makes some sense, not finished.It contains 4 playable levels.

But it shows some original gameplay and will give you some idea what forth is about.

 

Below some screens

Menu:

ship control room:

VR level

Dream level 1

Dream level 2

Cryo room

 

The cryo room was supposed to be the initial level of the game , but somehow arrived in a state that if you make any change and save it crashes the editor.

I included because is one of the best looking levels, wanted to link it to the others levels, even in unfinished state, but coudnt.

 

For the vr level read the text carefully.Or you will not understand the mechanic that let you pass in the other levels.

If you want to see individual level without following the game sequence use (loadlevel 1 to 5):

forth.debug.exe +loadlevel 1
 

I dont know if we ever finish this game , but i had to do this post.

 

Thanks everyone , this was long.

Hope you like it and any feedback apreciated.

 

[Marcousik]

in the cemetery where never borned ideas are crackling silver dust under your feets, you could walk on tiny fossil bones bleeding out past hope of future memories.

[aiaf]

Maybe, but it was a worthy fight with good results.

[Marcousik]

For sure - just wanted to honor this with a little poetry. 

[Slastraf]

Happy to be a part of this.

As you said, lack of proper communication contributed pretty badly for the state of the project. Text communication is probably the worst of all forms. Voice would be good but the best would be in-person, though its impossible .
Hereby I propose that we could meet on a voice channel maybe discord some time soon.
Lets make more discussion about game design and make a better plan about everything (e.g. code documentation, asset list, map design etc.). 

[Rick]

Just my notes. I initially signed up, but honestly after seeing how the design of the game was taking off I could tell it was just too big of a design to really get completed. This tends to be the biggest issue with community projects, and all projects in general honestly. The scope really started to creep and it became too much to realistically get done by a bunch of random people over the internet.

 

The good thing about these community projects is different techniques get used on each one and little by little we learn.One big issue is working styles. Everyone has such a different way of working and that can make things difficult for a game where consistency across everyone is really needed to make things fit together. When a person is paid well they are happy to conform to a standard, but when they aren't paid at all they tend to just want to do their own thing.

 

The Leadwerks game engine is so open ended and doesn't try to funnel people into a certain way of creating a game and that makes it challenging in a setting like a community project.

 

The one common theme between all of this generally seems to the scope of the project though. When you try to keep the scope down it means you don't need that many people and usually these things get 5-10 people who jump on right away. Then if the scope is small there is nothing to do for most so they fade away. However, if the scope is large then things get out of hand real quick. The larger the scope the more communication needed between people and since this is a hobby and time varies what could take an hour in person if it was a job turns into days and them motivation gets lost and a downward spiral happens.

 

When I tried leading a community project I wanted to try a very different approach to see how that would work. I had a framework for coding that I tried to get people to work within. The idea was each person could work on isolated code from anyone else and as long as the inputs/outputs matched up (I was the one to communicate this between the programmers) things would connect perfectly. The idea was much like lego blocks. As the architect I would determine all the blocks needed and assign the work to programmers. Then I'd connect the blocks of code they wrote. This had various degrees of success but often it came down to people had the idea of the final project and everyone wanted to add their take on it and had an opinion of what should be done instead of what was asked of them. That's the hard part with a community project. Everyone wants to also be the designer as well (very justifiable) but when everyone on the project becomes a designer bad things happen. In the real world people do their role and things work out much better that way. This is true for anything in life big enough to warrant multiple people working on it. If every construction crew member thought they should put their architect skills at work while making the building, the thing would never get done and even if it did, it would look way different than the original design by the actual architect. While the construction crew might think things don't make sense while building, it's their job to build the thing, not question or redesign it. This idea is very difficult with a community game project but I feel is really the best way to do one as it is a best way to build a building. Same concepts.

 

I still think a fairly tight game framework to which everyone on the project works within is the best way to get it done. LE is too open for that at the moment. Yes, it's nice to have a lua script per object, but games require interaction which means scripts need to often communicate. There is no defined way that works across many people working on scripts at the same time. Accessing script variables or methods directly from other scripts leads to issues when those things change by another programmer or aren't defined when you need it. It's best if scripts can be done in isolation and tested in isolation and the communication between then can be hooked up later with minimal effort. It's all about the communication. In both people and code.

 

 

[gamecreator]

Good points Rick.  I once proposed that there be only 1 coder on a group project for this reason.  A reasonably-sized project doesn't really need more.  For example, this project had 10 people join and it looked like maybe 3 people were active near the end.  So 1 coder for 2 or 3 artists is plenty, depending on the size of the group, though I understand a lot of people here prefer to code.

Mostly I think it's important for one person to take the lead, make fast decisions and keep the project moving.

[Rick]

@gamecreator It's a tough balance because being the only coder on a team like that can be overwhelming too. Perhaps 2 coders is ideal but with very clear separate ideas on what they work on. One being player oriented and another world event oriented (this would be the single scripts like buttons to open doors, puzzle things, etc). That would probably work better as they won't step on each others toes. In such a situation the player coder always has the hardest job though. Correct movement (some games can be elaborate in this), inventories (this is a whole thing of it's own), weapons, etc are no easy task to get all done by 1 person. In bigger AAA games each of those things I just listed would be done by a handful of people because they can all get complex and be elaborate over time. I really think an interface for proper communication between these systems is the most challenging but most beneficial thing that could happen to a community project.

 

The fact that still today LE doesn't have any sort of generally accepted inventory system that people are using and tweaking is not good. After all this time we have nothing that is shared by anyone and works well? Go to Unity asset store and type Inventory Systems. There are 54 and a reasonable amount are free. LE has nothing. Aggro tried making a generic one but he found out the LE editor and no universal way of communication between things just makes it difficult to create a good system in LE. It's a shame really.

[gamecreator]

Well, that's another discussion and I agree that there are a ton of ways Leadwerks could improve.  That still shouldn't prevent a determined and focused team from creating something "nice" (though not AAA) in a few months.  And yes, if tasks are divided well then the coding could be split by maybe 2 people.  Jorn/Aggror and I did that for one of the group projects in C/C++ and it worked OK.

[Rick]

@gamecreator What would you say in your and Jorn's experience during that project was the issue (you mentioned it worked OK not great). Just curious on others viewpoints on that topic.

[gamecreator]

I honestly don't remember.  One minor thing was that we were trying to include resolution selection and GUI scaling which I think was a bit too much for a small group project, at least so early in it.  But above all else it was a great learning experience and it taught me that Jorn is waaaaay better than I am at coding.  ?

[Marcousik]

I was speaking about a cemetery of dead games, because I feel sad about great games that gone dead...just like hellraid that promised to be so fun.

I know there are many political and economic reasons to leave a project, but the main question should be why the motivation is going down to finish something that was so promising and maybe exciting?

At which step of the development are the people beginning to doubt about the project? Or loosing the fun it needs to become a great thing.

So much great ideas gone lost, and it is really sad if only money was deciding about this.

[gamecreator]

I think a lot of projects get to a prototype phase where the game starts to become playable and people see that it's not as fun as they thought.  Though I've had a few projects like Run! Jump! Climb! where I was happy with where it ended (especially for a tournament entry).

[aiaf]

I dont think the scope is the problem.

Its how people approach the project.

Say you decide to join, then show your work, even small things done constantly will advance the project.

Its a hobby you only have 2, 3 hours a week to spend on the project, make it count , approach this professionally.

Read the other guys code and always think how your thing fits into what it exists already.

Communicate and leave ego out and be interested to move the project forward.

Meritocracy , your work is good, a way will be found to be included even if a bit different then the game plan.

For artist should be similar, first get the general feeling of the game then contribute, ask people what models are needed or adopt/start a map yourself.

I know its more complicated then this but most of the time the right attitude helps.