Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation since 05/25/18 in all areas

  1. 6 points
    Background It's been a few days since I put my latest alpha of my entry for the Tower Defence challenge on itch.io and my project page: https://lawnjelly.itch.io/ramsbottom I think I've covered the requirements for the challenge, and made the game a bit above just the requirements so it is a bit more fun to play and has some longevity. The reason I entered this time is because I'd been watching the previous challenges with a little envy, and had been waiting for one that seemed simple enough (I think the last one I looked at had multiplayer and I knew that could be a bit of a bag of worms). My usual low level c++ / opengl approach would probably be overkill for a small / low timescale game, so I decided it would be a good opportunity for me to try out Unity engine, which a lot of people are using currently. What went right 1. Using Unity Rapid development, well suited for this type of small game. 2. Attempting to get as much of the challenge completed asap, then leaving further time for more features / polish. I finished much of the base functionality in the first week, then spent time on and off in the next few weeks just making it better. There are lots of advantages to getting something 'finished' up front, and this is a development model I am trying to move towards. You can 'call time' at any time, and still have a functional product. Unforeseen events always seem to appear and limit the time you can spend on a project. This approach guarantees that even in this situation you will still have a 'product' rather than a half-done version of your 'glorious vision'. 3. Using the asset store, not building all the models myself, and using sites such as freesound for the sound, and creative commons music. For small learning games such as this it didn't make sense for me to make the assets. I know it takes me 2/3 of the time to make artwork etc, and while I am improving at it, I am better at (and enjoy) programming more than making artwork. 4. Finding some good tutorials to learn Unity (then throwing out their approaches!). There are some great tutorials out there (brackys for instance), and these are good for learning unity specific stuff, but in some cases I could instantly see better ways of doing things. I put this down to many tutorials being pitched at total beginners, who are happy to get anything on the screen. But e.g. using Unity editor to lay out levels just seemed ridiculous and limiting. What went wrong 1. C# . I hate it, absolute abomination of a language. I spent more time than should ever be necessary screaming at the damn thing, it makes visual basic look like Shakespeare. I could write a whole blog post just on the things about it that make me seethe, but yeah, if I could avoid ever having to use it again, that would be great. 2. Monodevelop Yeah, see point 1. Pretty bad. I might have to see if I can get another editor working if I use Unity again. I hear VS code may be worth a go (I'm on Linux). Monodevelop seemed really keen to reformat my code in stupid ways I couldn't turn off, and kept trying to autocomplete words incorrectly (that I also couldn't turn off). 3. Lack of debugging support. This may have been due to my setup, it might not be straightforward to get debugging working on Linux (I'm assuming with Unity it is possible to do step by step debugging?). This meant huge problems debugging anything but the simplest code (I had to resort to lots of Debug.Log statements). 4. Unity editor. I'm not really a drag and drop sort of guy. I tried to avoid having half the game 'code' being a particular setup in the drag and drop editor. I'm not even sure how to backup that stuff, I'm sure if I'd have had a crash I could have lost the lot. Come to think of it, did I have to backup all the assets too? With all that .meta stuff? I don't know. At least with code you can zip it up small and keep lots of backups. There should be an option in the menu to save your entire project in a compressed form without all the bloated assets etc, just the stuff that is a pain to lose. 5. Unity build times. I had massive problems with excessive build times taking hours when changing platform particularly, it kept baking lightmaps (or maybe something with shaders?) when as far as I knew I had tried to turn them off. Eventually more by luck than judgement, I found that deleting some skydome assets I had imported and deleting (rather than turning off) an extra light finally cured the problem. Far too little debugging info is given out by the build tool logs, to enable you to know WHY your builds are taking hours. Googling reveals I was not the only one with this problem. Don't just tell me 'baking lightmaps', tell me which light is causing this, which objects etc etc. Conclusion Overall I found the challenge very worthwhile. There are several of us working on it, and bouncing ideas around and spurring each other on works very well. Also a little hint of friendly competition is good too! I managed to get fair basic grounding in Unity, and have a better idea of whether it would be worthwhile using in any future projects.. I may use it for a couple more small games, or evaluate some more current engines (Unreal, or perhaps something more code orientated). Doing such small projects is also great for experiencing and practising the whole development cycle including release and marketing. This can give a much better perspective on how much time you should invest in different stages, and improve your ability to schedule / finish larger projects. It is something I would recommend to beginners through to advanced developers.
  2. 3 points
  3. 2 points
    Ohhlalala!!! your done bro! Kudos to all of you guyz ^ _ ^ y | <3 Awoken post Need to catch a plane... ( I'll try to finish challenge even on the field : - D )
  4. 2 points
    I think, in this case they may be referring to a different type of loop, as described by Daniel Cook in this Lost Garden post. In this usage of the term, it would be part of the game design. Ambiguous wording on the part of whoever designed your template - is there any additional prompting or examples along with the template that might clarify whether my guess is correct? Otherwise, I would agree with Tom, a game loop in the traditional programming sense is not something that would typically need to be detailed in a design document (but might appear in a Technical Design Document if you have specific requirements). The other type of loop described in the link is a newer use of the term, that isn't necessarily understood everywhere without clarification.
  5. 2 points
    This is C code (even if it's written in C++). I C, all function parameters are passed by value. You're passing the pointers by value. That means they get copied in, and then on function exit get destroyed. If you're trying to have the side effect of modifying an argument passed to a function, then you must either pass it by pointer (for C or C++) or by reference (in C++). That means you function either need to be this (C or C++) void AddNextCSG(TCSGInfo** first, TCSGInfo* to_add); or this (C++ only). void AddNextCSG(TCSGInfo*& first, TCSGInfo* to_add); And yes, in the first case you need to dereference the pointer-to-pointer when assigning to it.
  6. 2 points
    Intro: So this thread is going to be the place where I plan out the game design and mechanics of my survival crafting game. While I'll mainly be focused on my game feel free to input your own thoughts and ideas about survival crafting genre in general. So yea I strongly believe there are two types of game developers, those who jump right in and try to figure it out as they go and those who don't start coding until they have an actual structured plan about what they want in their game. I fall into that category. So the engine that I plan on using is RPG maker MV, mainly because unity scares me and RPG maker fits the aesthetic of what I'm going for better. Core Gameplay: So the Core gameplay loop involves the players moving around the different environments and collecting resources, while avoiding enemies. The resources can then be used to upgrade their base and gear which will in turn allow them to better explore and loot areas of the map. Elements: So to make things simpler I've broken down the mechanics into groups, or key elements of gameplay. I'll go more into detail on them in different posts and maybe add more, this is just a brief summary. Base upgrade: Definitely planning on this being one of the big features of the game. Right now I'm thinking the upgrades will consist of base defensive (so like structure reinforcement, fences, maybe turrets), as well as department./room upgrades (so like upgrading your crafting bench or maybe adding a science room, or helicopter pad, a farm, water and bullet plant) Item/Weapon/Armor crafting: Pretty straight forward. Craftable items will include stuff like health, armor, and weapons and other items used to help with further exploring. Player Stats: I want to keep this part pretty simple with only a few basics stats the player has to worry about and have a direct impact on gameplay. The biggest problem that i'm going to have to worry about here is how to make the narrative work with the stats. combat: Another element that I want to keep simple, well in terms of actions the character can take anyway. X to melee something and Z or C to shoot/reload. Beginning level enemies only take one hit to die while harder enemies will take more than one hit. I want to set combat up in a Dark Souls style, where the challenge/fun factor isn't so much in the combat itself but rather the player figuring out the best/most efficient way of moving around the areas and dealing with the enemies. And that's it, like I said I might add in more elements the more I continue to design and plan out the game but for now those are the big 4. Will talk about them more in depth in the posts below.
  7. 1 point
    Tricky keeping an eye on both the posts there and here and timeline .. but yeah that suggestion about splitting up your floor into a grid, doing your deform with whatever you like noise algorithm sounds like a start. You could then run a mesh simplification on it to reduce the polys if you wanted (might not even be worth it depending on resolution that you want). You might need to lock certain parts to certain heights (like linking bits around doors), and maybe blend these into your noise heights in the surrounding area. Uneven floors may introduce other issues which need dealing with, leg IK, collisions, line of sight etc. So maybe think carefully whether you might want uneven walls and ceiling too in the future, as it may be easier to deal with it all at once rather than retrofit other stuff later.
  8. 1 point
    So I'm now finished with a basic firing mechanism for the turrets. They target, shoot at and kill the enemy ships now and add money for each kill. I ran into an issue with aiming the turrets at he enemies. The turrets wouldn't turn correctly and and there were a few issues with the aiming that I had to work out. I have a collision sphere around each turret that detects when an enemy enters and leaves its radius. I keep a list of the enemies that is within each turrets power radius and so far have one algorithm for finding the enemy in the list that is closest to the base. I will be adding 2 more algorithms one for strongest enemy and one for weakest so the player will eventually be able to choose between the two. I ran into a an annoying bug that took a while to get it working right, turrets would turn too slow and not get all the way to the targeted enemy but here is what I ended up with that finally seems to work good. After the rotation I do a quick line trace to determine if there is an enemy ship in front of the turret. This was probably the hardest to figure out and get it working correctly. All that is left is to pause turrets when the game is paused, subtracting health when the players base is hit and adding 20 rounds. Then work out all the kinks to get it all working together smoothly and make it fun and tricky. Then I should be about ready for a 1 level demo. http://www.hunter-gaming.com/ https://www.facebook.com/indiehuntergaming/ https://twitter.com/HunterGamingInd
  9. 1 point
    No problem, it's okay Maybe I should start asking my questions outside of the beginners section now. I wasn't sure what was considered beginners. I actually found this site which tells me all the features my GPU supports, but I found your link more useful. I'll try using your link as a guide and see if I figure it out, or hopefully a WebGL user can pitch in as well. Thanks again for your help Lawn, hopefully I can figure it out, or somebody can also contribute with further suggestions. If I figure it out, I'll definitely share my solution here.
  10. 1 point
    Your game sounds a lot like https://wildmagegame.com/, it uses a very destructive terrain. Uses Unreal. I still think the engine you should look into is the Unreal engine. Mostly because you know C++ and because you will need a lot of power to swap meshes around dynamically. This video gives a good idea of how many polygons unreal can render: https://www.youtube.com/watch?v=oMIbV2rQO4k it is a trick of course. But one that could easily be used with voxels. The other advantage is that after you made your terrain system you would still benefit from the massive amounts of extra tools and options Unreal has.
  • Advertisement

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!