![]() At first, it seemed a bit counter-intuitive, as we are a lot more used to a class-based relationship between game objects, but after some (a lot) of tests we began to understand how we could build our games with Godot’s “node” system.Įven then, and that was our first big problem with Godot, it took us a great amount of time to understand how to simulate what we know about Obejct-Oriented Programming in Godot’s context (as would be done in Unity or Unreal). The Engine’s features can be found in the official website ( ), but the most interesting one we found was its modullar approach in designing game-scenes: scenes can be reutilized, or incorporated in other bigger scenes seamlessly. In the end, we had two *somewhat* finished games (“Ambrigram” and “Illuminatis Everywhere”), and some game tests made by Professor Santanchè. At the same time we helped the freshman teams, we organized ourselves to explore Godot during the 24 hours of. We had our first contact with Godot as supervisors of Gamux’s Meeting Jam 2015, a Game Jam organized every March for Unicamp freshmen interested in game development (a friendly way of preparing them for the Global Game Jam 2016). * there is a great Gamasutra article about Open-Source game engines I highly recommend, that matches some of the Gamux development perspective: Other engine features made us more certain of our choice, but they’re soon to be discussed in the next part of the article. Even as beginner developers, these are problems we can try to attend to, while contributing to a Game Engine we are betting can make a big difference in the near future. Philosophically speaking, its MIT license is perfect for us to use* (it’s great to see FOSS incentives in the game development industry, and Godot source-code can also be studied and modified without any fuss), and as we could see from the community, some of the Godot’s biggest problem was its lack of documentation and need for more public game examples - design templates for game mechanics that everyone could understand and use. ![]() After some group brainstorms, Godot was suggested as a project tool. But… why Godot?Īt first, our intention was to start a project with some of the senior students of Gamux - something in which we could put our experience to use. In this document I hope to present the general first impression we got from Godot in one of the Game Jams we organized earlier this year - Matheus Jun Ota and myself making the game “Ambrigram”, Thiago Amendola in the game “Illuminatis Everywhere”, and Professor Santanchè in some engine experiments.ĭISCLAIMER: This will not turn out to be some kind of “Engine Propaganda” as newbie developers, we did our best to analyze Godot within a neutral perspective, and as this first-impression should show, even though we liked Godot, it wasn’t without some real problems we had to cope with. Being a new Engine, it holds a small but growing community our intention with this project is then to create incentives to “boost” the growing rate of such community, at the same time allowing people to practice and study new ways of developing games with the tools Godot provides. We’ve recently reunited some of the Gamux students to explore Godot, a very interesting open-source game engine that launched its first stable version (v1.0) in January (2015). I am also part of Gamux, a student research group focused in Game Development ( ) we are also responsible for organizing workshops, Game Jams, and other game-related projects in our university with professors and students from areas ranging from Computer Science to Visual Arts and Medialogy/Media Studies. In addition, the user can interact directly with the terrain by utilizing a pointer to adjust details near them.My name is Henrique Alves, and I’m a Computer Engineering student at Universidade Estadual de Campinas (UNICAMP, Brazil). The miniature is used for other things as well: for positioning objects, teleport to arbitrary locations and creating teleport targets. Interacting with the miniature works by simply touching a spot on the terrain surface with one's index finger and dragging it to the desired height. A hybrid interaction approach is proposed: a miniature world, which is a modification of the World in Miniature (WIM) metaphor, is available for making bigger changes to the terrain. First, different 3D user interface interaction techniques are looked at, then functions a virtual reality terrain editor should provide are determined. Therefore in this thesis a virtual reality terrain editor is developed for the Godot Engine. As of now a virtual reality terrain editor does not exist for any popular game engine nor as a standalone software, even though in some cases it would be useful.
0 Comments
Leave a Reply. |