October 20, 2018 at 12:42 am #15528
Has anyone here used the Godot Engine before.Seems this site is DEAD.October 20, 2018 at 10:27 am #15530
Man, there really is something you don’t get with this community and the development of monkey 2. If you need a large community to feel good I advise you use unity or unreal engine. They have the two widest community arround. Godot has a mid sized one and has much less premade resources. Next version 3.2 should include vulcan which is cool.October 20, 2018 at 11:33 am #15531
Monkey 2 is not in the same category.
It’s a pure code tool (can i say that ?)
It doesn’t promise you to create a game in a week.
It’s a place for long term users who like coding without limit.
Our community is competent.
You can also try Lua-Love2D, Monogame, HaxeFlixel, Defold.October 20, 2018 at 8:37 pm #15532
Godot 3 is actually pretty nice (I recommend this tutorial), but I found that when I wanted to build physics stuff via code — walls to knock down and the like — the whole point-and-click thing fell apart, as you have to implement it all in code anyway, so you have no 3D placeholder to help visualise objects’ positions.
I’m sure you could work around it, but I lost interest (some of the 3D coding was impractical or difficult to figure out) and have been doing mojo3d ever since.
That said, we know you’re not interested in monkey2 anyway.
Godot was definitely fun to play with, so go for it.
Please post your progress.October 20, 2018 at 10:58 pm #15533
For the latest competition over at Syntax Bomb I tried making a game in Godot, somethings I really liked such as the AnimationPlayer and everything in the IDE thing… but the more I “coded” with it the more I felt like I was hacking with the scripts and scenes.
I’m going to try MonoGame next, which looks right up my alley actually: code in nice modern language (C#), great IDE, its mature and is in active development with a large community.October 21, 2018 at 11:08 pm #15535
I feel like MarkB should have gotten banned long time ago.
All he does is post some ‘troll’ post every other month.
And I agree with abakobo.
If you’re just looking for a big community, and not an actual tool to use, then there are plenty of other options out there for you.
Also, just a funny side note.
MonoGame doesn’t even have an IDE.
It just uses Visual Studio or MonoDevelop / Xamarin Studio.
They’re super heavy on the system, very non-portable, and even requires a computer reboot after an update.
MonoGame is just an Open Source implementation of the old Microsoft XNA 4 Framework.October 23, 2018 at 6:29 pm #15537
It is nice to have an active community, though. Even if just for inspiration or encouragement purposes.
Mark finally did 3D after the masses complained about it throughout BMax and Monkey1 all these years, and yet not many are here.
I don’t want to drudge up old topics/rants. And I didn’t begin programming decades ago to become popular (!) . But it would be nice to have more friends here in this space.November 8, 2018 at 12:59 pm #15574
I have used them more or less but I was not happy with them in terms of 100% code. But I found strong points in using them when needed.
Unreal -> you can get the best graphics – really cool for seeing how the graphics would look like
Unity -> you can do very quick iterations – this helps in early stage of prototyping
Godot -> I have not used it much but I got the feeling of looking like an open source Unity without the bloatware (but I was not impressed from it having GDScript)
The real deal for me is that these programming environments where you attach scripts to game objects simply can’t cut it in terms of software architecture. The only engine I did some serious development for 2 years was Unity. But the projects failed dramatically. What I found, is that you will loose the sense of software architecture. And you won’t know what goes where and why the entire codebase is distributed across the entire universe.
The entire development in such engines, forces you to use the composite pattern. So either you will have extend the GameObject of where you can create customized objects, or attach other GameObjects and make tree like structures. So that’s the composite pattern. But where it fails?
The classic problem that created the development hell for me was dealing with such dumb notions:
- should the bullet update itself?
- should the bullet check for collision with the player and enemies?
- should the enemy check for collisions with player and enemies and bullets?
- or should the player check for collisions with enemies and bullets?
This problem is solved by controlling how you want to update the objects. You can do that in Monkey2 easily, simply and them in a global list and perform the collision checks with a double nested for loop statement. But with the other engines mentioned, you see that by attaching logic to game objects is not a good idea.
OK, you might perform this style of programming in these engines but it does not solves all of the problems. Another development hell problem in Unity is mixing presentation with logic. For example consider this scenario:
- you have created a mesh model (eg: a sword)
- you import it – set it up – and now it works
- after a while you realize that the sword is too big (eg: you have the elf sword in the same size as the barbarian sword) so you want to make it smaller
- you do the modification and re import it back to unity
- but now what would you do? replace the mesh manually or use (or use an automation script)
- what happens if you do that with textures, sounds, resources
- what happens if some one else changes the prefab and breaks your script?
Simply the solution is that presentation and code need to be separated for good, not all mixed up together. In Monkey you can control if you want to make your code a mess or purify it. Simply make everything data driven and avoid hard coding it.
Another development hell is testability. What happens when you want to test specific parts of the software without involving irrelevant bloatware? For example you want to check the collision detection code and you create some functions that do only that without involving any other bloat such as audio-graphics-textures-level-game-logic. In Monkey you can call whatever you want any time you want, just rename Main function to Main2 and create lots of test scenarios, the point is to use existing infrastructure. But with other engines you need to create new scenes for each testing scenario, make sure is init correctly from scratch. Chances are that you won’t be able to keep the tests up to date so either you do them once but is a lost effort, or either you avoid testing at all and test things on the spot.
Well, these annoyances were too much for me. I really don’t know if these techniques lead to successful development, but for me is very complicated process. At least by using Monkey you gain programming experience all the time and control the way you want to do things. The downside is that you need more time but at least you get more sharp on what you do.
You must be logged in to reply to this topic.