translation missing: en.general.currency.dropdown_label

0 Cart
Added to Cart
    You have items in your cart
    You have 1 item in your cart

      Game Development

      Using Blueprints Effectively For Iteration

      A Comparison on the Advantages of C++ Compared to Blueprints



      Unreal Engine provides blueprints as an effective way of quickly iterating on concepts without having to wait for lengthy C++ compilation times between changes. Blueprints also provide a way for designers to access C++ implemented functionality in a visual way, so they can participate in iterating on gameplay without knowing how to code.


      Because of these strengths, Blueprints are best to iterate on ideas in their earliest stages. Compared to C++, Blueprints run into inherent maintainability problems as a result of their medium. Blueprints are more difficult to analyze, debug, and navigate compared to C++ code, because the C++ Visual Studio environment (with extensions) altogether has an incredibly powerful feature set which is not matched in Blueprints. A less experienced C++ developer without knowledge of these features and options might think Blueprints are the same if not better in those regards, and this is why this document exists.


      This is the only time in the entire doc performance will be mentioned, to keep the matter simple and in Blueprint’s favor. Even if Blueprints are just as fast in runtime execution as C++, we should still have nearly all gameplay implementations start in Blueprint, then implemented in C++ after iteration. While I don’t believe Blueprints are as fast as C++ due to having to work on a separate VM layer (the time cost happens when switching in and out of VM context, and moving data in and out of the VM) let’s just say for the purpose of this document, runtime performance does not matter.


      This is from a perspective of someone who has used blueprints in projects for 3 years, and C++ for about 7 years. A later section of this doc gets into it, but I also want to highlight that data-only blueprints have incredible value and should be a part of our projects, because they are the cleanest way to get asset references into C++. However, this document is about code implementation. The following sections get into the capabilities of debugging and navigation, as well as implementation time cost comparisons between C++ and Blueprints.


       Analysis and Troubleshooting of BP compared to C++

      Much of the process of fixing bugs involves analyzing the flow of control throughout the scope of runtime execution, and usually monitoring the state of data in one or more objects as code is executed. Doing this in the context of C++, there are many well established methods and tools provided. Some of these have equivalents in BP, but many do not. Additionally, the debugging features that are in both are less flexible and powerful in BP.


      Debugging - Breakpoints

      C++ and Blueprints both support breakpoints (pausing execution at a given line of code or node), and they are valuable for most debugging use cases. C++’s breakpoints with Visual Studio are incredibly powerful compared to Blueprint’s breakpoints.


      • Breakpoint conditions: C++’s breakpoints in VS support “conditions”. That is, the breakpoint will only trip if a given expression that you program into the breakpoint evaluates to true. For example, if (xObj.dataMember >= y), then use this breakpoint. Notably, these breakpoint conditions can be added and removed without recompiling, so they can be added as needed in the middle of a debugging session. This is useful for debugging code which runs extremely frequently, and only rarely exhibits a bug, so you can add a condition to your breakpoint to make it only trip when the conditions you define are met. Link to breakpoint conditions VS documentation
      • Data breakpoints: C++ in VS supports a very powerful feature called “data breakpoints”. Data breakpoints allow you to pause execution whenever data at any chosen memory address changes. This is incredibly powerful for debugging an entire category of bugs, in which data is being changed unexpectedly, and/or you’re not sure where the modification is happening from. Once a data breakpoint is hit, you can inspect the stack trace to see where the data write has originated from. This is useful to determine the cause of bugs for cases where the affected data is modified from so many different locations, to the extent it is not practical to use normal breakpoints at each line of code it is modified from, especially if those contexts are called frequently for purposes other than modifying the affected data, and most importantly, to potentially find an unknown source of data writes.  Link to C++ data breakpoints VS documentation
      • Breakpoint overview: In C++, you also get a breakpoint overview where you can see, search, and toggle all of your breakpoints throughout the entire codebase from one UI location. This is effective in cases where you need different breakpoints for different situations within a debugging session, and switching between sets of breakpoints quickly is needed for fast debugging. In comparison within blueprints, there exists no such control-table overview of all breakpoints - you’d have to manually go back through all the blueprints, find the nodes the breakpoints were on, re-enable them, and disable the old ones.



      Debugging - Watches

      Both C++ and Blueprints have “Watches'' as a feature - in which you can monitor some data or state while execution is halted, but again, C++ in VS has much greater capabilities with its watch functionality. In VS C++, you can watch the state of many objects across the scope of multiple systems, including the contents of data containers, where each element and its data members can be inspected freely. Blueprints also have a “Watch”, but it is only valid for variables that are local to the current blueprint context. Using Watches effectively is another critical part of debugging many types of issues, so having a worse form of “Watch” in blueprints makes the typical debugging experience more challenging than it needs to be.


      Preventative / Proactive Debugging - Static Analysis

      Something C++ has which Blueprints don’t is the ability to leverage static analysis tooling.  Static analysis results are very similar to compiler warnings, but static analysis tools can algorithmically find the places in your code where run-time errors can or will occur, and tell you about them. In this way, static analysis tools allow you to automatically find many categories of bugs (often, the worst kinds of bugs) without anyone having to play the game or use the software. The types of bugs static analysis tools can detect are things like uninitialized data access (like accessing a null reference), undefined behavior, memory leaks (if not using Unreal’s memory management for parts of the project), stack overflows, infinite loops (unintentionally stuck in while or for loops), numeric type overflows and underflows, array overruns and underruns, and much more. At any scale, static analysis can offer value to code quality and stability by pre-emptively detecting errors, similar to having an experienced developer review the code and point out places where there might be issues, or where there will certainly be issues. The value static analysis provides increases with the scale and complexity of the project. This post on the Unreal Engine site goes into some detail about the value of static analysis specifically in the context of Unreal Engine game development. A notable quote about static analysis is that John Carmack, the CTO of Oculus VR went on record saying “The most important thing I have done as a programmer in recent years is to aggressively pursue static code analysis.” Given that blueprints cannot leverage static analysis tools, that puts it at a severe disadvantage for maintainability at scale.


      Code Navigation

      Speed of navigating code (or nodes) is important when evaluating code, whether you’re analyzing it while debugging it, or remembering how a system works before you modify or extend it, or while visiting many sections of code during a refactoring session. C++ is substantially faster and more versatile to navigate than blueprints with the right tools and training. These tools are standard for UE4 developers, such as Visual Assist or Resharper C++. They are so unanimously used across UE4 developers, they both have UE4-specific features and settings within them, although their best features are universal to C++. The faster code can be navigated, the faster it is to analyze and make progress on. Both C++ and blueprints have a few common navigation use cases covered like “Find all references”, but Visual Studio and third-party tools provide even greater and more flexible options than blueprints. Here’s an example use case to demonstrate the power of a couple navigation options in C++ which I use constantly while working in C++ and C#, and miss whenever I work in Blueprints. There are many more, but 


      C++ Navigation - Symbol Search

      Imagine I want to find the class type of a data member in a “PlayerCharacter” class called “characterMesh” - not sure if it’s a static mesh, instanced static mesh, skeletal mesh, and so on. From anywhere in the entire codebase, in C++ with Resharper or Visual Assist, you could use Alt-Shift-S, type “char mesh” and press enter, then you will be instantly looking where the data member “characterMesh” was defined, in the PlayerCharacter class, where you can see its class type. If multiple things matched the filter of “char mesh” you would be able to see them in the context window and where they are defined (such as file name) and pick the one you intended before pressing enter. This is called a “symbol search” - it allows you to search the entire codebase for symbols (identifiers) which match your filter. This is also very useful for finding things named after something. For example, symbol searching “weapon mod” would allow you to find all classes, methods, data members, and so on with “weapon” AND “mod” anywhere in their name, viewable in an organized list with file names, and preview each line the matching code was found in. Clicking any of them would take you to that line. The closest thing a blueprint workflow has is the ability to search all UE4 assets by pressing alt-O, and searching for a blueprint by name there, then opening it, and then searching for the variable by scrolling through the BP’s details.


      C++ Navigation - Peek Definition

      In C++, you can use the “Peek Definition” shortcut while selecting any identifier/symbol in code to pop up an overlay to see the code context of where that identifier was defined without leaving your current code context. This allows you to see both how and where it was defined at a glance, with even the ability to scroll through and modify code in the “Peek Definition” overlay, and quickly close out the peek overlay by pressing Esc key. For example, if I was working with an object of the “PlayerCharacter” class and saw code reference it’s “characterMesh” member like so: playerChar.characterMesh, and I wanted to quickly see what other data members are in that class besides “characterMesh”, I would just have to use the “Peek Definition” hotkey on the word “characterMesh” to immediately jump to where it was defined in the PlayerCharacter class, then press esc whenever I want to close the peek overlay to get back the full view of the code I was originally looking at. This allows for rapid context switching to get information about whatever it is you’re working on.


      Summary of C++ Navigation

      The above two navigation features are just a couple of many navigation features I use in C++ that don’t have a good equivalent in Blueprints. The visual assist page here Visual Assist - Navigation Features shows and explains many navigation features in just that extension alone, such as GoTo related symbol, Find by Context, and bookmarking code locations with VA Hashtags to rapidly jump to at a later time.


      Code Creation Time

      C++ is substantially faster to create than using Blueprints. Here are some tangible examples.


      Defining Functions / Methods

      Things like function definitions in blueprints have to be created by using a bunch of drop-lists, buttons, and text fields. For example, just adding an input parameter to a function requires clicking a drop list to pick a data type from a list, then picking whether it’s an array, map, etc, from another drop list, then entering the parameter name in a text field. In C++, adding a parameter is as simple as typing it into the method’s declaration, for example,

      TArray<UPlayerCharacter*> & characters as a parameter is a reference to an array of pointers to UPlayerCharacter type.


      Implementing calculations

      Take this example calculation for determining a player’s maxHP stat, in C++:

      player.maxHP = player.vitality * 10 + player.level * 5;


      The equivalent in blueprints is:

      1 player node.

      3 “get” nodes from the player node, using three pins to get maxHP, vitality, and level variables as nodes.

      2 multiply nodes, each with two input pins.

      1 addition node with two inputs (each coming from the multiply nodes).

      1 set node to write set the result of the addition node to player.maxHP, which has an input pin using the maxHP variable as its target, and another input pin for the value the variable should have.


      8 nodes (1 player node, 2 multiply nodes, 1 add node, 1 set node, 1 get maxHP node, 1 get vitality node, 1 get level node) have to be added, and (3 get pins + 4 multiply input pins + 2 addition input pins + 1 set value pin + 1 set “target” pin) = 11 pin connections have to be made in order to do the same as that one simple line of code. The fastest part of that process would be quickly adding the multiply and addition nodes by pressing the “m” and “a” keys as shortcuts. Additionally, in blueprints, you have to take some care to line up the nodes in a way that physically makes sense to be readable. Measuring the amount of time it takes to write the line of C++ code, it took me about 7 seconds. That timing is not close to possible in blueprints. It’s certainly possible there are more efficient ways of implementing that calculation in blueprints, but the time it would take to determine the most node-and-pin minimalistic approach already makes it cost more than the C++ implementation, and the sheer amount of clicks and dragging (as well as going through the list repeatedly for which variable to get from a node) would guarantee it would always take more than the handful of seconds the C++ version takes.



      Blueprints and C++ each have very different strengths and weaknesses, to the point that they shouldn’t be seen as interchangeable tools. For clarity up front, I think all of our Unreal projects should use Blueprints, but exclusively just to their strengths and no more past that. Blueprint’s key strengths are that data-only blueprints provide the best way to get asset references and other data definitions into C++ in a maintainable way, and blueprints are fast to prototype with. Just in terms of early iteration times, Blueprints are faster in development than C++ because the recompile time is very fast, unlike C++’s very slow compilation. On the other hand, C++ is much easier to debug due to a rich set of debug and navigation tools and options. A C++ codebase is also easier for an experienced developer to learn and become accustomed to as a result of the navigational options, and faster to create new code within due to not having to mess with a bunch of nodes and pins to write simple expressions. Further, static analysis tools enhance the process to make C++ code more stable and then maintain that stability at any scale, which objectively improves the quality of the product. However, this is not to say nothing should use Blueprints outside of prototyping. Data-only Blueprints are still the best way to get asset references from the editor into something you can access in C++. Extremely simple event driven logic, like that in most UI implementations, is also fine to do and leave in blueprints. This is also great, because UI is most iterated on by artists and designers - not developers - making blueprint a great choice for them to use.


      In terms of gameplay implementation and not data-only use cases, Blueprints are best used for early iteration and prototyping. For example, when experimenting with how a feature looks and behaves. When that feature gets the sign-off, it should be converted to C++ immediately so it can benefit from all the aforementioned benefits, because it will no longer benefit from the rapid iteration speed of blueprints. It is true that sometimes a feature will get revisited for iteration much later after it was signed off on - in which case, just iterate again in blueprints then move it back to C++ when it’s determined to be the required implementation. Again, only features that are very simple and not that important to gameplay should be left in Blueprint. Everything that is important (even if simple) and/or even slightly complicated, should be moved to C++.


      Side reference:

      Here’s a great video which gets into the strengths and weaknesses of blueprints. The presenter, Zak Parrish, is a senior of Developer Relations and support at Epic Games who works with development studios to improve their use of the engine. With his experience from assisting studios and working with the team at Epic Games, he has the authority to talk about what is and isn’t a good use for Blueprints. I agree entirely with what he states, and many of my opinions are the result of applying his advice in projects.


      Case Study: Device Compatibility & Google Play Settings

      Case Study: Device Compatibility & Google Play Settings

      Without question, my favorite thing about the gaming community is the camaraderie with colleagues. It’s no secret that game developers of every level are often the real superfans of other independent game studios. 


      A great deal of the gaming community lives and breathes with this type of thought-sharing, feedback, and help. Every week, we receive questions from new friends and old, ranging from shared opportunities and game design feedback to troubleshooting and technical issues. Taking the more common, and thematic questions, and reusing them as blogs feels like a natural step for us, and broadens the number of developers we can assist. 


      The mini-case study below helps with a very small, but recurring issue that first game studios and game developers sometimes run into issues with: device compatibility settings.


      It’s often the case with beginners who are managing a store upload for the first time to miss a few steps. One of the most common is by not correctly configuring the Device catalog.


      If you look at the example below, you’ll see 15K+ devices supported from a project one of our senior developers uploaded.



      Here, you’ll see a similar project in the same month, and same version of Unity:



      With just under 5K devices supported, only 30% of the comparable above, something is wrong.


      In this case, the Game App API level is set to 23+. This means that Android devices must have that level of update to ensure compatibility, download, and play the game app.



      If you look at the package configured by the senior dev, you’ll see the difference:



      Set the minimum API level to 19 within Unity Player Settings, and you are good to go. 



      This confusion often starts because the Google Play upload dashboard will say that it requires the most recent API level to be uploaded. You do not have to set the minimum API level to be the latest. 

      Juicy Fog in Unity: A Mini Case Study

      Juicy Fog in Unity: A Mini Case Study



      Usually, I achieve fog by layering a decent amount of some low opacity fog sprites which are somewhat randomly scaled and rotated. The move slowly in random directions, and slowly change in scale and opacity over time.

      You can change the feel of the fog by changing the fog sprite assets themselves to be softer or harder-edged (or more/less detail) and by tuning the balance between the opacity of the fog particles and quantity. The more opaque they are, the less you need (lower emission rate), and the more "chunky" the fog will appear as a result. Less opaque fogs particles and more of them results in a more even distribution of fogginess (more smooth, less chunky).


      Here's an example fog particle system made that way:



      That's using this asset:



      And here's a variant using a softer fog asset:



      That used this asset:



      Here are the particle system settings I used there. Chances are, many of the settings will need to be substantially changed to fit the use case, but it can give you an idea. It's important to set the max particle size to something huge like 999, otherwise, unity may automatically scale the particle size based upon how big they are on camera. The max particle size there is really the "maximum size of particle in screen space at runtime".






      If it's low like at 0.5, it means their maximum size when rendered on screen would be 0.5, regardless of size settings elsewhere in the system. Important optimization and implementation related detail:
      There are two ways you can add a fog system like this to an area.
      1. Make it simulate in world space, and make its object a child of the camera object which moves around
      2. Make each simulate in local space (allowing them to be off-screen culled, unlike world space simulation) and make them a child of the level object. You define the areas they cover using the 'Shape' section of the particle system and adjust the emission rate to account for the amount of area covered


      You can set the simulation space in the particle system's main section, by gravity.


      With option 1, the particles will not move relative to the camera as the camera moves due to being in world space simulation, but the particles will spawn relative to the camera's position, which means the fog is essentially generated as the camera moves around, and the particles made where they camera used to be naturally go away. This works well with slowly moving cameras, because a low fog emission rate can easily keep up with the camera's slow position changing.

      It is also good if you're fine with the whole visible area being subject to fog in the same way visually (e.g, there's no place you don't want fog to be).

      This approach saves you the need from having to manually place and tune fog particle systems for the entire area, while still being decently efficient since it's one system moving with the camera, emitting a small amount of particles. You want to go with option 2 if you want to carefully control where the fog is, for example, if you never want it to display on top of a particular area such as a building or body of water. In DTs view angle, it may give more of a sense of depth to actually not have building rooftops occluded by fog, because it gives the sense that the roof tops are above the fog which is low to the ground.

      The main downside for 2 is that you have to manually place the particle systems and tune them by hand appropriately based upon amount of area covered. This is not so much a problem if the amount of space you have to deal with is small.

      You want to go with option 2 if you want to carefully control where the fog is, for example, if you never want it to display ontop of a particular area such as a building or body of water. In DTs view angle, it may give more of a sense of depth to actually not have building rooftops occluded by fog, because it gives the sense that the roof tops are above the fog which is low to the ground.

      The main downside for 2 is that you have to manually place the particle systems and tune them by hand appropriately based upon amount of area covered. This is not so much a problem if the amount of space you have to deal with is small.

      Option 1 is good if you have a lot of content and little time to add fog to it, or you're fine with fog being everywhere on-screen.

      Option 2 is good if you want a lot of control over where the fog is and isn't, and is best if there's not that much content to treat this way. I think DT will look best with this option

      Twitch: How to stream Nintendo Switch

      Twitch: How to stream Nintendo Switch



      Got the vibe to stream the new Animal Crossing, or just about any other new Nintendo title? This is the guide that will teach you how to stream games from your Nintendo Switch!

      Although most of the latest generation of games consoles allow you to stream directly from an app on the console to Twitch, one of the more conventional methods of capturing game footage – whether for streaming or for video making purposes on YouTube – has been accomplished by using a capture card.

      Since the Nintendo Switch does not offer the ability to stream directly from the console, in order to share your gameplay you may need to invest in a capture card.





      Nintendo Switch Capture Cards

      You can find cheaper capture cards out there but these two are the gold standard of capture cards and are widely popular within the streaming community of Twitch as they operate on both Windows and Mac.


      Elgato Game Capture HD60


      Elgato Game Capture HD60 S





      Use the following steps to set up stuff, once you have invested in a capture card.

      How to use an Elgato HD60 / HD60 S
      capture card to stream
      your Nintendo Switch to Twitch



      1. Download the Elgato Game Capture software

      Either go to the Elgato website by yourself or click here to find the latest update for Windows of Game Capture.


      2. Dock your Nintendo Switch

      Since the capture card needs an HDMI port, in its base station you will have to dock your switch.


      3. Connect your capture card to your Nintendo Switch

      You have to plug your first HDMI cable into the docked Nintendo Switch HDMI-out port and plug the other end of the cable into the HDMI-in port on your capture card.


      4. Connect your capture card to your screen

      Now, go ahead and plug your second HDMI cable into the HDMI-out port on your capture card and connect the other end into the HDMI-in port of your TV/PC monitor.


      5. Connect your capture card to your PC

      Plug the USB into your computer and the other end into the capture card using the USB-C cable included with the Elgato capture card.


      6. Power up your Nintendo Switch, open Game Capture and OBS

      Set your OBS to window capture the gameplay once you've opened these, and you're ready to go live! It is worth double checking all your settings beforehand, as some of the defaults may not be suitable for setting up your stream to your specific needs.





      Having trouble with any of the Elgato capture products? For you to resolve them, they provided a ton of support pages to help you! Click here to check it out if you're struggling.




      Can you stream Nintendo Switch
      without a capture card?

      Nintendo Switch footage can be streamed without a capture card, but it does have other requirements of a comparable cost, in which case you are better off purchasing a capture card unless you already have the gear available.

      You can use the Xbox One to stream your gameplay to your Computer, which can then be window captured in OBS, according to reddit user u/kakysha. A link to his tutorial is here.





      There you have it! Your Nintendo Switch games can now be streamed to Twitch. If you are a console streamer, and this is your first streaming from a PC, you can be struggling to read your Twitch chat if you have only one computer screen. Have fun streaming your gameplays in your Nintendo Switch!



      Steam Controller Configuration

      Steam Controller Configuration



      How do I enable Steam Controller Configuration?

      1. Open the Steam application, and click the Steam in the menu tab.

      2. Once you've clicked Steam, select Settings.

      3. In the pop-up box, click Controller.

      4. Once you've clicked the Controller, select General Controller Settings below the Controller Configuration.

      5. Place a checkmark in the box for your controller type.

      6. In the upper right-hand corner, open Big Picture Mode by clicking the icon.

      7. Once it's open, click the Library button.

      8. Select Bite the Bullet.

      9. Select Manage Game.

      10. Click the Controller Configuration.

      11. Click the Browse Configs button.

      12. Select the available standard controls config in the Recommended section.

      13. Click the Apply Configuration button.




      How do I disable Steam Controller Configuration?

      1. At the upper right corner of Steam, click on the Big Picture Mode button.
        This will open Steam Big Picture Mode, in full screen.

      2. Click on the Library button.

      3. Select Bite the Bullet.

      4. In the left-hand column, click on the Manage Game button.

      5. Click the Controller Options button.

      6. Click the Steam Input Per-Game drop-down box.

      7. Select Forced Off.

      8. Launch Bite the Bullet to confirm that your controller is recognized.
        Note: If your input is still not being recognized, you may need to relaunch Bite the Bullet.