Page 1 of 2 12 LastLast
Results 1 to 10 of 133

Thread: So whatever happened to the whole PGDCE thing?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1

    So whatever happened to the whole PGDCE thing?

    Looking at the forum, not much since 2014! Just a lack of interest?

  2. #2
    Yep this part is dead for a certain time. At least it was fun while it lasted
    Current (and lifetime) project: FAR Colony
    https://www.farcolony.com/

  3. #3
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    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.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  4. #4
    Quote Originally Posted by phibermon View Post
    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.

  5. #5
    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.

  6. #6
    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.

  7. #7
    I have 15 years programming experience with Pascal/Object Pascal (Delphi and FPC), and never seen nothing that cannot do with this language. I made games, multimedia apps, console apps and database apps.

    I think pascal needs more community support, new developers don't know the power of Pascal and the power of <T>, but I saw a little improvement since 2016 at tiobe chart. https://www.tiobe.com/tiobe-index/delphi-object-pascal/

  8. #8
    I will keep making my engine, not game (chances of success 5%), then will make a proof-of-concept game using assets lifted from OA, then will try making tools (another 15% success chance), then will try making a real game (chances of success 5% again). And only then I will look what could be shared / ported back to community.
    I haven't even created a thread in "your projects" yet, it's that hopeless.

    I admit I tend to create fixes for severe flaws in FPC RTL... Then not share them back because my fixes are too specialized
    Like that one that allows you reach Platinum level of Wine compatibility using fpc 2.6.4 for Win32 Without it you get random crashes on file operations because some crap algorithm seeped into the RTL in the times of Windows 95 and never got fixed in that version (does not free file handles that are less than 5). But why where there's 3.0.2 coming Or the system that solves exception handling in a DLL - but it's too too integrated into my engine and requires the DLL to have a special callback entry point for re-raising Pascal exceptions

  9. #9
    Quote Originally Posted by Chebmaster View Post
    I will keep making my engine, not game (chances of success 5%), then will make a proof-of-concept game using assets lifted from OA, then will try making tools (another 15% success chance), then will try making a real game (chances of success 5% again). And only then I will look what could be shared / ported back to community.
    I haven't even created a thread in "your projects" yet, it's that hopeless.

    I admit I tend to create fixes for severe flaws in FPC RTL... Then not share them back because my fixes are too specialized
    Like that one that allows you reach Platinum level of Wine compatibility using fpc 2.6.4 for Win32 Without it you get random crashes on file operations because some crap algorithm seeped into the RTL in the times of Windows 95 and never got fixed in that version (does not free file handles that are less than 5). But why where there's 3.0.2 coming Or the system that solves exception handling in a DLL - but it's too too integrated into my engine and requires the DLL to have a special callback entry point for re-raising Pascal exceptions
    Uh, why are you still using FPC 2.6.4? It has a large number of known bugs that have been fixed in 3.0.0 and onwards. (Personally I always just use trunk everything for both FPC and Lazarus... the developers are careful enough that the risk and overall rate of "breakage" is quite low.)

  10. #10
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    I think we've made good progress so far, I'm interested in discussing how to cater for many skill levels - it'd be nice if everybody that wanted to contribute had something to work on that they are confident with.

    But there are parts that only the minority can work on immediately.

    But there's no reason why we should wait for the core engine / graphics pipeline to be workable before its dependencies as long as we have substitutes for those dependencies and an abstraction / API that will remain at least fairly constant.

    I propose that parts such as a model loading library could be created before the engine design is even finalised and via a temporary abstraction - be able to render (for the purposes of development) using some existing system.

    In this example the structure/API of the model lib would be abstracted from the host engine so that it could be dropped in to the PGD engine when functional enough.

    Just one idea but anybody have thoughts along these lines? approaches that will let the most number of people start work on something instead of waiting for a minority to develop a framework?

    I think it would be beneficial to identify lines to be drawn so that it's multiple projects, PGD_Graphics, PGD_Resources, PGD_Framework etc - just an idea but I think it has merit.
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •