Best Recent Content

  • [Godot 3D] Zombie Defense

    Hi there,

    There is no voice comment, but the tutorial is progressive covering all aspects from modeling to scripting gameplay.

    https://youtube.com/channel/UCGzQFkSnOG-wEA8janAsJ_g

  • List of Android Modules

    If you're getting "internal error", access your Google Developer Console and activate the following APIs for your application:

    • Google Drive API
    • Google Play Android Developer API
  • My first tries with Godot and Blender

    Hello,
    Thanks for pdf versions
    About asteroid fields there is a several options....#1....use group of meshes (asteroids ) or mesh planes with billboard
    #2....use multimesh instance
    #3....use grid map
    #4....and of course particles
    use LOD for them whenever possible.....you can create never ending asteroids fields all species with procedural spawning
    about hairs you can use rather many planes with texture....look at Naughty Dog's The Last of us characters heads or visit
    Polycount forum.
    Yes, heavy particles are always resource hungry and in the real-time this is even more true :)


  • Is there a simple way to code in C++ (at least in the near future)?

    I have poor skills on programming, and honestly, I don't like doing this. But I admit that it gives a pleasant feeling of accomplishment when you get something to work.

    I tested the Nim bindings, but from what I understood, all GDNative bindings have common files:

    -The "godot headers", the Godot API in C code.
    Since the pure C is still the king of all languages, most languages can talk with a C library with reliability. That's made possible to script Godot with many different languages.

    -The languages bindings. Godot headers are generally found in the same repository.

    -The "natives scripts", created with two mouse clicks in the Godot editor.

    -The "GDNativelibrary" resource, created easily in Godot too.

    -A compilation script. You will run this file to compile your scripts. But you must respect the directory organization recommended (for example all your cpp script must stay in a "src" named folder).
    If you want to place your Cpp files elsewhere you need to understand this script in order to update the filepaths. (that's the annoying thing for me.) Edit: This script is provided by the binding.

    -The library you will create by compiling your C++ scripts. It's a single binary file per platform.

    -And of course your native scripts source code in cpp or whatever. The class must have the same name as the one specified in the native script. That's why Godot can found your code.

    Depending of the languages bindings, some additionnal stuff may be required but this should be documented in the readme.

    I tried to show that chain in a quick diagram. Sorry if the naming is not very accurate. (English isn't my native language).
    Binaries are in blue and text files are in green.

    When you run your project, your compiled scripts (the library) are dynamically linked to Godot, and no GDScript is required. (but you can use GDScript to call your library if you want).

    I don't know about you or other folks but my satisfaction doesn't come from just seeing my game finished already. It comes from the technique of making it. Imagine you go on a trip in a country by car. Now imagine instead you'd take the train. See my point?

    I understand that. Games engines hides all the technical stuff to accelerate the creation process. But if you love to code you will be frustrated, even GDNative follow the path defined by the engine.

    You can solve this by trying a little project without any game engines. The SFML C++ library might interest you. Or if you feel adventurous you can even try more low level libraries like Open GL, PortAudio, and dealing directly with the OS. With that you will become a master of game programming.
    I apologize if I wrote bad english.

  • How to convert mouse coordinates to 3d position?

    I am now realizing that when the camera projects a position using project_position, the position is based on the camera's transform origin and the znear value. If you project a position and you have a near of .1, it will project the position within some range of the camera's position and .1. If you are at a position of 32 with a near of .1, the projected position will be something like 31.9. Likewise, if you have a near of 10, and a position of 32, it will be somewhere in the 20s. By altering this near value, I've found that the code works above even with strange camera orientations, but then you run into clipping issues.

    I realize that a way to get around this issue of having the correct position but avoiding clipping is to set the z_near to some greater value, store the projected click position in this state, and then immediately switch the z_near to some near 0 value again that avoids clipping!

  • Free Roam Roguelike Racer

    Here's how the project looks after exporting to 3.0 in beta 1, which correctly works with .obj files.


    https://gfycat.com/pl/gifs/detail/ReadySadAmericancurl

    And here's a WIP of the day/night system, based on some 2.1. scripts by Khairul Hidayat:

    https://gfycat.com/gifs/detail/MintyJealousFerret

    (Embedded Gfycats experience a rather drastic loss of quality, so I recommend clicking the link to view them on site)

    If you've looked at the project repo recently, I merged the 3.0 branch into master a couple days ago and have now started working on improvements, such as the day/night system above.

  • Is there a simple way to code in C++ (at least in the near future)?

    I have poor skills on programming, and honestly, I don't like doing this. But I admit that it gives a pleasant feeling of accomplishment when you get something to work.

    I tested the Nim bindings, but from what I understood, all GDNative bindings have common files:

    -The "godot headers", the Godot API in C code.
    Since the pure C is still the king of all languages, most languages can talk with a C library with reliability. That's made possible to script Godot with many different languages.

    -The languages bindings. Godot headers are generally found in the same repository.

    -The "natives scripts", created with two mouse clicks in the Godot editor.

    -The "GDNativelibrary" resource, created easily in Godot too.

    -A compilation script. You will run this file to compile your scripts. But you must respect the directory organization recommended (for example all your cpp script must stay in a "src" named folder).
    If you want to place your Cpp files elsewhere you need to understand this script in order to update the filepaths. (that's the annoying thing for me.) Edit: This script is provided by the binding.

    -The library you will create by compiling your C++ scripts. It's a single binary file per platform.

    -And of course your native scripts source code in cpp or whatever. The class must have the same name as the one specified in the native script. That's why Godot can found your code.

    Depending of the languages bindings, some additionnal stuff may be required but this should be documented in the readme.

    I tried to show that chain in a quick diagram. Sorry if the naming is not very accurate. (English isn't my native language).
    Binaries are in blue and text files are in green.

    When you run your project, your compiled scripts (the library) are dynamically linked to Godot, and no GDScript is required. (but you can use GDScript to call your library if you want).

    I don't know about you or other folks but my satisfaction doesn't come from just seeing my game finished already. It comes from the technique of making it. Imagine you go on a trip in a country by car. Now imagine instead you'd take the train. See my point?

    I understand that. Games engines hides all the technical stuff to accelerate the creation process. But if you love to code you will be frustrated, even GDNative follow the path defined by the engine.

    You can solve this by trying a little project without any game engines. The SFML C++ library might interest you. Or if you feel adventurous you can even try more low level libraries like Open GL, PortAudio, and dealing directly with the OS. With that you will become a master of game programming.
    I apologize if I wrote bad english.

  • New to Coding

    @Wigatron

    Godot is probably not a good place to start if you don't know how to code at all. There are a number of challenges present when learning how to code: first, learning to write a programming language; next, learning the principles of coding which are present in every general purpose language; next, learning to use the engine's code alongside your own code, which is a huge chore even if you know how to code. The former two are hard enough in isolation, and also necessary in understanding how to use the latter. Exacerbating the issue is the general lack of community and tutorials for Godot compared to the other big guys (Unity & UE4).

    Personally, I used this website to learn how to code years ago: https://learncodethehardway.org/python/ This site is intended for people who are absolute beginners at programming. Python has the added benefit of being very similar to GDScript, so you should be able to move between the two relatively easily. You could also try your hand at a C# tutorial since that's going to be in Godot 3: http://csharp.net-tutorials.com/ However it's more so intended for people who already have some grasp of programming, so it may be better to begin with the first resource.

  • Is there a simple way to code in C++ (at least in the near future)?

    I think GDNative is a way.....in the future I'm sure this will be better and better ( support for C++ through GDNative )....I mean, Godot 3.0 is mainly all about huge rendering 3D stuff improvements.....then stabilize performance and then other scripting possibility......Godot 3.0 is an important milestone in the history of Godot engine...this is a cut-off the fuse cord with a Godot 2.0 versions.
    I'm with Godot engine one year but..I saw....so many new things in Godot..it's incredible.....amazing incredible!!....this is strong free-creativity soul of Godot engine...and I'm happy to be there.
    I'm satisfied with GDscript so much.....it's more or less easy to write for novice or artist and at the same time sufficient for advanced users.....but I see your discomfort
    with none so easy C++ scripting in Godot.....so the future will show :)
    All the best, Bishop.

    P.S ...GDscript is module too and ( "..,is not part of the base engine" )...how it is written in Godot docs - docs.godotengine.org/en/latest/development/cpp/custom_modules_in_cpp.html

  • Is there a simple way to code in C++ (at least in the near future)?

    I have poor skills on programming, and honestly, I don't like doing this. But I admit that it gives a pleasant feeling of accomplishment when you get something to work.

    I tested the Nim bindings, but from what I understood, all GDNative bindings have common files:

    -The "godot headers", the Godot API in C code.
    Since the pure C is still the king of all languages, most languages can talk with a C library with reliability. That's made possible to script Godot with many different languages.

    -The languages bindings. Godot headers are generally found in the same repository.

    -The "natives scripts", created with two mouse clicks in the Godot editor.

    -The "GDNativelibrary" resource, created easily in Godot too.

    -A compilation script. You will run this file to compile your scripts. But you must respect the directory organization recommended (for example all your cpp script must stay in a "src" named folder).
    If you want to place your Cpp files elsewhere you need to understand this script in order to update the filepaths. (that's the annoying thing for me.) Edit: This script is provided by the binding.

    -The library you will create by compiling your C++ scripts. It's a single binary file per platform.

    -And of course your native scripts source code in cpp or whatever. The class must have the same name as the one specified in the native script. That's why Godot can found your code.

    Depending of the languages bindings, some additionnal stuff may be required but this should be documented in the readme.

    I tried to show that chain in a quick diagram. Sorry if the naming is not very accurate. (English isn't my native language).
    Binaries are in blue and text files are in green.

    When you run your project, your compiled scripts (the library) are dynamically linked to Godot, and no GDScript is required. (but you can use GDScript to call your library if you want).

    I don't know about you or other folks but my satisfaction doesn't come from just seeing my game finished already. It comes from the technique of making it. Imagine you go on a trip in a country by car. Now imagine instead you'd take the train. See my point?

    I understand that. Games engines hides all the technical stuff to accelerate the creation process. But if you love to code you will be frustrated, even GDNative follow the path defined by the engine.

    You can solve this by trying a little project without any game engines. The SFML C++ library might interest you. Or if you feel adventurous you can even try more low level libraries like Open GL, PortAudio, and dealing directly with the OS. With that you will become a master of game programming.
    I apologize if I wrote bad english.