At times I even want to just build the engine from the ground up as a new project, using the existing code as reference - which is not a rant or something I have a plan how to approach, but this game and its predecessors are one of the coolest and most influencing games for me and a huge part of my life. In the current state it seems like the burden of adding small expansions here and there made the engine and the game content "convoluted". Well, maybe this should actually be a different topic. Would such a project even make sense as a fork or something on the main repository? Should I create a topic "OC the next mega cool version" ^^?
Anyway, what I am saying is: this game is cool, I am fond of the community, and I want to break up some crusts. Obviously, it seems more like a dream than something to become reality soon. Ideally I'd want to use the infrastructure that we have here, because it feels a lot better than just "going rogue" and developing something on my own. What do you all think about that?
Maybe it also makes sense to simply make things that do not suit the Clonk style gameplay in a different game engine actually (as Tyron did), but that would also be a bit disappointing.
It is true that especially Objects.ocd when compared to Object.c4d is more tailored towards itself. Even so we tried to make it more open and more adaptable, over the years we added so many intertwining features that things became less modular. Many of these features are either convenience features or systems working together. I don't think that is was the wrong direction to take, however, making additions has became more challenging.
As for things that are a different game altogether: yes, I think those are best made not with OC. Back in the day, Clonk was special because it offered an easy engine to play around with. But with so many game making tools out there, Clonk lost this special flavour.
Well, what sets OC apart is the possibility to have lots of content, different kind of content and it all runs on the same engine, so it does not feel like a different game. In CR there was a scenario that mixed up Clonk Mars and the EKE pack. In other game engines something like this is not as easy to do, because even if you can use the assets of the other games the code and logic behind them may be entirely different.
- File management: Would switch to xml files or just a parseable proplist instead of plain text files for many things: scenario, player file, etc... The downside is that the validations and file parsers for the current files are already there, so this may not be worth the cost.
- Player management:
* Make the player a profile
* Remove crew advancement and crew files from the player file. Having crew management functions (GetCursor, etc.) in the engine makes sense, but things such as rank, etc. are tied to Objects.ocd and should be implemented there
* Access players and teams as proplists in script, instead of having functions
- Game file types
* Replace most things with a proplist that is a separate file at the moment:
+ DefCore.txt properties can be properties just like everything else? Exception may be the ID property, because overwrite/inheritance may be strange with that?
+ Materials could be a definition by themselves?
- Landscape system
* add option for materials to be static, so that the mass mover can skip calculations on those materials - not sure whether this is really necessary, I just recall that landscape synchronization is one of the things that is vital for network games
* implement climates, temperature, material conversion, blasting to objects entirely in script - could be slow, though.
The motivation behind most of these changes is to separate the rules and assumptions from the main game and Objects.ocd from the engine. This may not even be a viable goal, because it makes the engine into a more generic game engine, but we do not even have a community that demands it. First of all it would be to my benefit mainly, but my projects are not played as often either.
Obviously these are changes that would take a lot of time and effort, with unknown amount of benefit, so I'd only go in that direction if we even want that. As Clonkonaut already stated: there are a lot of game building tools out there, why is there a need for us to go into that direction with the engine? On the other hand, the material and landscape system of our engine is quite unique, and the materials look really cool by now.
I am really just throwing around ideas here. Looking at the actual game I'd rather sharpen the existing ingame-systems (they are really convenient and come in handy when you design new structures) and try to sort out some legacy stuff from the Clonk definitions and its libraries, then focus on having the structures have a more uniform style.
>File management: Would switch to xml files or just a parseable proplist instead of plain text files for many things..
Using e.g. JSON would definitely make sense. But as you said, little gain for quite some effort.
>* Access players and teams as proplists in script, instead of having functions
That definitely would make sense! See https://bugs.openclonk.org/view.php?id=1068
>+ DefCore.txt properties can be properties just like everything else?
Would also make sense. I think some stuff has to be known earlier to load graphics etc, but most could go to script.
>add option for materials to be static, so that the mass mover can skip calculations on those materials
The mass mover doesn't do anything for non-moving landscape
>Would also make sense. I think some stuff has to be known earlier to load graphics etc, but most could go to script.
Yes, there may be some properties that should not be modified by appendto/include.
>The mass mover doesn't do anything for non-moving landscape
Hmm, what was it then that caused performance issues or network problems? I just remember that a few years ago the pixel landscape was identified as something that eats performance.
>I just remember that a few years ago the pixel landscape was identified as something that eats performance.
No, that's not accurate.
The massive game state (landscape, objects, script states) is what prohibits re-synchronization in network games (i.e. fast load & save).
Making the whole(!!!) landscape completely static would reduce the game state and could make loading and saving (and therefore runtime join) faster. But the network game wouldn't run much faster in general (compared to a non-network game with the same map).
Of course, a large map always uses more performance that a small map. That has nothing to do with network games, though. And I don't think it's the mass mover's fault
> prohibits re-synchronization in network games (i.e. fast load & save).
I've always wanted to experiment with making the save part a bit more smooth by using
fork(). Of course, that would only work under linux, but that's where the dedicated servers used to run (right?).
The hard part are indeed the objects and the script state because of the extra serialization step and no efficient way of taking a snapshot (aside from forking).
>Would such a project even make sense as a fork or something on the main repository? Should I create a topic "OC the next mega cool version" ^^?
Would it make sense as a serious attempt to fix issues with the OC engine?
No, not at all.
Would it make sense for you for your own growth?
Yes! Definitely! You will learn so, so much by starting such a project. And that will help you for about anything you will do later in your life.
If you really wanted to change certain aspects about the game engine, then the more sensible (but also more boring) approach would be taking a specific part of the game engine (e.g. movement code), understanding how it works, cleaning up and refactoring all the parts that belong to it, and then finally rewriting it.
This is about what I did for the particle system a few years ago.
The disadvantage is that it's obviously less cool than writing your own engine ;)
The advantage is that it actually has a decent prospect of being finished. And if enough people do that in different parts of the engine then this is more than enough to break up some crusts.
For example, changing the mapping of skins to players is probably a rather small project compared to re-doing the engine from scratch
>taking a specific part of the game engine (e.g. movement code), understanding how it works, cleaning up and refactoring all the parts that belong to it
This is what I would do, yes.
>and then finally rewriting it.
If that is even necessary.
Yes, "building it from scratch" was formulated a bit harshly. Actually I want to look at a separate part of the game/engine and have freedom to change it. The advantage of doing that on a clean project is that you do not have to worry about backward compatibility, the other problem is that you do not see when you block some other things that you require later.
- Adventure scenarios and RPGs, stealth games
* these work well with the engine, but do not need most of its features.
* they are really popular.
* these would benefit from buildings that can be entered. We had a concept how to do that before, and I'd like to implement the viewport objects. What keeps me from adding this: I need help how to add a new viewport as a (C++)-object to the game.
- Side-scrolling shooters or action games, platformers
* CR really had a lot of these, and they still seem popular now.
* This comes obviously from the very roots of Clonk, because that is what the first ever games were, and base building was added in later.
- more exotic games
* hex-strategy, or isometric view, board games (chess?). Some of these were implemented in CR, but I would not add more support to them then there already is (they are possible, but there is no special support for them)
Those are mainly games types that I started libraries for. Is anything missing? Also, the adventure and shooter games tie in well with the engine, but usually it would make more sense to implement those in a different engine, because few of them use the mining/landscape changing feature of Clonk games.
> - Side-scrolling shooters or action games, platformers
Have you played the DOOMSDAY scenarios in OC? They were basically auto-scrolling maps where you have to be fast enough to keep up with the scrolling (similar to some levels in Super Mario). For those, I built a bit of a system with trigger objects for events (like meteorites, changing scroll speed, enemy spawns, halt-until-enemies-killed, audio effects, etc.). I think with the new editor and proper props, it would be possible to create a small pack that makes building quick side-scrolling parkours in co-op in the editor pretty easy.
The only disadvantage is that they don't have very high replay value. So you would have to rely on people to build a lot of them :) (e.g. in a contest)
Apart from that when it comes to your merge request: just do it. As long as there are no warnings/errors and a rough playtest on your side shows it to be fine, it's alright. There is no activity for actual playtesting these kind of changes anyway.
And since there is no activity at all, you do your thing. If refactoring old code makes you happy, be happy. It's not something that will rekindle OC however. We'd need a major release with some actual gameplay updates, not unseen behind the curtain code shifting.
>Apart from that when it comes to your merge request: just do it
The PRs have had some activity, though. And having more than two eyes look at stuff is always a good idea
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill