So whatever happened to the whole PGDCE thing?

[LP]

[*]The fact that there aren't as many useful resources (game engines, libraries, tutorials) available for Pascal as they are for other programming languages.

I don't think this is the case.

[*]People who keep bitching that there are not enough suitable resources available, like you are doing lately, instead of helping with creation of such resources.

Please don't jump to conclusions. In real life I have done my part of homework. For instance, when offered to give an introductory course to game development, instead of Unity, I've insisted to go with FPC/Lazarus as basic toolset and usually have tried to promote Pascal/Delphi tools during development as much as possible. However, one would be very naive or stupid not to realize that Pascal popularity is not as it once was and since I, among other tools, use Delphi for work and maintain Delphi/Pascal framework, am generally concerned with it.

However, I do see a couple of issues myself, but they are not technical problems. It's not lack of game engines, online tutorials or Pascal resources - for Delphi and Pascal I think there are many resources for almost everything - graphics, networking, security, databases, etc. However, I think it's general blindness on purpose and ignorance for identifying issues that Delphi/Pascal developers tend to have. Spelling out issues is discarded as bitching (as you've just called it) and in overall is received with hostility and rose-tinted glasses.

While money is one problem another big problem is great demographic diversity of PGD members. You see PGD has members from all around the world so it is quite difficult to even get in live chat with other members.

I can't help with demography problem, but I could help organizing an event by participating myself, giving a course, tutorial or a seminar, or even shed some budget for it provided that it would have an appropriate invoice.

If no one needs such framework/engine then where did the idea for it come from? Why are people inquiring about what happened with it?

Because it is a general problem - for an unexperienced developer to start and work on an engine instead of actual game. Except that, this time, this activity that should generally be avoided, was explicitly organized by PGD and performed by multiple developers, only to fail miserably as it always does, because, again, you should be doing games, not engines.

Also what in your opinion would be more meaningful and have higher impact to Pascal Development Game community?

At least in the universities that I've visited, whenever a programming or game development course is given, what I usually see is Java, Unity, C#, etc. When I try to convince the administration to consider Pascal, it is usually met with some eyebrown lifting. I think this is something, addressing which would be more meaningful. How? Well, I think it does require some community involvement, so it means spending (or more accurately, wasting) time on unimportant things... like making yet a new damn engine!

[phibermon]

We do need a modern game engine for pascal - there are a number of people working on the next generation of game engines for our preferred language - Castle for example has matured into an excellent engine and it's getting better all the time. We don't yet have an Ogre3D or a Unity but we're closer now than we ever have been.

But that's not the main reason for a community engine - at least not for me. I wanted to see the community come together and pool its collective knowledge on a large project. Something we can all be proud of, spawn new collaborations. Something that people can learn from and even use in their own projects. It doesn't have to be Ogre3D, there's engines in development right now such as Castle that are tackling the high end - it's not for commercial success or making money - it's to have fun, together.

"Make games, not engines" is fine if you're making small games but isn't going to cut it for large games. I'd love for someone to be able to pick a modern pascal game engine off the shelf and write a modern game but we're not there yet.

I'm personally not interested in making games, I'm interested in making engines, developing new techniques and systems to abstract the game development process. I'm fully aware that engines are massive project and I'm fully aware that many engines fail - I'm not some kid dreaming of making the next quake! I'm a professional developer that's taken on a massive task in his spare time because it's fun to me

But at the same time, "make games, not engines" is the realm of the hobby coder making small indie titles that have access to things such as Unreal and Unity. People still need to render 3D objects, use shaders, utilise collision detection, path finding, steering etc etc

There's still an engine inside every game even if that engine is a one off specifically tailored for the job - there's a clear line between code related to gameplay and the code it calls as an abstraction to get the job done.

I understand the core mentality that the article is trying to get across - if somebody wants to make a game they should focus on making the game as it'll be more productive towards that end goal. It's trying to dissuade hobby coders from reinventing the wheel or writing code that they can't or won't use. It's written assuming people will be writing games in C++, javascript or any other far more popular language where all the tools already exist.

"make operating systems, not compilers" only makes sense if there's already a modern tool chain you can use. Making a modern 3D game in pascal right now, given its available engine/game related resources is like writing Linux in Cobol from scratch - yeah you can do it but the job would be way easier with the latest GNU C++ tool chain.

Almost everybody shouldn't be writing engines - it's bloody difficult and most want to make games so "make games, not engines" applies to them. But *somebody* has to write the engines, develop modern examples with Vulkan, GL4.x, write steering libraries, skinning libraries, asset trees so that people *can* make modern 3D games. Without a Unity, Unreal, Ogre3D etc to start from - that task is monumentally difficult.

Yeah you *could* of released Skyrim using the morrowwind engine and it would of been a good game but not as good as what they did release. We're moving forward, not backwards.

Can we please get back on topic and try an analyse what went wrong with the project so if there is another effort, we can make it work this time.

[laggyluk]

In my case I got side tracked and when came back it was kind of game over already. Also task that I chose (network) wasn't much fun to work on, ended up wrapping up 3rd party library with some higher level logic but then what's the point of network code that is not tightly integrated into the engine? And it was going that way (my lack of knowledge and other devs not considering multiplayer being core engine feature).

If there's going to be another try some time then I think there should be an online road map with general features to implement and detailed task lists people can pick off from. Trello/google docs. Completing small steps gives a feeling of progress and maybe more people would participate.
Of course some big head needs to be able to think things through before such tasks list can be created. Are our heads big enough?

Btw maybe this legendary pascal engine could have some feature others don't have to draw interest? Like built in soft body physics or true voxelness (boxes<>voxels). Of course there is a good reason popular engines share more or less common feature set - probably not enough demand for other stuff

[Thyandyr]

If there's going to be another try some time then I think there should be an online road map with general features to implement and detailed task lists people can pick off from. Trello/google docs. Completing small steps gives a feeling of progress and maybe more people would participate.

This thread is 10 pages long so clearly there is interest. Starting sketching up a roadmap sounds like a great way to start. And instead of listing everything what a perfect engine should have, people could just add what parts they are willing to contribute to and what they wish to see. That way we get easy overview.

I'll start: I have unused domain and webhotel in case hosting is required. Would love voxel related stuff. Can do random name generation unit/voxel stuff.

[Ñuño Martínez]

(...) Would love voxel related stuff. Can do random name generation unit/voxel stuff.

I would like to see something like Ken Silverman's VoxLap engine. I know that nowadays voxel has lost its initial meaning (volumetric picture element) thanks to Minecraft and maybe also Unity and Unreal. I really like that "pixelated" feeling of such engine.

I did a voxlap-style try a lot of time ago in C named VoxRend. I have some success but I avandoned because I messed with maths and I didn't know how to fix it (not long ago I discovered I used different axis and projection for camera, scenary and objects ). I still think I should resume the development (in Pascal, of course) some day.

[Thyandyr]

Voxelwise I'd aim for https://www.youtube.com/watch?v=2vnTtiLrV1w / https://github.com/nothings/stb/blob...voxel_render.h

[laggyluk]

I would like to see something like Ken Silverman's VoxLap engine. I know that nowadays voxel has lost its initial meaning (volumetric picture element) thanks to Minecraft and maybe also Unity and Unreal. I really like that "pixelated" feeling of such engine.

I did a voxlap-style try a lot of time ago in C named VoxRend. I have some success but I avandoned because I messed with maths and I didn't know how to fix it (not long ago I discovered I used different axis and projection for camera, scenary and objects ). I still think I should resume the development (in Pascal, of course) some day.

Yeah I meant something like that. There are attempts at this subject from time to time but so far nothing 'successfull' so I suppose it might not be the best idea to try
https://www.youtube.com/channel/UClz...x9v66YRza5u_Mg

[phibermon]

I think it's too late to start work on a voxel engine now. The future of 3D hardware is essentially an on-chip voxel engine allowing for real-time ray-tracing. Such hardware is already in development by Intel, Nvidia and AMD.

When such hardware is with us, groups of voxels will be fundamental graphics primatives and the way an engine that makes use of such hardware works, will be quite different from current approaches.

We can expect to see the dawn of such devices in around 2 to 4 years and with them we'll see the next generation of consoles making use of them too.

So spending a few years coming up with the fastest way to handle voxels on hardware poorly suited to the task will be made defunct as all the hard work is swallowed up by the hardware and the low level APIs.

True volumetric assets are much harder to create than traditional polygonal geometry - techniques that project and merge surface textures from inputted meshes to define the properties of internal voxels notwithstanding - there's animation and deformation to content with - which is the current showstopping bottleneck of voxel engines. Hardware will have some form of direct support for such operations.

The days of traditional 3D engines are numbered yes but not as much as the days for the current approaches to voxel engines.

It'll be the death of geo clip mapping due to tessellation hardware all over again.

Traditional engines will have slightly more shelf-life - running on older hardware, requiring far less time spent creating resources and potentially being faster on newer hardware for certain types of games (can't see entire planets made of voxels (with voxels smaller than pixels) being feasible for at least another 5 to 10 years)

[Triplefox]

I'm looking at this thread with interest. After spending a lot of time on web games I wanted to do something in native code again, and shopped around newer languages(Rust, Go, Nim, D) but ultimately decided that these factors were important to me:

• Fast compile times
• No, or opt-in, garbage collection(some reference counting is OK)
• Smaller, rational language design
• Good existing tooling and libraries

And FPC's Pascal fits all of these neatly. It's always beat C and C++ handily on compilation speed and ergonomics. There are "nice to haves" that are in newer languages, there are examples of stronger tooling elsewhere, and there's plenty of old cruft in the landscape, but the legacy of Delphi + FPC has actually been very good to the language since it's enabled a strong focus without much fragmentation. In comparison, if I want to do something in Rust, a lot would still have to be done "from scratch" - few or no projects to sample code from, rough libraries, a lot of stuff still being bindings to a C library.

I'm mostly agnostic now to the idea of "all Pascal everywhere", or building a top-notch engine from scratch, or other grand designs. They aren't motivating projects, to me. I think the language is a good choice for the same reasons it was originally good(small, structured, logically organized, easy to compile, some common conveniences and protections). What I mainly want to champion in this thread is the idea that you can make very cool, hip gaming software without chasing after AAA-scale projects.

My own plan for right now is to do some "Crt-only" stuff. Textmode gaming has a perennial fanbase and I can probably build up some libraries out of that. I want to produce libraries in the stb libs fashion: One file, you drop it in the project, and it works. This is actually way more straightforward with Pascal units, but the fact that this has become a trendy idea in C, an environment that is hostile to the concept, speaks to its appeal.

Then I would progress to graphics systems that are API-independent. The trick to that is, the application can address graphics with a high-level custom state machine. That state machine pushes commands on a stack or sets registers, and then outputs lower level API calls to your GL, DX, Vulkan, etc. This is exactly how old-school immediate mode GL talked to the graphics driver, and why it remains so convenient. It's totally valid to build that abstraction yourself when you have a design in mind and you're aiming towards a purposeful method of rendering("make games not engines").

And you can have a series of such state machines that translate a very high level source representation. Think of how canvas graphics APIs often provide a "Pen" or similar kind of state-driven drawing method: You can build your own pen and make it capable of whatever conveniences you want for whatever type of scene you want to draw. You can feed the results of that into a second system and have it process the results, and emit that to the low-level API.

If you extrapolate from this strategy, you can also take the approach of targeting an existing engine with a DLL, and then gradually strangle all the features out of it by moving more and more of them into your own code and eliminating the dependencies. The abstractions you make might not always be the nuts and bolts, but they are great seasoning, and go with anything.

Building up from prototypes is also feasible. This is why I'm starting with the "Crt-only" approach: it will get me to feedback quickly. Feedback is crucial to making progress with anything big, and it's easier to get feedback when you don't take on too much.

Lastly, I'm drawing on examples from other communities. There's the examples of Handmade Network and the PICO-8 community. This former is a dev community that's very focused on "back to basics" coding for efficiency - mostly in C, but not particularly language-focused. The second is about a "fantasy console" with an intentionally retro aesthetic and harsh limits on resources, programmable in Lua, and it's been promoted as a learning tool. I'm also very inspired by analog hardware projects such as the special stage systems Ming Mecca - game-like qualities taken out of the packaging of gaming and turned into a synthesizer instrument programmed with patch cables. These qualities deviate strongly from the accepted norms of what coding - game coding or otherwise - is or should be, and should be taken as examples of the possibility space.

There is lots of potential for "can-do". It's just a matter of finding a good leverage point and leaning on it.