What I'd like to do is to experiment in regards of the modernizing the engine and remove legacy stuff, changing things as I see fit without having to wait for pull feedback or caring to much about all scenarios working. Sure, it is a lot of effort and it is unlikely to go anywhere except nirvana, but it is still worth a try. Is the best way to create another github account and fork the game, since I already have a fork with my main account?
Ideally I'd like to:
- do my changes on the side without breaking things in the *real* OC objects and anything on this site or possible releases of OC
- be able to merge the changes back, if the effort was fruitful
- not create a "rival" or "competitor" with a different name
- separate game engine and game content into separate projects (this also has its drawbacks, of course)
On a side note, the release button from https://wiki.openclonk.org/w/Release_Steps is gone. I looked that up, because it occurred to me that I don't even know how to release the game or what the modalities are. Even more so, now that I roughly know what to do, I wouldn't know who else has to agree to a release, and so on.
Update: See also https://forum.openclonk.org/topic_show.pl?tid=3472 for reference, also a reminder for myself.
If you just want to change/modernize stuff just for fun or for the learning experience then that's great as well, of course!
I still think the effort would be most fruitfully invested into the movement system (not getting stuck anymore) or into the mod system (Larry, to recruit new people).
And for the "how?": Yes, just use your fork on github.
If you have nothing in there anymore, you could even delete your fork and fork the repository again.
And then, it would still make most sense to create a different branch for your changes. That makes it easy for you to pull any official OC changes later or even cherry-pick some changes into your fork/master and then synchronize fork/master with openclonk/master. Then you can work normally and have a workflow as everyone expects it and as you would have in a "normal" company as well :)
If you want, I can explain that in more detail.
>- not create a "rival" or "competitor" with a different name
Noone would be mad at you if you did some changes and release the game as OpenClonk Marky Version or whatever :D That's exactly what our license is for
>- separate game engine and game content into separate projects (this also has its drawbacks, of course)
Do you have a good reason for that? Because yes, it does have drawbacks and in other projects I always found it to be very annoying.
>Heyo Marky :) If you want to change stuff about the game, I think the best approach is always to ask oneself what is best for a player. And if you don't know, then it's always helpful to watch videos on youtube from people playing OpenClonk and see what they are annoyed about. And then try to tackle that.
I am actually thinking about re-designing a lot of stuff and I am aware that this is likely to fail or be too much effort in general. At the moment we carry around so many things and sub-systems with sometimes very intricate rules that sometimes do not even make sense for the current game or make things more complicated for mod developers.
>I still think the effort would be most fruitfully invested into the movement system (not getting stuck anymore) or into the mod system (Larry, to recruit new people).
I agree :D
>Noone would be mad at you if you did some changes and release the game as OpenClonk Marky Version or whatever :D That's exactly what our license is for
It would still create one more thing to keep track of, no?
>Do you have a good reason for that? Because yes, it does have drawbacks and in other projects I always found it to be very annoying.
It would allow including the engine as a submodule for the larger mod projects or allow a different setup. On the other hand one could also use the game content as a submodule (yes, they are annoying). Well, maybe I won't do that after all.
We heavily underused the engine by having it just render single models into a 2D environment when it is intended to provide full 3D realtime scene renderings. Which also meant that options the engine could provide potentially crashed OC or lead to the models simply not displaying. We also spent years to tie the different graphic engines together and ended up with Frankenstein's graphics; a 2D landscape, 2D sprite graphics (sometimes with bump maps), 3D models rendered outside the game and being inserted and on top of all that a basic lighting and shader system that always tried to give everything a somewhat not-Frankenstein look. It never really worked and the whole game looked mashed together, with frequent errors in lighting, shadows and fog of war. I do think this hurt the game as new players always got the 'it is still a bit rough and weird' feeling.
A complete overhaul might just commit to a fully 3D environment (or revert back into a fully 2D one). If the landscape and all the objects are done by the same engine, lighting problems are probably less bad, writing shaders to really tie things together becomes easier and certain features will not have to be coded multiple times for different systems.
Maybe OGRE would still be okay in that case. What we also failed to realise is that OGRE did not give us the support we had hoped. We had hoped that by using a semi-popular engine, we get all the modelling workflow for free. We did not, however. While it looked promising in the beginning that one could download an export plugin for Blender, this was false hope. It seems that OGRE is less interested in providing what we needed: a simple 3D model format that people can quickly craft, export and use in a game. We only ever had this one, fairly broken Blender exporter and we still had to manually edit the models afterwards, to remove all the features that OC does not support (or you as the designer are presented with lots of warnings when firing up OC). In order to properly use OGRE, you will probably have to first define your workflow and write all the necessary plugins for 3d modelling software yourself. We failed to do that and therefore over the years many 3d artists we had became very frustrated. We could not tell them how to do the models, what polygon counts, how to rig the models, how to animate or even what Blender features to stay away from as they will crash the exporter, crash OC or simply not work. It is impossible to use a proper set of predefined materials in your 3d models and thus every new artist was confronted with the task of tediously creating textures with little to no guidance in what to do or even what colours to use. The .material files are mostly filled with unused values because OC somehow invents its own way of doing materials.
OGRE is certainly a powerful tool that we never used. We do not have the proper toolset to offer. Maybe there is an alternative that provides what we needed: a simple way for 3d artists to create models and have them display in the game without hours of redoing because they clicked the wrong button in Blender (not that we still have 3d artists left at all).
Furthermore I looked into cocos2d, which also supports 3D models, but I disliked that it uses yet another custom 3D file format.
What I miss more in terms of file formats, etc. is a central point that loads a definition/group entirely. The way I understand the engine is that it somehow loads the definitions upon opening a scenario, but it still reads certain things on demand, such as graphics, meshes. Ideally I want to have a function that loads an .ocd file and tries to get a graphics resource. Loading the resources would be delegated to some instance where parsers can register and translate (potentially different) file formats into the internal 3D format.
I figured that applying a marching squares algorythm to a 2d array that represents the landscape would result in too many vertixes. To reduce the complexity of the mesh, I tried building a quadtree from the 2d array first, and then create a collision mesh from the quadtree. I really had problems finding a suitable way to generate the quadtree though.
Many tutorials on quadtrees implement them by having extra classes and methods for building blocks of a (sparse) quadtree, but such a implementation turned out to be too slow.
Early on I decided to represent the landscape not by a single huge 2d array, but by tiles of 64x64. But anyhow, generating a quadtree for 64x64 pixels was still too slow.
After struggling with this, I decided to have the quadtree not be represented by a large number of node objects referencing children and parent node objects, but as a byte array of fixed length. In the array, first comes a byte for the root node, then 4 bytes for the second level, then 16 bytes for the next level, then 64, then 256, then 1024, and 4096 bytes for the deepest level. An recursive function travels across the 2d array in a specific pattern to fill the uqadtree with bytes that represents the nodes. If 4 nodes in a row were the same value, they are merged.
This turned out to be faster (as long as not too many tiles are updated... so e.g. snowing would be a huge problem).
I could upload the Unity project to github for couriosity.
Landscape consists of tiles each one 64x64. Each tile has a field for a 2d array for material, and afield of a 1d array for the quadtree. Pixels are changed in the 2d array. The 1d array is then updated accordingly. A collision mesh is generated from the 1d array.
What I can definetely say is that it is really cool to use proper physics in a clonk-like game! Seeing rocks actually pile up is really cool! However, sometimes the physics are actually too accurate, e.g. a sliding box will not even slide up a step of 1 pixel height, which is technically the correct behaviour...
Here's Newton's thesis about 2d landscapes with polygons btw, maybe it contains interesting ideas for you: https://forum.openclonk.org/topic_show.pl?pid=13293
>We heavily underused the engine
We are not using the Ogre Engine for rendering at all, as far as I know. It's only the file format. Not sure which alternatives would have been better for the file format.
>I do think this hurt the game as new players always got the 'it is still a bit rough and weird' feeling.
I think that OC looks, for the most part of it at least, quite beautiful and would really consider that a very minor point - for example compared to the movement quirks.
I fully agree to the rant about that we expected a better workflow from using the Ogre file format. Buut I am not quite sure which one would have been better. But adding a different one is probably(???) less effort than e.g. changing the vertex system or fixing the movement
> We are not using the Ogre Engine for rendering at all, as far as I know. It's only the file format.
Ah, yes. You are of course correct!
I guess our experience with feedback on OC is different then. Whenever I showed OC around (among friends, online communities or people I met at gamejams - the last two groups however being people focused on game development, so maybe looking at things with more scrutiny), the wonky and unfinished look (graphics-wise) was a frequent criticism I received. "Looks very indie" was one of the better terms for describing it. ;)
Compare to e.g. minecraft, which looks even more indie. I think people are very open to compromises in graphics when the rest of the game is fun.
And especially the light effects, landscape shader, particles can look really beautiful in OC - and everything together, imo, looks better than for example CE or maybe even CR :)
1) The lighting of the meshes, especially with the hard shadows mismatching the style of the landscape gives it the feeling of a sandbox prototype (or an indie game). Probably a simplistic and colorfull palette with shadows not being darker than a certain percentage (like 40% of midtone) would solve this issue.
2) The general way how meshes are read visually. Some meshes have some very intricate design with thin details, which don't render well in my eyes. A general bold style leaning towards the general shape being a square, worked in my opinion always the best clonk, the way there visually interact with landscape, but also physics-wise. If combined with the a visual hierarchy of primary and secondary feature, would probably help "reading" the shapes of a mesh and therefore make the visuals in general enjoyable.
I always wanted to adjust the "missing" models, but I really lack some skills to make them profoundly better. In a general movement to contribute to OpenClonk i might actually try, if I am not alone.
And a nice viewing tool for the exported models would also have been a good addition.
If there is still interest in a good exporter, I could continue on my port of the Exporter to the new Blender 2.80 version. (which broke the last version)
By now, I personally couldn't tell you in good conscience that there is further interest in having an exporter for Blender. As I said, there are no artists left to do anything and there is no active development and probably no real interested in the game itself.
> The post was in no way meant to belittle your contribution. On the contrary, you made the best effort to make a working (Blender-) exporter. As a project however, we were lacking a whole lot more.
I did not take any offence in your post. I just wanted to point out that I tried with the exporter to make it simpler and would be willing to contribute in improving it. So if we would have a plan of what we would want to have to give OC perhaps a bit of new momentum, I could contribute.
I also recently failed exporting an oc model with 2.8, but is there any benefit in having 2.8 for the export stage? I ended up exporting it to 2.79b and then use the oc exporter. That reminded of the 2.49 vs. 2.5 incident.
Everything even remotely development related should be public
But yeah, are there any forum admins (just Newton and ck, right?) still alive?
> But yeah, are there any forum admins (just Newton and ck, right?) still alive?
I saw some used in the pathfinding code as I tried to write a TextMate-Grammar for highlighting in VSCode.
>as I tried to write a TextMate-Grammar for highlighting in VSCode.
That's pretty cool!
>Btw. is there actually some documentation to the usage of anonymous functions in openclonk?
What do you mean by that? I think you can only put functions into proplists, but they won't be completely anonymous like lambdas in other languages. Do you mean something like in this script?
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill