So whatever happened to the whole PGDCE thing?

[phibermon]

I was very excited by the project and some people worked hard on getting it together but there were large disparities in skill level that were I factor I think - the seasoned engine devs difference in opinions aside, there was so much to do and so much to plan and design before it reached a level where there was something for every skill level to contribute to.

It would of been a tiny handful of people working on an engine for ages - a tiny handful who already had engine project of their own.

So the experienced drifted away onto their already working engine projects - the less experienced drifted away because there wasn't much for them to do other than learn how to make game engines - which is what they were doing anyway.

---

I think upon reflection the project needed a working and established engine core to build around, some part of that engine developed enough that there were jobs for people to do at any skill level and somebody to maintain a list of tasks that people could pick up according to size and skill.

In effect we needed gamification of the process of creating a game engine.

[SilverWarior]

I think upon reflection the project needed a working and established engine core to build around, some part of that engine developed enough that there were jobs for people to do at any skill level and somebody to maintain a list of tasks that people could pick up according to size and skill

I strongly disagree with you on this.
You see the main idea of PGDCE was not to take an existing engine and then build upon it but to start creating a new engine from start (that also includes engine core) in order to provide from start to end learning experience for everyone involved.
What PGDCE lacked or should I say is still lacking is a proper design documentation which is written in such way that even those without any prior experience in game engine development would be able to understand it.
But that was never made. The closest that we got were just a few text documents suggesting the basic class structure. Wile design document outlining the basic class structure might be enough for experienced game engine developers to start working on a game engine that definitely isn't enough for people who have no prior experience on game engine development to start any work. Why? Because they probably won't be able to visualize relation of these different classes and therefore understand their role in the game engine as a whole.
That is why (if your remember) I suggested that we instead start making a mind graph which will at the beginning outline all planned modules (the idea was for PGDCE to have modular structure) and which could then later be further extended with more detailed information about each specific module and their mutual relations. But for some reason there was no interest in my idea about creating mind graph as part of documentation.

Any way the second reason why people lost interest in the creation of PGDCE is that at the time when we were still in the process of creating documentation the Castle Engine was published. So many people would rather go making new games on existing engine rather than making the engine itself.
Also at the time user masonwheeler offered a chance to help him continue development of his own partially made engine named The TURBU engine instead.

[farcodev]

Any way the second reason why people lost interest in the creation of PGDCE is that at the time when we were still in the process of creating documentation the Castle Engine was published. So many people would rather go making new games on existing engine rather than making the engine itself.

That is a strong point, especially by this day and age where game engine like Unity and Unreal exists.
Many people doesn't care anymore about what is under the hood.

I don't advocate for these tools, but it is a reality.

[SilverWarior]

Strong point until you find out that those engines does not support features that your require. At that point you realize that adding needed features to such engine can be a verry hard task.
Not to mention that you might be stuck with some bugs that come with those engines.

[User137]

Engine like Unity may actually have so many more features than we can ever imagine re-creating. On top of that they have Microsoft, Google and others as platform dev partners. Direct support for VR, latest graphics card features and so on. Same project running on Win, Linux, Mac, Android, iPad without code changes... At best the own engine is a thing that helps participants to learn about game engines, but it's like tasking 10 people to build a skyscraper when it comes to engine fitting for modern games.

A while back we released this Unity game https://www.youtube.com/watch?v=_fe2KDt7MYE , which had 1 artist, 1 level designer and 1 other programmer besides me. Physics, animations, graphics with shadows and all were trivial to do compared to how i could even imagine accomplishing on a custom made engine. Even something like making a skeleton explode and bones drop on the ground colliding all over the place. And no, nxPascal i code is nowhere near capable of doing any of those. What i really liked about was the animating that's really powerful. The engine allows you to write your own shaders, but what's even more impressive is the user support of thousands of people whenever you don't know how to do something by yourself. You get answer within minutes in most cases.

[phibermon]

That's the point though - full design documentation requires a design that is at least in it's most primitive form - complete. No matter which way you spin it, be it extensive design documentation or a solid platform on which to build - experienced engine devs are still doing a lot of work for quite some time before anybody that doesn't yet have the experience - can start.

Take the imaginary Jane - Jane loves making games and wants to learn how to create a modern 3D engine so she can realise her dream of a game where you play a Amish assassin taking out scientists at CERN.

Jane has created 2D games/demos and has also started to play around with some OpenGL examples and has started to get a handle on 3D projections and piping data to the graphics card.

With all the will in the world, Jane can't yet sit down and write a shader/material sorting rendering pipeline - she doesn't know enough including why sorting by material is a good idea.

She could sit down and start writing an object orientated scene graph and it would work eventually - however her work wouldn't anticipate the hundreds of quirks and uses that the scene-graph must contend with then lots of people start creating new node/entity types that don't run into issues on their own - then one day it's discovered that feature X needs a different approach to handling the scene graph and BOOM all the dependencies and the graph itself have to be refactored.

Emily bleeds in binary and breathes in triangle strips - she could come along and create a scene graph design that anticipates most of it's usage patterns and major refactoring isn't required.

Emily would have to teach Jane an awful lot of stuff before Jane could come up with an informed design.

So does Emily take the months to teach Jane how to do it, holding up everything and everybody that depends on it - or does Emily just write it herself?

----

Either a base-code, complete design documentation or teaching everybody requires already experienced engine devs - it took me years to know what I know and I'd still be more comfortable consulting other engine devs before I settle on designs.

I think a base-code (it doesn't have to be massive) is the best approach - it ensures a solid design and good practices which will filter down by example to the rest of the engine - anybody that doesn't know about some part that is in the base-code can always learn it and they've got the people that wrote it right there in the team to answer questions - also an existing base-code means that Jane can jump right in and apply what she already knows.

Even in large commercial environments - engines are rarely the product of one or two devs - you have people that specialise in certain things - coders that support artist requirements will be masters with shaders and skinning/animation code, somebody will be a mathematics whizz and they'll be handling more complex things such as BSP processing, optimized culling routines etc

For the project to carry on living - it needs active devs of all levels working on it - 20 devs is great but if only 3 of them can do anything for weeks/months, be it creating design documents, base-code or teaching somebody else how to do those things - then the project is going to fizzle out and die.

With a simple basecode then there's loads of tasks for all skill levels - anybody can choose anything they like - if they want to spend months learning what the experience devs are doing and join them? they can - the source is there, they can ask questions, watch it evolve - but if they just want to contribute and learn *somthing* they can do that too - we need a plugin to load a given model format just as much as we need a scene graph.

[SilverWarior]

@phibermon

I see us two have a different opinion of effective learning process.
I'm guessing you are more oriented toward traditional learning where you are simply told what to do and what it "best" approach to do it.
Well I'm more oriented toward exploratory learning approach where you tell people which approaches doesn't work at all and also show them as many possible approaches that work and let them decide which approach is "best".

You might have noticed that I always write best in double quotes. I do this because in programming there is no best solution that would fit everyone. Best solution actually depends on many things like compatibility with existing code and coding style, current programming level of individual etc.

I'm willing to bet that if us two get into discussion of how base code should look we will both have different ideas for it. Why? Because each of us is probably thinking about different scenarios to use that base code in not to mention that each of us probably have its own preferred coding style.
Only by working together could we design base code that would be most suitable for both mine and yours usage scenarios. Same goes if we want to make this base code to me best suitable for everyone.
That is why I feel we should allow everyone interested (even those with no prior experience of game engine development) to also be part of the base code development even thou they might be just watching it being built.