Jump to content
  • Advertisement


Popular Content

Showing content with the highest reputation on 05/10/19 in Blog Entries

  1. 1 point
    I've had the pleasure working with @Brain on his game: Mr Boom's Firework Factory by assisting with some graphics as of recent. I'll post a link to his blog and gallery at the end so you can go and check it out. Long story short, @Brain had a container which he could use but it was over 260,000 Tris and had 5 texture sets, and 4 decal textures all 4k each. I offered to optimize everything but realized the meshes were too messy so I ended up just re modeling it all while maintain most of the same look (structure wise - not texture). I then baked, re-textured the container, and added the decals supplied by @Brain. The final mesh is only around 20,000 Tris, 1 texture set which is 4k (includes the decals within) which is a major reduction from the original. I did two different lighting setups to show case the containers. The first is more outside cloudy type HDR, the second is a clear blue sky one. Check out @Brain's blog, gallery, and project page below:
  2. 1 point
    Bionic Commando was chosen because I loved the NES game back when I was younger. I got the version for the GameBoy as well as the GBC version that updated a lot. The main mechanic is a claw that shoots out and grapples and pulls the player or lets the player swing. The player cannot jump, so the bionic arm is one of the main means of movement. It was this mechanic that I did not do well. Which makes this attempt a failure. I was able to get it working well enough but there were some game destroying bugs. These bugs around the main game mechanic could have been resolved if I redid it a better way, however, that is kind of the point of this RIP Method. Make mistakes, think of better ways to do them but move on without refactoring too much. Another issue I had this time was when I wrote out the gameplay elements, they didn't cover all the work that needed to be done. I will have to keep an eye on that to make sure I don\'t make that mistake again because that seriously messes up estimates... and hurts my motivation and my feelings. The rest of the game went well, learned a better way to handle enemy states, but I feel like it too can be improved a lot to make it even more reliable and efficient. There was some ways I thought of doing things but found better ways, for instance: I was working on letting an enemy type fall through a platform to drop down, but it was not falling. I turned off collision completely, but it was still not working right. Then I found that turning one collision channel made things work the way I wanted while still letting the enemy get shot by the player. It\'s a small thing, and something that makes sense when looking back, but when approaching a game engine with all its complexity, it takes some time to get used to not just finding functions but getting a feel for how the engine is designed to be used. The doors was another improved method that was made easier. But there are improvements I think that I can put in for those as well. Anyway, the third project is done. I learned more and feel like I've gotten a bit faster and more efficient even though it took longer, I spent less time working on it because it was interrupted by the game dev challenge I did which I'm counting as my fourth project. Which means that my next project is the last stage of the first level. I'm choosing Battle Unit Zeoth as the project, it's a game that I liked playing on my GameBoy when I was younger. It's a side scrolling shooter where you control a mech and shoot bad things while getting weapon upgrades. It was a short but tough game to get through.
  3. 1 point
    And now, with the scripting tool ready to be tested, and the beautiful placeholder as the main protagonist, it's time for some cinematic action. Remember: our goal was to make an rpg with a deep combat system and an entertaining story to follow (what else?!). The first thing you need to tell a story is having a story to tell. So, with a limited scope for lenght and complexity, I wrote two short scenes in my best adventure/fantasy parody style. The idea was connecting both scenes through the gameplay, making a short demo of what could be a game developed with these tools. The script is something along the lines of a couple of soldiers travelling through a desert to accomplish their super important quest, facing all kind of problems to continue their journey. What super important quest could that be? The omission of it makes it far more interesting than anything I could make up. I decided that two levels (two big scenes) was enough for a good demo. The first one being a desert, which I had to design. As the main goal wasn't a good level design, I didn't put much effort in it (altough in the next level, I tried hard making an interesting one). Even though, I think it's cute enough. So, in the intro cinematic we see these two soldiers talking about past adventures as they cross the desert. Of course, an enemy appears and then they have to fight it. The focus was not in originality, but entertainment. When I was happy enough about the script, I started translating it into the scripting tool. I splitted the work in two tasks: - Making the cinematic itself (controlling the behaviour of all characters and events in the scene). - Using a Unity plugin (Cinemachina) to "film" what the script was playing. So, on the one hand I had two characters talking for 30 seconds, and on the other I had to control from within Unity the camera behaviour. In retrospective, even if I liked the final result, I must confess I wouldn't do it like this again, mainly due to editing reasons (a living hell). Having the camera control independent of what's happening in the screen means that if I change anything (ANYTHING!) in the script, I must synchronize the whole cinematic again. That's a lot of testing and debugging. A LOT. In the following cinematics I made, I controlled the camera transitions and behaviour from nodes within the tree script, so unrelated changes usually don't affect camera behaviour. And after some work (the whole process took me a couple of days, I blame the camera issues), I finally had my first cinematic. Feel free to comment about it. So, we now have a combat system, a scripting tool, a silly story and a cinematic. The following step is using all of these things to make an actual game.
  4. 1 point
    Welcome to our third blog post! In this, we'll be showing off some of the innerworkings of our Structures. This includes a full overview of both integrated and planned content. We'll discuss each Structure's purpose and how they tie into Moonrise's RPG-like system. But before we dive into the Structures, we need to talk a bit about Resources… --- Resources allow for the construction of new structures, spawning and advancement of units, and eventually- researching upgrades. Nature is the easiest and most abundant to collect. Water is also fairly abundant, but just a little more difficult to acquire. Pages are much more difficult- there are many ways to gather them, but the most common is by slaying enemies. They are the main resource. --- In regards to resources, Harvesters are used to automatically gather from the world around. The most basic of them is the Harvester. It allows rapid collection of Nature. Greater Harvesters emphasize gathering Water. And Master Harvesters allow for consuming Nature and Water resources to create Pages. --- Now, with resources complete- The quintessential structure is the Home. With it, life can be created, and the warriors can assemble. Disciples are the most basic of which- they only cost Nature. Magicians, however, are much more advanced, but well worth their cost of Nature, Water, and Pages. --- Defensive Structures include the Sanctuary, Haven, and Evaporator The Sanctuary is used for health regeneration of any ally nearby. Similarly, the Haven is used for mana restoration of nearby allies. And the Evaporator is for defense against nearby foes. It casts both powerful spells and emits a harmful aura, damaging nearby enemies. --- Our last set of Structures are our most important. They are the Libraries and the Lecture Hall. These Structures will be used for advancements. This can include anything from bonus statistics to unlocking new classes and spells. The Library is used for advancing unit stats- health, mana, regeneration, and so on. Bear in mind- all these advancements are permanent, and go across all warriors. The Great Library is for advancing units, and unlocking new ones. Within the world, you can collect powerful artifacts called Tomes. These artifacts are used for taking units beyond their basic tiers and into their most powerful state. The Dark Library is used for utilizing a unique and obscure unit type- the Narya. This includes being able to summon said Narya, alongside emplacing its spells on your regular units for even more customization than current. Last comes the Lecture Hall. This is for acquiring new spells on your units, costing resources and requiring tomes or other unique artifacts. --- That concludes our list of Structures. Thank you for viewing our page! Thank you for viewing our post!
  5. 1 point
    Despite a strong start time is already creeping up on me with the end of the challenge at the end of May. I actually have to go away before this so I have even less time. However I'm confident I can have a couple of playable levels. Android I managed to waste a week trying to convert the project to Android. Support for OpenGLES 2.0 is new in Godot 3.1, and well, it's a bit flakey. This is not entirely Godot's fault, the GLES2 scene is a nightmare in general I know from writing GLES2 code. The problem is mostly down to a lack of standardization in what features devices will support, and bugs in the devices and drivers. Really they should have standardized a number of tiers for GLES2 devices, and mandated support for certain elements in each, and had rigorous testing. But instead, the situation is like the wild west, with devices picking and choosing features to support. This makes development and testing a nightmare. So my current situation I have an Android phone which Godot doesn't support at all (too early Android version, godot had to update the signing method, something to do with security at google play not allowing older APKs), and on my tablet, I can run the game up until a skinned character appears on screen and then it crashes. The godot skinning method is not supported on all devices. Open source of course means that the onus is on ME to fix these bugs .. and I have Godot compiling in QT Creator and the export templates, but clearly a significant investment in time will be necessary to be able to fix such things in the renderer. Unfortunately the core team don't seem to be working on ES2, perhaps more working on Vulkan now. That would be one thing I have noticed about the Godot project, is that there is a lot of effort towards implementing new features, however some would argue that bug fixing should take greater priority. This is perhaps a feature of open source, where people will work in preference on interesting new features rather than boring bug fixes. Anyway I have decided fixing Godot has to take a back seat for now and I am concentrating on getting working gameplay. Some things I have been working on: Improved terrain rendering / collision Procedural level generator Artwork for platforms, health and fuel generator platforms Camera improvements I still haven't decided on the objective for completing the levels. It may be just crossing from A to B, or it may be transporting an item with the tractor beam. Or destroying a certain number of things .. perhaps I could have varying requirements on different levels. I'm not sure what is going to happen on the artwork side, it depends how much time I have. Ideally I'd like to create a full set of specific space models, but if no time I can reuse some of the frogger ones. Once again, 3D Paint is proving awesome on the artwork creation front. I must get around to making some windows builds.
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
  • 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!