Developing fan projects is at the moment not a huge thing, because the community is small, but even to me some of the original concepts are not clear (more on that later). Anyway, the game itself is kind of a self-contained micro cosmos where everything is tailored towards the OpenClonk objects, for example all the libraries that make up the Clonk and its controls. Back to the fan creations: These seem to come in several flavors, ranging from "new object/scenario that expands the original gameplay", such as the expansion packs in CR, to "separate game that just happens to use the same engine". The expansions obviously try to make content that is compatible with the Objects.ocd content, or at least they build on its infrastructure. For separate games the infrastructure is useful, but sometimes the code structure seems too confining in some places (e.g. Clonk with lots of assumptions and built-in effects regarding the animations, mapping skins to player settings, etc.).
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?
Update:
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.
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?
Update:
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.
Rewriting everything is a very ambitious project indeed since Clonk has collected so many features over the years. I don't really know if it's worth the cost.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.
Yes, everything that wants to slightly change some of the fundamentals runs into the problem of being hard to code - you have to overwrite entire functions, use >90% of their code and change minor things mostly. Also, I apologize if the first post was a bit out of context: Actually I wanted to create the topic about animations first, then I just happened to note me stream of conscience into a post and made it a separate topic.
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.
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.
![[de]](/mwf/flags/de.png "Germany")
Well, if anything comes from it, I'll at least post some ideas for things that I would change if I'd create the game from scratch / not care about compatibility. Presumably, these can be done in the current engine without writing it from scratch (well, "writing from scratch" is essentially "look at the existing code and copy/rename things without regards to backwards compatibility too much"). Would be cool if we could vote/discuss these individually? Also, is there a way for formatting lists in this forum?
- 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: 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
Ok, so a static landscape does not really do anything except reduce joining time, so it may be annoying but not top priority. Might be useful for some arena scenarios, but in the usual settling game you will want to have a dynamic landscape.
![[jp]](/mwf/flags/jp.png "Japan")
> 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?).
I think the landscape shouldn't actually be the main issue here, because it's already in a very space-optimized format at runtime (I think just two bytes per landscape pixel?). Copying a couple of megabytes of memory isn't very expensive. Additional compression for network transfer could then happen asynchronously on a thread.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.
Regarding "less cool than writing your own engine" - I do not actually want to write my own engine. I'd like to make some significant changes to this one (throw out stuff, or organize it differently) "as I see fit", and re-implement it if there is a need for it, without having to care about breaking things or doing them differently. The problem is, if the result is good then it is hard to bring them back easily, I assume, because the code may have diverged too far.
Doing a separate post here, because this focusses on a different subject: What kind of expansions/genres do we want to support? In previous versions of the game we had:
- 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.
- 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.
![[us]](/mwf/flags/us.png "United States")
> - 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)
I made them quite a while ago. I never made them official since they contained some copyrighted music; but I can try to revive my old laptop and find them.
We have auto-scrollers?
Date 2019-03-09 09:26
Just split up the Clonk into several scripts, waiting for a review on the PR. After that, since there is not much activity anyway, I'd like to go through the script files and make the code style more or less consistent (yes, huge effort, low value most likely, but I like cleaning up things).
Like, *all* the script files in OC? Wow.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
Yes, I also prefer reviews. Avoiding errors is one aspect of it, but the other more important aspect is finding out whether you are heading in the right direction with your changes. This is also the reason why I did not merge the ambient color PR yet. It works, but not the way I want it to work.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
