Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About PhilDev

  • Rank

Personal Information


  • Twitter
  • Github
  1. This time I want to post something that is not related to a game I’m working on right now but to the engines I used making the last two games. Game #2 (Castle Adventure) was made with Godot and Game #3 (Tapmoji) with Defold. I mentioned on Twitter that Defold was completely new to me and I was asked by the Defold engine developers themselves what my on-boarding experience was and if I could compare the ease-of-use and the feature-set with Godot. At first I want to mention that I didn’t try every single feature in both engines. In general I don’t have much time so I focus on making 2D games as fast as possible. So I only used the features that were needed to finish these games and didn’t try everything. Maybe there are still features I don’t know very well that would be important to mention. Godot Setup I used Godot in two game jams already and I think I know this engine a bit better than Defold. I really like this engine! The reason being, it was the first engine I used where it wasn’t necessary to download additional stuff or install anything. You can just open the downloaded file and start your project. Example Projects A second big plus was the large amount of example projects that can be chosen right from the editor. The Godot community seems to be very active and this reflects in the large number of examples. GUI The GUI is very clear and intuitive in my opinon. It’s divided in 4 parts: On the left there is the file system of the project and the scene hierarchy, which contains the nodes of the current scene. The inspector is on the right where you can change properties of the currently selected node. In the main area you can switch between the scripting editor and the graphical 2D or 3D scene editor. In the bottom area you can switch between the output console, the debugger, the audio editor and the animation editor. The Godot editor Scripting Language and Editor The scripting language is GDScript, with a syntax similar to Python and some optimizations for the Godot engine. The automatic code completition in the editor is really helpful and speeds up coding really fast. Since the release of Godot 3.0 it is possible to code with C# and C++ as well. The scripting editor in Godot Docs The documentation is very detailed and includes a huge amount of tutorials. Every single feature has its own tutorial. There are not only examples provided by the community, which can be chosen at the start screen of Godot, but also there is a GitHub repository which includes a huge amount of demo projects. Features In Godot you work with scenes. There is a powerful 2D and 3D editor where you can add and edit objects very easily. It is possible to choose from a large amount of pre-defined nodes for sprites, colliders, tilemaps, lights, sounds, particles, animations, networking and many many more. A nice, big feature is the built-in editor for key-frame animations. It is possible to change every single property of a node over time. Setting up keyframe animations was very intuitive and fast for me. It saves one from writing a lot of code. Godot has a lot of features which make developing 2D games very easy. My favourites are, as already mentioned, the key-frame animation editor, and furthermore, the TileMap editor and the simple approach to create frame-based 2D animations. Desktop, Web and Mobile export The desktop build aswell as the web build are very simply done with just a few clicks. When I was making “Castle Adventure” I used Godot 3.0. I couldn’t release a web build because it ran very slow. The problem was the number of lightsources and particles that are being rendered at once. I didn’t test it with Godot 3.1 yet, but maybe the web builds are more performant now. Issues Besides this Html5 perfomance issue there was also a problem setting up particles while making “Castle Adventure”. It was not possible to let particles emit in a particular direction. I found this Github issue related to this problem. Fortunately this was fixed in Godot 3.1! I used Godot twice in game jams already and had to forcibly work with Git. Honestly at both jams the whole team was not amused about the time we wasted solving merge conflicts. The problem occured everytime when two or more people where working at the same scene and pushed their changes to the repository. The quickest solution for this problem was making as many scenes as possible and splitting the work, so everyone was working at their own scene. In my opinion there should be an easier way to call nodes of a hierarchy by code. For example in Unity one can just call GameObject.Find(“Name”) whereas in Godot you often have to call every single node in the hiearchy until you reach the node you want (get_root(). get_node(“..”). get_node(“..”). get_child() …), especially when you try to call a node from another scene. This slows down coding, since I have to look up how to reach a particular node nearly everytime. Something similar to GameObject.Find() in Godot would be very nice! Edit: Thanks to some feedback I have learned that Godot has such feature already (Node.find_node(...))! Thank you! Defold Setup Like in Godot, there is no setup for installation. You just start the application and choose your project or an example project. It’s quite similar to Godot, only there are less sample projects. But what Defold does better: The sample projects are explained like tutorials. And this was really hepful to me. Less googling, yeah! Example Projects There are not only sample projects included in the editor, but also examples in the docs, and there is a GitHub repository with demo projects. GUI The GUI is a bit simpler than in Godot, since there are less built-in features. But the main part is the same: You have your project hierarchy on the left, in the central area you can switch betwen a graphical UI editor and the scripting editor. On the right you create your gameobjects and define their properties. The design is very simple. There are no additional windows for adding components or defining project properties for example. Everything works with right-click and choosing out of a context menu. The Defold editor Scripting and Editor The scripting language here is Lua. The Editor is very simple. The automatic code completition is not as powerful as in Godot. For example it would be nice to have auto-completition when typing URLs to gameobjects, which I have to lookup everytime I need one. Also I miss popular shortcuts like Ctrl+X for deleting a whole line of code or Ctrl+C + Ctrl+V (with nothing selected) for duplicating a line. But there is an option to open files in an external editor. So it is possible to open the .script files in an editor like Sublime Text or something similar. Defold scripting editor Docs On the Website you can find Manuals, where every component is explained with an example and a couple of nice graphics. There is also a section Tutorials, which contains 9 games with source code. You can test them directly in the browser. You can choose them also as example projects when you start the Defold engine. The third big help on the Website is the section with Examples which shows some examples of main components like Animations, Particles, GUI, Debugging and Input. Everything is explained very lovely and detailed, espacially in the Manuals. But the examples are focused mainly at developing 2D games. For working with 3D environments there is provided little information. Features In Defold you have collections, which are quite similar to scenes in Godot. Collections can contain Gameobjects or other collections. Gameobjects contain components which define its visual, audible and logic representation. To access objects or components in this tree structure, you have to write the path like an url. This makes it easy to access every component out of every scriptfile. To define properties of the application you have to change values in one single file. The game.project file. Very clear and compact approach. There is also a curve editor for animations. I never used it so far, but I think it’s really helpful when making particle effects. My absolute favourite feature is the possibility to build and hot-reaload on mobile devices. On Android you just have to install an app called dmengine. It was really helpful making “Tapmoji” for Android and has accelerated the development of this game very much. Finally, like in Godot, there is also a useful debugger. Desktop, Web and mobile export And again like in Godot, all exports are possible with just a bunch of clicks. To install the exported apk on an Android device you have to install the adb tools. Issues In general there are less build-in features then in the Godot engine. It feels kind of more low-level. This was noticable when I wanted to handle input clicking on an gameobject for example. Converting screenspace to worldspace coordinates is a thing you have to do on your own in Defold. Rotating gameobjects doesn’t work as I expected and experienced in other engines as well. There is no such function like rotateBy(degrees). Having helper functions for these things would make prototyping and coding faster. Fortunatly some helper exist! But not in the editor, you have to download them. There is something called Asset-Portal. There are some examples that can be simply imported as libraries into existing projects. There is also something really powerful for the input issue I mentioned above: Defold-Input. I had two problems making “Tapmoji”, that took me a lot of time: The first one was related to random numbers. Even though I initialized the random number generator with system time, I experienced strange behaviour. I spawned emojis moving from left or right randomly. But the first few seconds after starting the app, they all spawned at the same direction. The first few values seemed to be the same, not random. I found this post, which helped me with a really strange solution: calling random() multiple times before using random numbers. I think this shouldn’t be necessary 😉 The second problem was the web build: It was very slow in comparison to the desktop build. The solution here was to uncheck the V-Sync option in the game.project file. Having this option checked, there is a delta-time issue when running the build in browsers. Maybe there should be a short hint in the docs? The last and least important issue is related to the usability. Like mentioned above, I would like to use the scripting editor like every other editor, with the proven standard shortcuts. It simply makes me code faster. My Conclusion A big plus with both engines was the large amount of example projects that can be chosen right from the editor, they can help you find your way into the engine. Godot has more examples but Defold has some projects that are structured like tutorials, which is a lot more helpful in getting to know the engine. I like Python/GDScript more than Lua. Lua is not that popular, so I had to learn Lua before working with Defold. For me, it’s not as much fun as Python (why the hell do they start counting at 1??). But of course this is my subjective opinion, not an engine issue. Now let’s get to the feature set. Godot has more build-in features than Defold. It is advantageous to create 2D games fast. But having less built-in features doesn’t make Defold a bad engine. Under the hood, Defold is a 3D engine. It keeps things more low level, since this results in a wider range of possibilities for devs. However, the Godot engine started as a tool for developing 2D games, therefore it evolved as an engine which tries to make 2D game development as simple as possible. This results in more 2D features. With both Godot and Defold, developing the very first game worked faster than I expected. You get a lot of help and useful docs and examples on both sides. But there is still a big difference: Godot is open-source and Defold is not! I’m a big fan of the open-source approach and that’s a big plus for the Godot engine. I’m sure the Defold devs have their reasons for not going open-source (maybe beacause of the collaboration with King) but as you can see at the Godot project, this open source thing works just fine! Both engines are constantly being worked on and both communities are very active and growing. The devs of both engines reacted to my twitter posts, that shows me that they take care of their communities! 😉 Especially the Defold devs were willing to help me and wanted my feedback on their engine. That’s all! That were my impressions after using both engines for only a short amount of time. There are far more things to compare to each other, but as mentioned before, I don’t have that much experience with either engine. I hope that this comparison was informative for some of you and may help someone choose a new engine. I’m looking forward to the development of the engines in the next few years! View the full article
  2. PhilDev

    A Game A Month #3 – Release?

    Hey folks, another couple of weeks have passed since the announcement of my third game this year! Read this post, if you’ve missed it. At first: Sorry for the delay, again! This “A Game A Month”-Project is more ambitious than I thought. There is a lot that currently prevents me from game development. Last month I moved and now I write my master thesis. In detail: 6 weeks have passed since the announcement and I had only 10 days for coding (something about 25 – 30 hours). I think this is the first big lesson I learned, since I started this project: It’s very important to manage your time properly if you want to stay productive. I have to find a way to improve my time management skills. Maybe it will be better in the next few months 😉 Get to the point, is the game finished?? Yes and No. The idea was to make a simple casual mobile game using the Defold Engine. The good news is, that the game has a playable state. But it’s not in a state that I’d like it to be for publishing it on Google Play. Therefore I decided to publish the current state as a playable Html5 version on itch.io and take some more time to expand it and release it for mobile devices. So the mobile version will be the goal for next month. But for now, here it is: Tapmoji! Try it out and give me some feedback! You can play it in the browser on mobile devices, too. Current state The current state is as follows: The GUI shows three emoticons that have to be caught, the current score, a countdown and the remaining lifes. There are emoticons moving across the screen in different modes: horizontally and vertically, and popping up at random positions. After tapping on the needed emoticons, a new screen appears, showing that the level is finished. Tapping this screen starts the next level. With every level the speed of the movement is increased, so it gets harder to recognize the emoticons. Also the spawning interval is decreased, so there are more emoticons at the same time on the screen. Tapping on wrong emoticons decreases the amount of hearts. If the player has no lifes left or the time runs out, a “game over” screen appears, showing the total score. There are still some Todo’s! The game was already playtested by some friends, and it was well received! But the todo list list is still very long: Creating a menu screen Creating a screen showing collected emoticons Getting stars(?) for completing a level Using stars to unlock a new random emoticon More moving modes for emoticons More visual feedback for actions like tapping wrong/right emoticon, loosing a life, … Sounds Release on Google Play Originally it was supposed to be a short project that should be completed quickly due to lack of time, but for me it’s just too much fun to end it halfdone. And I think that this is a condition that is very important and valuable in game development. My experience with Defold Defold was totally new to me and I would like to share some on-boarding experience with you and compare it with my experience with the Godot Engine, which I used in my last project. I will take my time to compare these engines and publish another post in a few days regarding this topic. So stay tuned! Source code Of course this project is open-source and you can check the code at GitHub or download it right here: Defold_Tapgame_update2.zipDownload Have fun playing it on itch.io, and stay tuned for the release of the mobile version! View the full article
  3. It’s time to announce what the april-game will look like! This month I will take a look at the Defold engine and make a very simple casual mobile game. The Defold Engine Defold belongs to King, THE mobile game developer, which is known for the Candy Crush game series. It provides an simple editor with basic components you need for making a game, like a GUI for placing sprites and other components, a debugger, a console and the possibility to deploy the game by nearly one click for every platform. It has both 3D and 2D capabilities and makes deploying games for mobile platforms very very easy. The coding language is Lua. The engine is available for free since 2016. The Defold editor The Game The idea is to learn the basic components of Defold by making a very simple casual game for mobile devices. The main components will be Smileys! They will spawn and move across the screen, and the player has to tap on some of them in a certain order as fast as possible. This will also unlock new types of smileys. A GUI will show the current score, the time passed, and the smileys that have to be catched. I already worked on that game for about a week now and this is how the current state looks like: Screenshot of the current state Little time (again!) And again, this month I don’t have much time to make a great game… Therefore I will make it as simple as possible. So for example I wont do all graphics on my own. I will use smileys that are available for free. Also the gameplay will be really simple but hopefully addictive enough. Also I have to learn Lua first! It’s a scripting language I never touched before. Googling led me to this video: Learn Lua in one Video. I think it’s a good starting point. The plan is to deploy the game for Html5 and Android. I never published a game on Android before so maybe it will be released a bit later as I have to get to know the process of publishing a game on Google Play first. In summary, there are many new things to learn this time! Let’s see how far I’ll get. And I’m really excited to get to know Defold! Wish me luck! Source code Of course this project will be open source, too! Download the the current state from GitHub or right here: Defold_Tapgame_update1 (zip, 830 KB)Download View the full article
  4. PhilDev

    A Game A Month #2 – Release!

    A few days ago I published my second game – Castle Adventure, A Platformer using the Godot Engine – and finally here are some news related to the development process! As you have maybe noticed, it took me more time than just one month. Since I had exams in march I decided to take another month, because I was not really satisfied with the state and didn’t have enough time to finish the game. So here it is! A simple Platformer with eight levels with a castle-like setting, where a knight has to collect coins, avoid obstacles, destroy woodboxes, fight against enemies like ghosts and skeletons, find keys and open treasure chests getting new weapons. The player has three lifes and has to restart a level when he looses them all. The goal is to get through all stages and collect as many coins as possible. Progress There are some new features since the last update: A menu, which is simply a playable stage with the title of the game at the top. Destroyable woodboxes with spreading particles Possibility to collect coins 6 new swords 3 new levels Soundeffects and background music A outro screen Summary Generally, most of the features I added were very simple to implement thanks to the Godot editor. My favourite was the animation of the enemies. For example, the movement of the skeleton is made with keyframe animations without a single line of code! The movement of the sword, the creation and the movement of the background, the lightning, all particle effects and the graphical user interface were also done simply with the help of the editor. The most of the game logic is scripted in a file attached to the player. Like the movement and behaviour of the player and the events triggered by collisions with items or enemies. Generally, thanks to GDScript, a python-like language, and the useful code completition aswell as the included docs, scripting is very easy and clear, too. One of the most time consuming features was the possibility to dynamically change the weapon of the player when a treasure chest is being opened. There are two types of swords: a short and a long one. Overall there are twelve different swords and with every sword comes a card which is shown in the pop-up window of the treasure chest. Weapons Because the most things are done fast using the GUI Editor, I could focus more on graphical stuff and made my own castle tilesets for the platforms and the background, some obstacles like spikes, a circular saw and an animated zombie-hand and the swords, using Inkscape. Sounds, by the way, are all from OpenGameArt.org. Problem: Html5 performance Exporting the project into a Windows, Linux or Html5 Application is as simple as everything else in Godot. It is done with a bunch of clicks. But wait, why there is no Html5 version on the Itch.io page of this game? The answer is simple: the Html5 version was to laggy. Every level of the game has the most time approximately five lightsources being rendered at the same time. I think this is the main performace issue. Also the particle effects are slowing down the performace, everytime they appear. There was no time left to solve this and also I still didn’t update the project to the new Godot 3.1, which was released just about two weeks ago. I’m curious if this will help. If this will be the case, I will of course update the game and maybe even upload a playable web version. Conclusion I’m happy to have finished another game but, as ususal, there are still more things I would like to add. For example more levels, a better ending scene and checkpoints where the player spawns after getting killed. Maybe I will update the game someday. As mentioned many times yet, developing a game with Godot is very easy and fast in my opinion. There was no feature I struggled with for hours. The Engine is a good choice for both, fast prototyping of game ideas, and creating nice and polished games with every feature a game needs. The best thing is, that Godot is open source and still in development! Personally, I like to code everything myself, therefore I used engines like LibGDX so far (like in my last game, SuperShot). So it was a new experience to me to mainly focus on the graphics/art and do everything else with a bunch of clicks without planning much time just for coding. Like in LibGDX (which is based on Java) it is very simple to export games for all platforms. The only drawback in comparison to LibGDX is that you cannot just simply export and distribute a jar-File, which runs on Windows and iOS, but you have to export the project as an iOS application using a computer running the iOS operating system. Because of that i’m not able to distribute an iOS version of the game. But being based on C++ Godot seems to achieve a higher performance than LibGDX, which is a big advantage. Finally, I really like Godot, and I think I will use it in the future for my private 2D game projects! Sourcecode Of course this project is open source and you can check it out on GitHub or download it here: Godot_platformer_update3 (with release builds) (zip, 37,5 MB)Download Don’t hesitate to give me some feedback on the gameplay, the graphics and the sourcecode here in the comments or on Twitter! Download the game here (itch.io). View the full article
  5. PhilDev

    A Game A Month #2 – Update!

    Hello back! It’s been nearly a month since the announcement of the second game: Making a dungeon platformer using Godot 3. Unfortunately I had to deal with some exams in the past weeks and had not enough time to finish this game at the end of february. Nevertheless, I made some improvements and it looks great, yet! The more features I add, the more new ideas I have. The whole thing becomes bigger than expected. Therefore I decided to take some more time, until the end of march, and take the chance to make a really nice and polished game. Also, in the meantime the feedback to my last update on Twitter was really good, which motivated me to take more time and effort for this game. That means, I will not start to make a new game in march, since there is too little time to work into a new game engine and finish a whole new game. Sorry! New features This is how the current progress looks like: The player has 3 lifes, decreasing on collision with obstacle or enemy Dialog for choosing new weapon, when opening crate 8 different swords New obstacle: Rotating saw New obstacle: Grabbing zombie hand New enemy: Ghost New item: Potion, collectable by player, restores a life Ability to hit and kill enemies with sword A white “swoosh” effect when attacking with sword Player is getting hurt when colliding with enemy Particle effects: when collecting potion, getting new sword, kiling enemy, spawning zombie-hand New assets for the background: Windows Level transitions 4 levels Things to do Of course I want to add more levels, introducing in every level a new enemy or obstacle. I’m currently working on a skeleton which will move and throw bones. Also, I will add some moving platforms, which will add some variety to the game. With more levels there will be more swords needed, which the player will be able to collect. There will be also more things to collect, like diamonds or coins. I’m not sure right now, but I will eventually add something like that. Also, a small menu scene is on the to-do list. Furthermore it will be a lot of work to find fitting soundeffects for every feature of the game. There are far more things I’d like to add, but these are the most important ones and I think it’s definitely enough for the next two weeks, since I will also do the graphics on my own. That’s all for now! Check my Twitter for some small updates and don’t hesitate to give me some feedback on the gameplay, graphics or the source code! Source code Meanwhile you can download the current state of the project on Github or simply here as zip file: Godot_platformer_update2 (zip, 592 KB)Download View the full article
  6. Hello again! it’s time for a new announcement: This month I will deal with Godot 3.0, making a Platformer/Jump’n’Run! For those who are new here: I try to create and release a new game every month, using another game engine in every project. Last month I’ve created the first game using LibGDX, which you can play here: Super Shot. Feedback and comments are welcome! This time, the idea is to create a platformer with an atmospheric dungeon setting where a knight has to find his way through different levels, collecting treasures and fighting against enemies. Since I’m a big fan of Role-Playing Games, I would like to add some RPG elements. The player will be able to choose between different kinds of swords, armour and upgrades. To keep this simple, there will not be something like an inventory or skill system, but the player will be able to choose one of two upgrades, everytime he opens a new treasure chest. I’ve already created some concept art and took a first look at Godot. After about one day of watching tutorials and getting into Godot and with just about 140 lines of code, the result looks like this: Current progress This includes a tile-based level, dynamic lights, a tile-based animation of the player and his movement, keyframe animations for the sword and the key. What is Godot 3.0? Godot is a free and open source community-driven 2D and 3D game engine, which comes with a GUI editor with many nice and intuitive features. After downloading the engine you can start directly without installing anything. It’s very easy to create scenes like the one above with just a bunch of mouse-clicks. To implement game logic it is necessery to attach script files to objects and code in a python-like language which is called GDScript. You can also use MonoDevelop and code in C#. The documentation is included in the editor, which is very helpful. A really cool feature is the possibility to download simple demo projects right from the editor, for me this was a great help when I was adding lights into the scene. Screenshot of the Godot 3.0 Editor In general Godot 3.0 provides everything a 2D and 3D game needs: Audio, physics, math, animation, input, file I/O, creating GUI, shading, networking and even AR/VR interfaces. Useful links Here are some links for more information about Godot: The Godot website and download: godotengine.org Online-Documentation: Godot-Docs Some tutorials I came across so far: GamesFromScratch on Youtube (this guy does literally everything related to game development ;)) Godot Platformer tutorial series from UmaiPixel on Youtube Defining the Gameplay Components These are the main components that are necessary for gameplay: Tilemap based levels with background and collidable tiles (done) Player movement, player death (done) Dangerous obstacles like spikes etc. (done) Enemies Combat system Collecting keys, opening treasures (done) Upgrade system (GUI for choosing new upgrade) GUI showing hitpoints and stamina Level transitions Menu Creating graphics and animations, and finding suitable sounds is also part of nearly every single point mentioned above. Hopefully I will be able to finish them by the end of month. Let’s Move On! I really like the current state and the way these things are achieved using Godot. My next step will be to start implementing the combat system and some enemies. Come back in a week or two for an update and check out my Twitter for some screenshots! Meanwhile you can try out my last game (online): Super Shot Sourcecode Of course I created a Github repository for this project, too: Godot_platformer Or simply download the project directly: Godot_platformer_update1 (zip, 715 KB)Download View the full article
  7. PhilDev

    A Game A Month #1: Release!

    Yeah, it’s release time! Three weeks have passed since I started developing this game and now it’s finally finished. As announced earlier, I started to develop a Shoot’em Up using LibGDX. I posted two updates so far, and now it’s time to finally publish it. I’ve made a couple of improvements since the last update: New spaceship graphics, improved background More items: Shield-item, boost-item, more gun items Ability to fire a “Super Shot” when enough enemies were killed A logo for the menu Sounds The hardest part was to balance the game properly. I adjusted the gameplay very often and I’m still not really satisfied with the final state. It’s not that easy to make a game “fun”. So now it is your turn to playtest this game and give me some feedback in the comment section! 😉 There are still some aspects that need to be improved or changed and many many things I would like to add. But January is over and it’s time to get this finished and start a new project! I uploaded it to itch.io, where you can play it in the browser directly or download it for the desktop. Give it a try! Conclusion In general everything worked as planned since I had enough time for this project. More precisely, it took me about 30-35 hours to get this finished. On average I worked 1-2 hours per day. Honestly, that’s a bit more than I expected and I don’t think that I will have that much time every month, but I had a lot of fun with this project. As I already mentioned in the first post, I know LibGDX very well, so there weren’t many new things for me to learn. It was more about getting my first game finished and released, with the knowledge I have so far. I really recommend using LibGDX for creating such web or mobile games. It has everything needed to create even a 3D game. I am amazed at the size of the deployed applications: the jar file of this game has a size of 12.7 MB, the html export 33 MB. The only downside of LibGDX is, that it does not seem to be maintained anymore. The last update was in December 2017, as you can see on the News page of the libgdx website (as of the time of this post). Nevertheless, it brings everything you need to create a game and it works fine. I’m happy to finally release my first game and I’m looking forward to make the next one with a new engine! Stay tuned for the next announcement! Source Code Meanwhile you can check out the source (including all assets) of the release version on Github or download it here: Libgdx_shootemup_release_code (zip, 3.2 MB)Download View the full article
  8. Hi everyone! I’m back with an update of my first monthy game this year. I have made great progress and it seems like I’m on a good way to finish this game in January. Update: Clouds, explosions, health-bar, score Here is a short summary of the progress: Menu, pause and game over states Player death: By getting shot, collision with enemies and ground Restart handling – reinitializing gameplay Counting score, showing at top-right corner Showing health-bar, decreasing on hit Spawning non-shooting obstacles (clouds) Spawning items: Repair tool Additional “super”-class “GameObject” – For ShootingObjects, Obstacles and Items – for handling movement and collision areas Spawning explosion animation on enemy and player death Background shaking Dynamic player shadow Gameplay improvements Press to start! The game starts with a small menu now. It’s done very simple: At the start the gameplay is initialized, but the spawning of enemies and the updating of the player is deactivated, while the flag “started” in the Gameplay class is set to false. So the background is scrolling, which makes an ingame-feeling in the menu. At the center of the screen a label “Press to start” is shown by the GUIStage class. When the user presses space, the “started“-flag is set to true and the Gameplay.update() method spawns enemies and updates everything. The pause-state works nearly the same. There is a paused-flag, which is set to true, when the user hits escape. When paused is true, the whole update method does nothing anymore, but the Gameplay.draw() method still renders everything. A label “Pause” is shown by the GUIStage class. Game Over! As stated above the player can be killed now. This gameplay mechanic needed a bunch of things to be done. At first, the player can crash with the ground. Therefore a ground shadow was added. It gives the player a feeling of how much space is left between the ground and the spaceship. Furthermore a collision with an missile decreases the health attribute. To show the health to the player, a health bar is needed. It consists of two images rendered at the same position (Check out GUIStage.java). A border image and a red inner image, which width is set dynamically according to the health. To make the death more intense, a background-shake has been added and some explosion animations will spawn now. The explosions are spawned, too, when an enemy is being killed. I made this animation some time ago, so it did’t take a lot of time to implement this. Explosions are “SpawnObjects” which have their own pool, and are respawned by the SpawnPool, like enemies or missiles. Read more about the SpawnPool further down in the text. The explosion animation consists of 8 frames. At the player’s death, the gameover process is triggered. A short time offset of two seconds lets the explosion animations finish and makes the player realize that he just lost. The spawning of new enemies is stopped, the control of the player is deactivated but the background still moves. After these two seconds the “Game Over” label is shown and the player has to press a button again, to restart the game. Items Another new feature are items (Item.java). Items are spawning at a fixed interval with an own timer. They are managed by the SpawnPool, too. Currently there is only a heal-item but it is possible to define different types with own animations and effects. Items are surrounded by a bubble, which is an additional sprite rendered above the actual item. A heal-item in a bubble Obstacles To make the game less monotone, I had the spontaneous idea to let some obstacles spawn (Obstacle.java). In the current version, a wave of clouds spawns from time to time, which have to be avoided by the player. Of course, it’s possible to add more types of obstacles later on. The cloud with a thunder animation Level generation Since there are obstacles now, the generation of the spawn stages was improved. It works as follows: A stage has a fixed time limit (currently 20 seconds). Currently there are just four types of enemies. Every stage spawns another type of enemy. After four stages two types of enemies spawn at the same time for the next four stages. After these eight stages the spawn system begins at the first stage again, but with an decreased spawn interval to spawn more enemies. Check out calcLevel() and spawnObjects() in Gameplay.java. After every two stages, there spawns an obstacle stage, which pauses the spawning of enemies. The duration of the obstacle stage increases every time a new obstacle stage spawns, so this part of the game becomes also harder with time. The main part is done! So for now, all core mechanics and features work fine! This is where the fun part starts: creating and adding more enemies, missiles, items, obstacles, levels and, of course, sounds. Also the GUI and the menu need some polish. Finally, some balancing has to be done to make the game as fun as possible. I’m looking forward to the next update! To do: More enemies and missile types More items More levels Cosmetics (Menu, GUI) Sounds Balancing …drink more coffee! For those who are here just for the update: that’s all for now! Come back in a week to play the finished game! Until then, I appreciate every feedback and suggestion in the comments. For more information about this “A Game A Month”-Project read this post. Source code Check out the source code of the current udpate on Github or download it here: Libgdx_shootemup_update2 (zip, 1 MB)Download To import it to IntelliJ properly, check out my previous post. More code! For those who are interested: Like I stated in my previous post, I will dive deeper into the code in this blogpost. Especially the SpawnPool, which is the most important and helpful component of the game, I guess. Check out the next page! View the full article
  9. Welcome to my first attempt at making a game in a month! Thanks to the holidays I had some time to set this blog up and start working on my January-Game. The first game will be a simple Shoot’em Up made with LibGDX, an open source multi-platform Java game framework. It’s a framework I used many times so far and which I know very well. I think that’s good for the start as the risk will be low that I wont finish it in time. I can focus mainly on the game itself and don’t have to learn things from the start. The Game The goal is to make a simple endless sidescrolling Shoot’em Up in a cartoon style space/alien setting. The player controls the spaceship holding down one button (like in flappy bird) and has to shoot down attacking alien spaceships, surviving as long as possible, while the enemies will become more challanging with time. The GUI will show the current points and a life bar with the player’s ship state. If we can implement this basic idea early, we might also add some items that are upgrading the ship of the player Screenshot of current state The Engine and Tools LibGDX provides everything needed in a 2D game. Audio and input handling, math and physics, a 2D particle system, tilemap support, a 2D UI library, OpenGL helpers like Shaders and even a high-level 3D-API. It is very easy to deploy a project as a desktop, android, iOS or Html5 application. There is no editor like in Unity or Godot, so you manually have to write code in Java. But there are some useful tools like a particle editor and a texture packer, which can make this task easier. After downloading and executing the LibGDX Setup App you have to open the project in your favourite Java editor. It is necessery to install the Java JDK. Personally, I prefer to use IntelliJ for coding in Java. Setting up the project in IntelliJ is explained further down in the text. For creating some assets I will use Inkscape. Summed up, the setup looks as follows: LibGDX Setup App Java JDK Editor: IntelliJ Graphics: Inkscape What components we will focus on? The game will feature follwing main components: Animated objects Scrolling parallax background with layers Object pooling Collision handling Playing sounds User Interface LibGDX project setup with IntelliJ The Setup App To create a LibGDX project you have to execute the LibGDX Setup App. I checked “Desktop” and “Html” as it gives me the possibility to publish the game in the web later on. Besides, I chose “Tools” to have the option to add particle effects. The Setup App. Make sure that the Java JDK is installed on your system. Import to IntelliJ To import the project to IntelliJ you have to click on “File > Open…”. Navigate to the project (here: Spacegame) and doubleclick on “build.gradle”. Confirm the next dialog with “Open as project“. In the following window make sure that the Java JDK is chosen. I prefer to check “Use auto-import”. Hit OK and wait a moment for Gradle to build the project. Next, it is necessery to create the desktop launcher configuration. In the Project window go to “Spacegame > desktop > src > .. > DesktopLauncher. Rightclick this file and click on “Run ‘DesktopLauncher.main()’”. This will create a DesktopLauncher configuration. Don’t panic, we will fix the error that should show up now. The last step is to link the assets folder with the project. Go to the “Run” menu and click “Edit Configurations…”. Choose “DesktopLauncher” on the left. In the “Configuration” tab, fill the “Working directory” attribute with the path to the core/assets folder. In my case “D:\dev\Projekte\LibGDX\Spacegame\core\assets”. Now it should be possible to run the application hitting the green arrow on the top-right corner. Everything happens in the “core” module. Spacegame.java is the starting point. In the “desktop” module you can find the launcher file for the desktop application of your game. It does nothing more than loading Spacegame.java. If we would have chosen the android module in the setup app, it would also have an own folder with a launcher file. You should check out the documentation for more information about setting up projects (in IntelliJ, Eclipse, Netbeans) and more stuff. Some good tutorials on LibGDX are: GamesFromScratch.com And on GamesFromScratch on YouTube A LibGDX Game Template Since I worked with libGDX already, I have a template which I reuse often. You can clone it from Github or download it right here: Template Project (zip, 362 KB)Download You can import it in IntelliJ like described above. Don’t forget to link the assets folder. The template project consists of two Screens: a loading screen (LoadingScreen.java) and the gameplay screen (GameplayScreen.java). The base class and the starting point for the LoadingScreen is GdxGame.java. The loading screen is shown as long as the asset manager (Resources.java) is loading the asset files. There is also a basic input class (GameInput.java) and a class for creating 2D animations (AnimatedSprite.java). GUI elements like fonts and buttons (Scene2D elements) can be implemented in GUIStage.java Gameplay.java is the starting point for adding gameplay code. It loads an example animation. Feel free to download and to test the project. The template includes this tileset with spaceship animations I made some time ago: Spaceship tileset. Original size: 1024×1024 Shoot’em Up Code Structure Now back to our “Spacegame”. It’s time to describe how the code will be structured. The GameplayScreen (GameplayScreen.java) will manage the user input (GameInput.java), the GUI (GUIStage.java) and the gameplay. Gameplay.java is the class where the actual game will happen – creating, updating and drawing the background, the player, the enemies and reacting to collisions and input. The following diagram shows just the basic structure of the gameplay components. Of course, we will add more classes later on. Basic code structure As the player and the enemies will have nearly the same functionalities, namely beeing animated, shooting and being shot, there will be a base class (ShootingObject.java) which Player.java and Enemy.java will inherit from. ShootingObjects will spawn missiles (Missile.java). To take care of the Java garbage collector, we will use object pooling. We will not create a new instance of an enemy or a missile every time when a new one has spawned, but reuse objects that are “dead”. Therefore we need a spawn pool (SpawnPool.java) which manages all spawn objects. A SpawnObject.java interface will be needed for the enemies and missiles. ParallaxBackground.java handles the scrolling background layers (ParallaxLayer.java). Current progress Finally, it’s time to show how the actual state of the game looks like. The background movement, spawn pooling and collisions are working well so far. But there are still many things to do. For example the GUI, a menu, more enemies … But hey, it’s a playable state! Current state of the game Get the sourcecode on Github or download it right here: Libgdx_shootemup_update1.zip (419 KB)Download That’s all for now! In the next blogpost I will dive deeper into the code and show how loading resources, using animations, background movement, object pooling and collisions work. It is also planned to make a short how-to for the assets I created with Inkscape in a future blogpost. I’m really excited to show you some progress! Don’t forget to follow me on Twitter to get updates! See you soon! View the full article
  10. PhilDev


    Hello, I’m Phil, a hobby game developer who wants to share some experiences with the world. As I worked on many private hobby projects so far but didn’t really release anything, I decided to start a blog which will hopefully motivate me to finish and to share some games and experiences with the gamedev community. The main idea is to create a new, simple game using a different kind of technique/engine every month . I will compare the engines by showing all the positive and negative aspects I had to deal with. Another goal is to get an overview of the possibilities the engines provide, to know which would be the best fit for the ideas I (you) have. Since I haven’t worked with many of these engines thus far, it will be a new experience to me nearly everytime I make a new game. This will also define the way I will write most of my blogposts: for developers who want to know how to get started in a particular gameengine, how basic things work and what possibilities the engine offers in general. Hopefully there will be a project at the end for each engine to serve as an example for my readers. Of course my projects will be open source and I will use Git to share my code. Engines These are the engines I will focus on first: LibGDX Godot Phaser Cocos2d-x Unity Unreal Engine Yeah, thats a lot of engines. Some are very big, some really small. Since I’m doing it in my free time, and one month is really a small amout of time to develop a game, I will focus on simple 2D games (unfortunately no AAA games, sorry guys!) , as 3D assets are taking a lot of time. Nevertheless maybe there will be some small 3D assets in some games (maybe in some kind of 3D platformer) as that would be a new experience for me as well. There are far more engines like MonoGame, CryEngine, Amazon Lumberyard, ShiVa Engine, Game Maker … but I don’t want to get ahead of myself. Let’s see what the future brings. More things to show Apart from this possibly I will also show some examples on how I did my graphics. I like to use Inkscape and I really have a lot of fun making cartoon-style 2D graphics. As I’m really happy everytime I see people blogging about graphics and stuff, showing some examples and simple tricks, I think I should do that too. So there will also be something more to see than just code. Wow, that’s a lot of stuff, dude.. For those of you who think so, you are totally right! But I think I have enough experience programming in different kinds of languages and creating games with differend kinds of engines. So new stuff shouldn’t be that hard to learn. Failing is also a part of the process of developing. If a project fails I will tell you why, show you the problems I had and publish the code anyway. Finally, I want to make clear what I will not cover in this Blog: I will not show the basics of each language (Java, Javascript, C#, C++, ..) as that would go beyond the scope of this blog. Furthermore I will not explain every single line of code. I will explain the basic concepts and the main parts of the code. Of course I will try to comment the code files as much as possible to make it understandable for beginners. If something is unclear feel free to write a comment. I will do my best to explain as much as possible. I’m really excited to post the first updates on the first game! Secret hint: it will be a game made with LibGDX! Follow me on twitter to be noticed about updates (@game_month). Stay tuned! View the full article
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!