Announcement

Collapse
No announcement yet.

The Siege and The Sandfox - A Stealthvania set in an ancient desert kingdom

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    That looks great!, One question are those debugging tools custom mode or came with the engine ( mostly speaking about the ones used in the AI the text displaying the controller name, behavior etc )
    Offering my Freelance Game Design ,Counselling and C++ Programming Skills!
    https://forums.unrealengine.com/show...ner-Counseling

    Marketplace Assets
    Melee Tracing Plugin:https://forums.unrealengine.com/show...Tracing-Plugin
    Medieval Combat Starter Kit:https://forums.unrealengine.com/show...at-Starter-Kit
    Foliage To Blueprint:https://www.unrealengine.com/marketp...e-to-blueprint

    Comment


    • #17
      Originally posted by Pedwar2 View Post
      This looks amazing indeed. Glad to see these paper2d projects coming up! We need more paper2d in the engine. When can we expect to play this beauty?
      We are looking at some time next year. Plenty more to do, but we'll share as much as we can along the way.

      Originally posted by alvarofer0020 View Post
      That looks great!, One question are those debugging tools custom mode or came with the engine ( mostly speaking about the ones used in the AI the text displaying the controller name, behavior etc )
      These debugging tools are part of the Gameplay Debugger. It can be a little tricky to get it to display, but it's very useful as you can see. Let me know if you have an trouble as I made myself a cheat sheet to get it running.

      The Siege and The Sandfox | Development Thread | Twitter | Twitch | Facebook

      Comment


      • #18
        Originally posted by Achilleon View Post
        This looks amazing.

        I got one question though, how did you made the lighting so good on the characters? Is there any way to use normal maps for Paper2D sprites/flipbooks?
        Thank you and keep up the good work! ^_^
        Hey Achilleon, thanks for the kind words. All the sprites in the game are just your standard, non emissive materials and accept the standard lighting of the engine, no normal maps here. The 'lighting' I assume you are referring to is just what our character artist has painted into the hero and guards to help give a sense of depth. No real easy way around that other than just handpainting each character frame by frame. Old school pixel art basically.

        You can use normal maps with sprites very easily, as they just use the standard Unreal material system setup. Tilemaps are set up differently for some reason and call in textures, not materials, so using normal maps there probably needs more thought. As we decided to not use normal maps (see below) I haven't looked much more closely into how I could use normal maps on tilemaps.

        Originally posted by Pedwar2 View Post
        For our game, we have been using sprite light to get our normal maps, then we add them to our sprites. We haven't messed with lighting too much in our game, but it does work.
        I've not actually used SpriteLamp in anger, only seen the website and various videos so this may be me getting some wires crossed, but what I took away from it was the user is basically drawing the RGB channels of the normal map for SpriteLamp and it just combines them together? I might as well just make the normal map myself in Photoshop and then pass a normalise filter over it via the Nvidia Photoshop plugin? It can do other stuff I assume such as make AO maps or allow dynamic adjutsment of the created normal with embosses and the like, akin to NDo, but I normally get those from the highpoly (obviously not really that applicable in a pixel art 2D game!) or use something like NDo or CrazyBump.

        We played around with the idea of normal mapping very early on in development and, whilst the results were quite nice, we always felt it removed something of the purity of the pixel art aesthetic for only a very subtle effect. There are some indie titles out there such as Megasphere and Dungeon of the Endless, that use normal mapped pixel art very well but ultimately it tends to work best on clean looking, hard edged "surfaces" (such as sci-fi environments, see MS and DotE examples linked) and our game has quite an old weathered look to most of the environment so it quickly just made the scene "noisy". It's also quite a lot of work for only a very subtle effect so the team decided against it.

        The Siege and The Sandfox | Development Thread | Twitter

        Comment


        • #19
          Oh wow, the gameplay debugger looks extreamly useful for the AI work i have been doing, I managed to get it to show up But im sort of confused on how to get it to show up the Information about a specific Pawn / AIController in the world, As well extending it to display custom informaion inside said AIController and Pawn
          Offering my Freelance Game Design ,Counselling and C++ Programming Skills!
          https://forums.unrealengine.com/show...ner-Counseling

          Marketplace Assets
          Melee Tracing Plugin:https://forums.unrealengine.com/show...Tracing-Plugin
          Medieval Combat Starter Kit:https://forums.unrealengine.com/show...at-Starter-Kit
          Foliage To Blueprint:https://www.unrealengine.com/marketp...e-to-blueprint

          Comment


          • #20
            Originally posted by Pedwar2 View Post
            This looks amazing indeed. Glad to see these paper2d projects coming up! We need more paper2d in the engine. When can we expect to play this beauty?

            We need more paper2d in the engine. For our game, was have been using sprite dlight to get our normal maps, then we add them to our sprites. We haven't messed with lighting too much in our game, but it does work.
            Thank you. I tried to make the normal look work but failed. I will probably ask for help later from you, but very later! ^-^ No need to derail the thread about my problem though so ending it here!

            Hey Achilleon, thanks for the kind words. All the sprites in the game are just your standard, non emissive materials and accept the standard lighting of the engine, no normal maps here. The 'lighting' I assume you are referring to is just what our character artist has painted into the hero and guards to help give a sense of depth. No real easy way around that other than just handpainting each character frame by frame. Old school pixel art basically.

            You can use normal maps with sprites very easily, as they just use the standard Unreal material system setup. Tilemaps are set up differently for some reason and call in textures, not materials, so using normal maps there probably needs more thought. As we decided to not use normal maps (see below) I haven't looked much more closely into how I could use normal maps on tilemaps.
            I see now. I worked on some tests and it seems that my culprit was the transluceny acting reeeeeeally weird when it interracts with any lighting around. Anyhow thank you and good luck with the project, we definitely need more of these! ^_^
            Fighting Game Template: PROJECT: Unreal Fighter 2D

            Comment


            • #21
              Oh this is great stuff - do keep blogging!

              Comment


              • #22
                Originally posted by alvarofer0020 View Post
                Oh wow, the gameplay debugger looks extreamly useful for the AI work i have been doing, I managed to get it to show up But im sort of confused on how to get it to show up the Information about a specific Pawn / AIController in the world, As well extending it to display custom informaion inside said AIController and Pawn
                Information on this is thin on the ground as far as I know. But what I do know is that it depends if you're running in PIE or Simulation mode. If you're in PIE mode, when you enable the debugger it'll pick whichever controller is closest to you (not sure if it's cursor position or world position). If you're in simulation mode, it'll use whichever one you click on - this is why it's preferable to be in simulation.

                I haven't yet had a chance to look at expanding it for your own purposes, but it's certainly something I'd like to get to in the future. Please do let me know if you get anywhere with it!

                The Siege and The Sandfox | Development Thread | Twitter | Twitch | Facebook

                Comment


                • #23
                  Reminds me of Prince Of Persia, UE4 style
                  System
                  ASUS G550JK - 12GB ram, Nvidia GeForce 850 2GB

                  ArtStation
                  Artwork thread

                  Comment


                  • #24
                    The game looks amazing - love your pixel art.

                    Game Design - Photogrammetry - Programming
                    Tutorials · Twitter · Twitch

                    Comment


                    • #25
                      Such a good looking game man keep it up !!

                      Comment


                      • #26
                        Originally posted by Frequia View Post
                        Reminds me of Prince Of Persia, UE4 style
                        Ding ding! 10 points. PoP is an inspiration and such a great series, glad it comes across in some form.

                        Originally posted by SchnitzelDude View Post
                        The game looks amazing - love your pixel art.
                        Originally posted by Kalleal View Post
                        Such a good looking game man keep it up !!
                        Aww gosh, thanks a lot. Nice words like this are creative types fuel. Us pixel pushers thank you for your kind sentiments.

                        The Siege and The Sandfox | Development Thread | Twitter

                        Comment


                        • #27
                          UI elements and never ending polish

                          With us now looking to build in a nice tutorial area for preliminary outside play testing, I decided to have a go at blueprinting out dynamic control GUI elements that would fade up and down based on player proximity as well as be able to switch out sprites depending on platform being used (such as Xbox, PS4 or PC). Now I'm a pixel pusher by trade and logic always makes me cry but I was quite surprised how easy it was for me to thump this out and I was quite pleased with the results.


                          I'm only so far along with it but the platform switching can be done within the blueprint via a simple variable so I'm assuming the code types in our team will be able to call that from a menu/option setup when the player decides what control system they are using and the game will adapt automatically. It will also eventually need to handles redefining the controls so it displays the appropriate button/key for the set action, but that's beyond the scope of what we need for the initial demo (and perhaps my abilities)!

                          In other developments, I have always been a bit miffed that the dawn and sunset images worked so well and were far more interesting to look at (even though they are background visuals and shouldn't really be distracting the player) than the night scene was, it came off as far more flat and dull. With this in mind, I went back to it and decided to give it a new lick of paint. I searched around the internet for ideas of how to make night scenes a bit more interesting and dynamic and looked to the sunset/dawn scenes already done as well. The strong light source is what really let me make parts of the scene pop out so I decided it's a clear enough night time, why not have the full moon bounce a lot more light down to the mountainside below and pick up more detail of the rivers and city in the background.


                          It didn't take too long to switch it up, I'm fairly happy with the results and it's another step in the right direction. Its only subtle changes from the old version for the most part and it may be touched up again in the future but for now we have plenty more to be getting on with. As usual, any criticism, questions or feedback are welcome.
                          Attached Files

                          The Siege and The Sandfox | Development Thread | Twitter

                          Comment


                          • #28
                            Looking good! Keep up the amazing work!
                            Good War Games.
                            Twitter: @goodwargames
                            Facebook: www.facebook.com/goodwargames
                            Unreal Engine WIP: Hyper:BAE
                            Unreal Engine WIP: Wasabi Horizon

                            Comment


                            • #29
                              AI Update #2

                              Creating a workable perception system for a 2D game in unreal has proved a much bigger challenge than we had expected. However, despite the initial problems we’ve managed to come up with something perfect for our needs. One of our coders, Rex, did a great job in creating us a bespoke sense configuration for 2D.



                              What we now have is a collection of several 2D cones, which give a much better representation of the AI’s sight. We’ve also offset the position of the visibility raycast to go from eye to eye, rather than the centre of each character.

                              These two changes have made a massive difference to how it functions, and give us much more room to add interesting gameplay features. There’s plenty of tweaking ahead but by and large the AI sees you when you think it should, and hiding from it is also much more intuitive than before.

                              Speaking of tweaking these values, Rex also implemented a new debug to replace Epic’s own Gameplay debugger for our purposes. It easily lets us know which cone/s we are in, and if the AI is successfully able to raycast to the player.

                              EQS

                              Unreal Engine has a really powerful tool known as the ‘Environment Query System’. This system allows you to ask questions about the environment around you, and filter it down into useable bits of data. Using this hugely powerful tool for a 2D game is obviously overkill, but the key advantage is that they are very easy to create and test just using blueprint and the in-game editor. My aim wherever possible is for everything to remain completely readable by anyone on the team, so they can make their own improvements and suggestions.

                              At the moment I’m only implementing a few simple tests, for example: ‘find the nearest waypoint I can successfully plot a path to’ and ‘pick a random spot near to where I last saw the player’. Here's an example of picking a nearby valid point (the blue points are discarded as the AI can't reach them):



                              I’m looking forward to expanding these in the future using a few simple tricks to help the AI make smarter decisions without cheating too much. For example, when I create a query to pick a random spot near where the AI last saw the player, I can weight the results towards where the player actually is (even if they are hidden!).

                              Last Known Position

                              Another important aspect of our perception system is the concept of ‘last known position’, which I’ll refer to as LKP from now on to preserve my sanity!

                              Unreal’s perception system has it’s own concept of LKP, but we aren’t currently using it just yet. My simplified version positions an object whenever the player leaves the view cones. This position is then used as a start point for a search, should the AI reach the point and still not get a visual on the player.

                              Having this LKP object also allows me to deploy another classic stealth AI cheat which I like to refer to as ‘6th sense’.

                              Imagine a situation where I pass through an AI’s view cones heading in a direction it can’t see. How do I make the AI seem smart and know which way the player has gone? Sure, I could make it super complicated by using things like Dead Reckoning combined with multiple EQS to decide which cover the player is likely to be in. This is the sort of thing you’d find in Crysis or Halo, and as such is somewhat beyond our scope as a 2D game.

                              Instead, the LKP is updated for a short time (~0.5 seconds) after the AI has technically lost sight of them. From the player's perspective, this usually just looks like intuition, and would only look like cheating if the time is too long. As with most things in life, this is best explained with a gif.



                              The green tick in the cross hair is my LKP. See how it continues to update even after the player character leaves the view cones.


                              Suspicion

                              Suspicion is what we use to determine what the AI thinks is worth investigating, and later chasing after. The rate the suspicion increases is determined by whichever cone the player character is currently in. If they are in more than one cone, the cone with the higher rate of suspicion is used.

                              Currently we have 3 cones:

                              Close Cone - Instant max suspicion. If the AI sees you here, it will chase immediately.
                              Mid Cone - Average level increase.
                              Far Cone - Small increase.

                              Note that currently this suspicion system doesn’t take into account how well lit the player is. I’ll try adding a modifier based on that during the next pass as right now I just feel it’d muddy the waters while we test out the basics.

                              I also added some code to cover colliding with the the AI. Spoilers - they don’t like it very much.

                              Behavior Tree


                              All these new features mean there’s a lot more going on in the Behavior Tree now. I think it’s time to start splitting these into separate behaviors . . .



                              There are a few other issues that have started to appear, now things are a bit more complicated - I have quite a few areas where I quite harshly abort sequences if things change (like for example the player leaves the AI’s sight) and these now cause visible hitching as the AI flip flops between two branches. I’ll need to take a step back and rethink some of these longer sequences and find some more graceful break points.

                              So, that’s all for now! What’s next?
                              • Hooking up all the animations
                              • Moving the view cone around (looking up and down, moving up and down slopes etc)
                              • Adding some placeholder sounds
                              • Lots of tweaking of the ‘magic numbers’ until it feels good



                              Thanks for reading! I’d be happy to hear any feedback if people have any advice or thoughts to offer here.

                              The Siege and The Sandfox | Development Thread | Twitter | Twitch | Facebook

                              Comment


                              • #30
                                I would never have known it was UE4, it looks like it was made using something that specializes in this sort of thing. Great work!
                                lunar-software.com | routinegame.com

                                Comment

                                Working...
                                X