The development tools for Cerberus?

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
I don't think it has anything to do with poor marketing. But lack of what BRL followers actually wanted.
Maybe this is not what the Blitz3D and BlitzMax community wanted and this is why Monkey failed plus other things I guess but it is no longer Monkey and I think Cerberus should aim outside the BlitzBasic community already. Personally I would not even mention Monkey X anywhere, yes this is the underlying tech but nobody really need to know unless they want to contribute to the source especially if it was the source of anger and disappointment among the Blitz users.

The way I see it there is lot of people out there who looking for exactly what Cerberus has to offer already. 3D is actually not that much of a problem, sure many people want it, nice to have it but still lot of people making 2D games and 2D games are still popular.

For example the AGK community is begging for OOP since day1, also begging for more powerful graphics API commands for Tier1, ability to integrate libraries and me personally begging for some kind of 2D lights that cross-platform since day 1 and the ability to read and write storage in HTML5. TGC just published their news letter with some hints for AGK Studio 2 and no OOP, no lights, no HTML5 storage, no API commands for Tier1 on the list but 3D level editor, Visual Shader editor, VR support, 2D level editor improvements, basically they seem to try to compete with Unity and Godot now while the core product is getting less reliable with each release. The forums already feels pretty dead, only few people discussing bugs mostly. TGC falsely believe people moving to Unity, Unreal and similar engines with visual editors but they are wrong. People are moving to other frameworks like MonoGame, Solar2D, Löve especially Löve becoming very popular because of the simple Lua language that is somewhat similar to BASIC.

But also when I was visiting the MonoGame forums there was also quiet a lot of people was begging for better VB support and VB because just like Cerberus it is BASIC with OOP, more simple, beginners love it.

So, there is lot of people still looking for an easy yet powerful cross-platform programming language for games while Cerberus is hidden in a very dark corner of the web covered with a blanket with strong unnecessary references to Monkey. Seriously the search engine results for Cerberus is horrible. You can't find it under any search query and this is because people don't talk about it on the web and don't link it, it is not mentioned anywhere.

The only way to fix this is to looking for sites talking about game engines, programming languages and at least in comment sections mention Cerberus that is a SEO point right there, even go as far to contact admins of sites to add Cerberus to lists on their website, add it to wiki pages where possible. Etc When people search for things like game programming language, game frameworks, cross-platform game development, Cerberus must be listed on first page.
For example I added it on alternativeto:
https://alternativeto.net/software/cerberus-x/
Also added to one of my lists there:
https://alternativeto.net/list/7173/list-of-game-programming-languages

An other thing could be done for example is to add it as an engine on itch.io so people can flag their creations it was made with Cerberus so it would also come up in this list:
https://itch.io/game-development/engines

Finally, I think the home page also need some improvements. The first time I visited the website I was like "what the f*- is this mess?" and I did close the page at first. But then I decided to go back and check it out anyway.
There is too many noise on the home page. The home page in my opinion should be dedicated to introduce Cerberus (without mentioning Monkey anywhere).

The home page should describe:
What Cerberus is (no Monkey)
Highlight the features and benefits, supported platforms of Cerberus (no Monkey)
List some games with screenshot made with Cerberus.
Mention that it is open-source and full source is available on GitHub (no Monkey)

Mention Monkey only in the documentation maybe and GitHub but don't mention it on the home page because people immediately search for Monkey, find out it is dead, maybe even see complains from disappointed Blitz users what a piece of s** it is and they immediately ignore Cerberus, never come back. So I think it is better to hide the fact it is based on Monkey on the home page at least, but it is okay to admit in docs and GitHub.

The games section is the most crucial because many people make their decisions based on what other peoples was able to achieve and eye candy. If possible need to list some games that looks pretty and fun to play. Even if no longer available because the author removed from the stores but if possible share some screenshots and the name of the game directly on the home page if it looks pretty. At this section would be also ok to mention some Monkey titles because Cerberus is based on Monkey and fully compatible, This is exactly what MonoGame does, they advertise them self with title was made in XNA while MonoGame got nothing to do with XNA, it is not based on XNA, it is only a reverse engineered, compatible open-source implementation of XNA yet they do talking about XNA titles as it was made in MonoGame. Which is technically not true yet it is ok because MonoGame is XNA compatible. So it is totally fine to mention Monkey titles in this section of the home page.

Sorry for the long post and the off-topic but since we started a discussion about this here, I could not stop it :p
 
Last edited:

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
@ddabrahim I just reread your post and you have many valid and good points here. Thank you for taking the time to write that.

I also think that we should concentrate on our strengths which is the fast and powerful api to create 2D games. Personally I would love to have 3D support but then, like you said, 2D is still a thing and important for many. Otherwise tools like GameMaker or Construct wouldn't be so popular.
But they all share one thing. An editor based environment which attracts the artsy types of game developers as well. They can't code so well but clicking a level together quickly attracts these kinds. There is a reason why Steam is swarmed with indie titles made with these tools.
We/i need to work on making CX easier regarding developing a game. Being it supporting editors, being it more game supporting APIs/framework.

If Metal wouldn't not become a requirement on the Apple platforms one day, I would not look for one second into a solution for CX.
The other day I told Philipp on the phone that my hope is that Apple will still support OpenGLES forever, but I think we all know how the story ends. With our current render abilities, we kick tools like Godot and others out of the stadium currently. But regarding Apple we HAVE to look into a solution that let CX target OS10/11 and IOS. When do we need it, I don't know.

When we have these basics covered, we can easily go out and scream at everyone that our tool is the better one.

And yes, the website can use an overhaul. Currently it is an addon to the forum software but because of this, it has its limitations. We/i will address that one day.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
They can't code so well but clicking a level together quickly attracts these kinds.
It is not only about level editors but also visual programming. Even coders sometimes prefer an easy click/drag/drop solution because it is a lot faster and also more simple. I admit, I know how to code and I do enjoy the freedom and flexibility code gives me, I have a genuine interest in how some things can be programmed but I can enjoy an easy drag/drop solution.

This is why Unreal Engine is so popular, many C++ coder love to use the Blueprint system because it is not only easy but extremely powerful too and also fast at runtime, C++ does not have a lot of advantage compared to the Blueprint system of Unreal.

GameMaker also offer a visual scripting solution but the actual scripting language GML is extremely easy to use also. GameMaker offer one of the best OOP experience supported by visual editing solutions in my opinion, personally I love it. The only reason I don't use GameMaker is that the compiler is extremely unreliable, very often I need to deal with bugs caused by the compiler. I'm debugging my code for hours only to realise, yep nothing is wrong with my logic, it is the compiler. You need to work around lot of limitations and bugs in GameMaker.

Construct also offer a visual coding solution called events which is almost feels like clicking sentences together like If 'A' key is released Then Set X = 10 of Player. It is that simple if you can read and write english, you can use Construct. But an other thing is important about these tools is that they offer a complete game engine with physics path finding, camera, lights, visual effects, support for sensors in mobiles, 3rd party API integrations, asset managements when you create and delete objects at runtime..etc
In visual tools like GameMaker, Construct, Unreall, you can literally focus on the gameplay only, you want this to move and you want that to jump, no need to worry about "how" only about "when", so it is a lot faster. For example I have remade a project in Cerberus that I have done in Construct. In Construct it did take me literally 4 hours, in Cerberus it took me 3 weeks including learning of course. Now that I know what I'm doing and did made a kind of game framework of my own that currently has most features implemented I needed for this project maybe I could reduce the time now to 4 hours in Cerberus but it took me 3 weeks to get here. And the framework I made certainly doesn't fit other type of projects while you can certainly make them in just few hours in Construct.

So this is why they are so popular but it is all comes with limitations regarding performance, what tools you can use, what API's you can integrate with, what devices you can support. They are fundamentally different from Cerberus and alike and in my opinion it would be a mistake to try to compete with them like TGC trying with AGK Studio. Cerberus is perfect for people looking for freedom and full control and Construct is perfect for people who looking for a simple visual solution. It is not so easy to combine the two, as far as I know only Unreal Engine was somewhat successful at it they did make a brilliant job with Blueprints.

But if you would be interested to maybe develop some visual tools to simplify the workflow with Cerberus for those who need it, I recommend to:

include your game framework with Cerberus with full documentation.
consider to look in to Blockly for a visual code solution to generate cerberus code.
This two combined, a game framework and blockly could speed up development greatly.
Look in to Construct events, conditions and actions to get an idea what sort of blocks you could implement in Blockly. I can compile a list if you are interested, I have many years of experience with no coding tools and ide what sort of action, conditions are really useful.
For 2D level editing, Tiled is the most popular and really awesome tool, you can even use custom objects to mark location of dynamic entities like player, enemies and also set values like player health, enemy strength and then parse the info in your game engine, you can create a really smooth dev experience with Tiled.
For 3D unfortunately I don't know any good 3rd party ones. There was long time ago 3D World Studio, Cartography Shop but they are no longer developed. I think there are some level editors for Quake engine and Source engine to create mods, maybe could try those.

Currently there is not a single modular framework that you can choose if you need a game framework or not, need a level editor or not, need visual scripting or not..etc. It is either all in one that doesn't fit coders and offer less freedom, flexibility and performance or offer nothing, need to do everything from scratch that doesn't fit people less interested in coding or looking for a solution for rapid development and prototyping.

In my opinion this is the direction it is worth going to keep people happy at all levels, coders, artists, no coders a combination of Cerberus + a game framework + Blockly + Tiled tightly integrated but optional, I don't know any modular framework offer anything like this but I think it could be a very interesting design even if you choose to develop all the editors your self.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
Tiled imports are already there in FantomCX, IgnitionX and Pyro.
In IgnitionX there is an experimental thing where you can watch and modify positions with the mouse at runtime.
 

Gerry Quinn

Active Member
Joined
Jun 24, 2017
Some people (like me!) just want to write some honest code and can't get their heads around these 'visual coding' systems. It seems to me that those are the ones who will be interested in Cerberus.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
just want to write some honest code
Yes, this is why in my opinion it is a mistake to try to compete with all-in-one visual tools like Godot, GameMaker, Defold...etc and turn Cerberus in to one of them but in case devs are interested to add more layers to attract more visual type people then it could be interesting to have a game framework, blockly and tiled as optional layers on top of Cerberus nicely integrated for a smooth workflow but all optional of course and hidden from those want to write code and nothing else.

So by default it would be vanilla Cerberus as it is now, would be no different, but if someone need a game framework with state management, sprites, pathfinding, particles, physics, camera..etc then it would be included and all you have to do is Import it and then in case someone don't even want to code could use blockly to generate CX/GF code using easy to use visual blocks similar to Construct, could have an option to launch it from the IDE and use that instead of typing code manually. I know Blockly is looks like Scratch and Stencyl but no need to think of that complexity, you can design any kind of block in Blockly so it is totally possible to create a simple event system similar to Construct where you drop actions and conditions and set values but even better in my opinion with all the flexibility and freedom Blockly has to offer. Finally Tiled for level editing, again could be included and launch it from IDE and save level data by default in to project folder.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
Yes, but could easily wrap it in to NW.js for example that give you also access to file system through Node. To include a little editor maybe.
I did also see projects where it was embedded in a WebView. in case you prefer to use a certain GUI lib as long it got WebView, you can embed it for sure.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
However, in case you don't like Blockly or prefer not to use JS, an other "easy" solution could be to use Godot, it is offer an extensive GUI library that includes GraphNodes to build your very own custom node based scripting solution, something similar to Blueprints in Unreal. You can see it in action in RPG in a box, just scroll down to visual scripting to see a screenshot or give it a try, it got a free version. In fact RPG in a box was entirely made in Godot, everything you see is made in Godot the entire tool with all editors and engine, so you can end up with a pretty advanced editor actually...
link_map_tut_07.gif


But maybe there is a much better solution for QT or something that I don't know about....
 
Last edited:

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
Regarding Metal maybe the best way to go about it is to target Swift and SpriteKit directly. Targeting Swift would also have the benefit to be able to integrate with other Swift frameworks too like GameplayKit, SwiftUI, ARKit..etc 1 size fit all (cross-platform) solutions always going to have their limitations and problems and who knows maybe one day Apple ban everything from their app store except ones was written in Swift. I know I mentioned the other day it would be better to target only 1-2 cross-platform SDK's to cover all platforms but maybe I was wrong and considering the fact CX is a transcompiler the best would be to go native for each platform and avoid cross-platform solutions.

HTML5 - peronsally I love mojo2, I think it is great. But in case someone know of few problems, the other most obvious choice would be Pixi.js or Cocos2D.js maybe.
Windows - again, mojo2 seems ok to me but in case there is any problem, there is a bunch of C++ and C# engines and frameworks to choose from I have no favourite really.
Linux - same
Android - I know about libGDX but was told it is dead. I don't really know any other native one for Java and Kotlin but almost certainly whatever we pick for Windows and Linux it can also target Android. I don't know, maybe Cocos2Dx or Sokol is fine I guess.
iOS -Swift + SpriteKit
macOS - same
tvOS - same

In any case it could be possible to focus only on 2 targets actually. mojo2 and SpriteKit or Sokol and SpriteKit or Cocos2D and SpriteKit. In worst case scenario 3 mojo2 + Sokol + SpriteKit to cover all platforms with native targets. Would this be too much to maintain or to teach CX to translate to Swift?
 

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
Currently the render part of mojo and mojo2 is based on OpenGL/ES. On all platforms. The difference with mojo2 is that its implementation uses opengles that was translated to CX. In mojo you have your own native code file for each platform.
If I understood you correctly, you suggest to use a different 3rd party framework when targeting a different platform. That would make maintaining everything even more work. And also porting features not so easy. Sometimes maybe impossible.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
Yes, after you mentioned FNA to add Metal support while Sokol already have it, I figured you might be considering frameworks because you are not familiar with Metal or something and SpriteKit seems very promising and developed by Apple them self. But sure, it would be a pain to port features for all targets if each target is using a different framework :p

However, it is already not the case, mojo, mojo2 and agk is different, not all features available on all of them and need to code differently, don't know what the story with Sokol is going to be but SpriteKit would be at least native and maybe less headache to keep up with Apple since SpriteKit is developed by Apple and they seem to be more dedicated than Microsoft was with XNA.
 

MikeHart

Administrator
Joined
Jun 19, 2017
Location
Germany
Forget about agk for a bit. That is just a pet toy of mine which i shared. Yes, i am not familiar in Metal so using a solution that supports it is the goal.
 

ddabrahim

Active Member
Joined
May 3, 2020
Location
Cyberspace
If the ultimate goal is to have 1 framework to target all platforms, maybe worth considering Cocos2D. With Cocos2d.js you can target native HTML5 using JS and with Cocos2dx you can target all the rest with Metal support on iOS and macOS using C++, JS or Lua but there are unofficial wrappers for C# and Python too.
FNA is also an interesting option but no HTML5 support and personally I dislike being dependent on Mono and Xamarin but in case a C++ framework like Cocos would be too complicated or too much work, then targeting FNA and keep mojo2 for HTML5 support could be also a way to go.

But in case the ultimate goal is to develop a custom framework (mojo3) with Metal support, I have no idea how to go about that :confused:
I thought this is what Sokol is all about, if it not and you are not familiar in Metal the only way to go about it is to use 3rd party frameworks. Atm I would vote for #1 SpriteKit, #2 Cocos2D and #3 FNA in this order to add Metal support. It is if Sokol can not be used.
 

Phil7

Administrator
CX Code Contributor
3rd Party Tool Dev
Joined
Jun 26, 2017
If the ultimate goal is to have 1 framework to target all platforms
The word framework might be the problem here. The only way to use a big high level framework with CX would be to make the api of the framework accessible from within cx code. But this means there is no control over how the api works.
We are talking about a really low level framework if you want to call it framework at all. Something that isn't adding functionality but merely putting multiple target plattforms under one set of api without loosing to much of performance and usable functionality. It might be called a multiplattform render/input/audio layer. From there we can create something like mojo or mojo2 as the high level api.
Certainly custom code for all targets using the native render api like Metal for MacOs/iOs, DirectX for Windows, GLES for Android and so on would be the most performant option but just not maintainable for us.
 
Top Bottom