Is this game possible with Godot?

Avencherus

Hello there.  I’m new to Godot and just came across it, but I feel like I’ve come to the right place.I’ve been reading the documentation, and I must say so far it’s well written, especially the part about encrypting saved games. :DLacking the experience and familiarity with it, the idea of scenes are a bit alien to me.  So I have a hard time answering a few design questions.I would like to create a 2.5D adventure game that has multiple game states in the same areas, and there is a little bit to unpack to describe what I had in mind.  So here it goes, I’ll do my best to describe it, and hopefully I might pick up some pointers from someone.First here is a general image of what the exploration would look like.[img width=750 height=260]https://s31.postimg.org/jj4s8fgt7/basic_idea.png[/img][b]The requirements.[/b][list][li]I’m going to have purely 2D art.[/li][li]The backgrounds and foregrounds will be layers that may or may not parallax.[/li][li]The main player area will be either 3D or faked 3D space made of an invisible plane that will allow a player and their companions to walk into the background or foreground.  They will need to scale properly, and collision still has to behave.[/li][li]The sprite directions will be drawn with 8 sets of animations showing the angle they’re walking, based on the angle of their vector.[/li][li]There will be scrolling up and down, and the camera likely has to track to the first background layer, so the character sprites won’t slide around in ways that don’t make sense when the camera translates the view.  How can 3D positions be aligned to a background through camera translation?[/li][li]Also I’d need some kind of vector/line/polygon collision masks, to create special boundaries around the 2D art so objects and players can’t pass.[/li][li]When a player moves to another area, the camera angles will have to vary to support different perspectives, so the characters can scale in way that makes sense for that 2D background.  Otherwise they might look like giants or hobbits from scene to scene.  I feel like if I don't use the engine properly here, I will have to create unique solutions for every area in the game.[/li][li]If players end up being invisible 3D geometry with 2D sprites, I would like a way for the up movement to move them in a sort of orthogonal path that aligns to the screen coordinates.  (This is shown in the attached image.)  I’m not sure how difficult it might be to do this kind of transformation on their movement vectors.  I would want to avoid the controller's UP/DOWN adding velocity that tracks its aim at some 3D vanishing point, this kind of movement gets confusing when the artwork is all sprites and textures.[/li][/list]Is such a blend possible within the existing tools, and without circumventing in a major way the engine's ability to perform as it was designed?  I wouldn't want to create something that may get buggy or have performance issues, and I'm certainly not experienced enough as a programmer to write the low level functionality of such a robust engine.Is a 3D plane with 3D collision geometry, combined with 2D textures the way to go?  Can the game handle mixing 3D and 2D elements in this manner, or do the backgrounds and foregrounds need to be billboards of some sort?I was also thinking it must probably require an orthogonal projection camera, but I wouldn't know how to preserve the scaling aspect of characters moving towards and away from the screen.Or is there some kind of 2D solution?  Such as having some invisible 2D/3D space that can project a transformation into a 2D viewport/camera?  I would imagine I would have to do some sort of special hacking to get this to work, but my concern comes back to organizing such a design in this model of nodes and scenes.I’m still a bit foggy on what exactly a scene is, since in the examples it seems it can be used to just encapsulate an entity.  They work together in some hierarchical way.  My brain keeps telling me that would be an object class.  It hasn't quite clicked yet what all comes with a scene, and why it's called a scene.If it's the case you want to contain objects in their own scenes, what kind of organization or layout would make the most sense for all of this, so as to avoid having to rewrite all kinds of game logic from one player area to the next?  I’d hate to make some kind of unwieldy cobweb out of things, because I’m missing the design intentions of this engine.Thanks for reading, and any insight or recommendations you may offer.[i]PS: From what I've seen so far, I'm quite liking the engine.  I really hope I can use it for my game.[/i]

razvanc-r

I'm pretty late to the show but... you have quite an elaborate story there. The short answer I think is yes, you can do it. And as you mention there are multiple solutions. But unfortunately I don't think that there's an easy way where you basically let the game engine do all of the work for you. You still need to do some collision checks / scaling stuff from code. I can't even imagine telling you exactly what to do as this is a very large subject but there are a bunch of examples that you can download from the godot repository and one of them includes an isometric mini-game if that's what you mean by 2.5D. There are also examples of 2D usage in 3D space and 3D space in 2D so you have places where to start from. Also on the forum here I've seen some good resources and tutorial links, you'll just have to search and use the IRC channels (#godotengine & #godotengine-devel on FreeNode server) which I highly recommend, much better than this forum really as you'll get answers in no time most of the time :). (if it's not something way too complicated :P) So good luck and see you around!

Avencherus

razvanc said:

Also on the forum here I've seen some good resources and tutorial links, you'll just have to search and use the IRC channels (#godotengine & #godotengine-devel on FreeNode server) which I highly recommend, much better than this forum really as you'll get answers in no time most of the time :). (if it's not something way too complicated :P) So good luck and see you around!

</blockquote> Thanks razvanc for the response. I'm kind of homing in on some solutions.  You're right, it's not something that I can put together with the out of the box tool set of Godot.  But Godot is still quite flexible that I think I can somewhat hack a solution for it. As it becomes more clear the direction I should take, I'm sure I'll find myself more involved.  X)

zadig

·About the "scrolling up and down" and the camera behaving properly, could you elaborate it more? For what I understand what you want to achieve can be done by just playing with layers and Z index in a 2D game in a fake 3D manner, but I may have not understood you well. ·Collision handling should be no problem. You will have to deal with coding but any serious project does. GDscript should be enough, no need to hack Godot under the hood (considering I understood your concept). ·When you say that the camera angle changes I think you mean the zooming of the sprites, right? As far as I understood your concept the camera has a fixed view angle - at last in one of the axis (it can move up and down, but not rotate). Assuming you want to deal with sprites scaling due to the distance of the camera when characters move far from it I see no problem once again. It is more important to think about the size of your sprites and the resolution of the game due to scaling up/down of the sprites - the lower resolution, the worst quality. This is a fact beyond Godot or any other engine, so another thing to mention is that careful planning of the artwork is always a good thing (deciding when and where to use strokes to define limits of a sprite, for instance, the contrast of colors between foreground and background etc). If you are going to create a low-res game you may have to fine tune a few zoom levels of the sprites in a pixel-art style 'cause there's something as "too little information" when dealing with low-res re-sampling. Since the player can move closer and farther form the camera, is this movement smooth, or are you planning to have a fixed number of possible distances (e.g. 4 profundity layers for the player)? This seems to me like a key-factor to decide if going with 3D or 2D physics. Assuming you can use just 2D you are ok, performance-wise. If you deal with hybrid 3D/2D solution I can't emit an opinion since for now I used Godot only in 2D games. A curiosity: Is this your first game project? Tell us a little about your background so we can point you in a more precise direction according to your experience. My impression is that you want to achieve the game mechanics of titles like "Streets of Rage" (camera-wise at least). Is that correct? In Godot you can use scenes to... well, be a "scene", as in a level of a game, but you may also use scenes as a place to put objects that will be used in other scenes (think of a library), to create a tilemap, etc. You can have child scenes instantiated as a node in a root scene, so your game may have a scene encapsulating the levels, assets, etc. It is worth to mention that you are likely going to have a global script - a singleton - to deal with information shared between scenes. I personally like to use a singleton to deal with global variables, but also have scripts that I assign to the root nodes of different kinds of scenes, containing the relevant functions - like save/load for playable scenes, and animation stuff for cut-scenes etc. Anyway, it seems that you can use Godot, but I'd like to hear a little more about your background regarding game dev, game art creation etc. Good luck!

Avencherus

zadig said:

In Godot you can use scenes to... well, be a "scene", as in a level of a game, but you may also use scenes as a place to put objects that will be used in other scenes (think of a library), to create a tilemap, etc. You can have child scenes instantiated as a node in a root scene, so your game may have a scene encapsulating the levels, assets, etc. It is worth to mention that you are likely going to have a global script - a singleton - to deal with information shared between scenes. I personally like to use a singleton to deal with global variables, but also have scripts that I assign to the root nodes of different kinds of scenes, containing the relevant functions - like save/load for playable scenes, and animation stuff for cut-scenes etc. Anyway, it seems that you can use Godot, but I'd like to hear a little more about your background regarding game dev, game art creation etc. Good luck!

</blockquote> Thanks zadig. Yes, it would probably be similar to a beat em up game, but I'm fairly sure that I can't really rely on that model entirely.  Though the closest thing I've seen to what I'm working towards are point and click adventures like Disc World.  Except the navigation will be key driven using simple game physics. The "angle" idea I see is a bit ambiguously stated on my part.  The background artwork will be quite varied in their perspective from scene to scene.  So every scene will have some variation in the hypothetical viewport into the world.  I was experimenting with this idea before I discovered Godot, and I've found that I do have to apply some skewing and such to the transformation to fake a sort of tilt so the character movements move and scale to the background artwork in a sensible way. I'm experimenting with Godot, but I see that scaling Rigid Bodies is something that has to be worked around, but also scaling the collision shapes in response to player movement seems to be a quirky thing. I will continue to fiddle around with that, but in the end my thought is that I will create some unrendered scene that is just the physics bodies that act in full scale.  From there I will take the positions and transform the coordinates into a perspective view.  Creating my own kind of camera, but wrapping this around Godot so I can take advantage of what is already built in. It's still not decided yet, I have to do a lot of tinkering still and I would want to test the complexity and end performance of some of these ideas before forging ahead. For more background, it's actually me and my wife that decided we would like to make a game.  She's traditional painter and I'm applications programmer.  I'm learning as I go as of the last few months, and after some studies I got a good understanding of the scope of writing a game engine.  I realized we weren't going to get this done anytime soon if I had to learn and create our own 2D engine.  It's still something I'm going to work on doing, but as a side project for learning purposes. Other than that I dabbled in mod making when I was a teenager, but now I'd like to get serious about making games. Godot seems like just the right fit for what we'd like to do. We've never done anything like this before, so I wouldn't want anyone's expectations to be high.  It's really just started, and I've just barely gotten familiar with Godot, but as things begin to actually materialize I will very likely share my progress here for anyone who is curious in our little project.