Jump to content
  • Advertisement
    1. Today
    2. ArcanaDragon

      New Hero Added 10-23-2019

      New hero added: Roar Click here to play Hero Land for free in your browser
    3. Graphic libraries usually provide methods to draw text on the screen. These handy methods are often quite slow to run because they recompute many parameters at each call. To save computational time, the flyweight pattern can be used to provide text parameters with low memory and cpu usage. Facade design As usual, I start by adding new methods to the GUI Facade. There are many possibilities, here is an example that allows the drawing of messages of any size and color (NB: I only show new methods, I assume that the ones from the previous posts are still there): The setColor() method sets the text color. It uses java.awt.Color to defines the colors. I could create my own Color class, but it won’t lead to significant changes, and java.awt.Color is always in the Java standard library; The setTextSize() method sets the text height in pixels; The getTextMetrics() method computes the bounding box of a text to print. It also uses a class from AWT, namely java.awt.Dimension; The drawText() method draws text at coordinates (x,y). It also clip the text if it is too large. The clipping rectangle is defined by (x,y) and (width,height). AWT Implementation Implementing this facade with AWT is easy for setColor(), getTextMetrics() and drawText(). This is only a wrapping of existing methods: @Override public void setColor(Color color) { if (graphics == null) return; graphics.setColor(color); } @Override public Dimension getTextMetrics(String text) { if (graphics == null) return new Dimension(0,0); FontMetrics fm = graphics.getFontMetrics(); int textWidth = fm.stringWidth(text); int textHeight = fm.getHeight(); return new Dimension(textWidth,textHeight); } @Override public void drawText(String text, int x, int y, int width, int height) { if (graphics == null) return; FontMetrics fm = graphics.getFontMetrics(); graphics.clipRect(x, y, width, height); graphics.drawString(text, x, y+fm.getAscent()); graphics.setClip(null); } For the setTextSize() method, there is no existing method in AWT. A solution is to search for the font that has the required text height in pixels: public void setTextSize(int size) { if (graphics == null) return; for (int i=2*size;i>=4;i--) { Font font = new Font("Arial",Font.PLAIN,i); graphics.setFont(font); FontMetrics fm = graphics.getFontMetrics(); if (fm.getHeight() < size) { break; } } } This method is time-consuming and can be called many times at each frame rendering. Multiplied by the number of frames per second (usually 60), this can lead to a lot of unuseful computations since most of these calls will return the same values! A first approach consists of manually caching the parameters (in this example the AWT font instance). This saves computation time but requires additional work for the user and the implementer of the facade. A more efficient approach is based on the Flyweight pattern. Flyweight Pattern The Flyweight pattern... Continue reading on https://learngameprog.com ...
    4. Lerp( a, b, t ) = value InvLerp( a, b, value ) = t lerp returns a blend between a and b, based on a fraction t inverse lerp returns a fraction t, based on a value between a and b Use case! 🔊 Say you want to control audio source volume based on distance at 10 meters, you want volume 1 at 20 meters, you want volume 0 Then the volume is then given by volume = InvLerp( 20, 10, distance ) If you've ever used photoshop's levels tool, then you've used both lerp and inverse lerp! 🎨 The input values use inverse lerp, the output values use lerp! When used with images, inverse lerp can be used to increase value contrast! for example, here's a selfie before and after an inverse lerp💖 Also, note that some Lerp/InvLerp functions also extrapolate (such as in shaders), while others clamp the values within your given range (such as Unity's Mathf.Lerp/InverseLerp functions) Make sure you clamp unless you want to extrapolate 📈 Here's an interesting use case! An inv lerp where a and b are colors and the value parameter is the depth of this water, you can achieve hue-shifting for a color elimination effect by depth🌊 water.mp4 Addendum - another useful function is Remap! Remap takes a value within a given input range into a given output range, which is basically a combined inverse lerp and lerp! Here's the code for all three! (Also, none of these are clamped - they can all extrapolate) Enjoyed this quick lesson? Check out Freya's work via the following social platforms: 💖 Patreon ❱ https://patreon.com/acegikmo 📺 Twitch ❱ https://twitch.tv/acegikmo 🎥 YouTube ❱ https://youtube.com/c/acegikmo 🐦 Twitter ❱ https://twitter.com/FreyaHolmer 💬 Discord ❱ https://discord.gg/v5VWuga 🌸 Instagram ❱ https://instagram.com/freya_holmer Want to read more about Lerp? Freya posted a thread here: Adapted from the original Twitter thread with kind permission of the original author. Further reading on GameDev.net: A Brief Introduction to Lerp, by Matt DesLauriers
    5. frgauthi

      Space Race

      Space Race is the first game I have made using the unity engine. It is an endless runner type game based in space where you dodge asteroids at an ever increasing speed while trying to maintain your fuel supply by picking up fuel orbs. The point of the game is to get the highest score possible which is reflected on the local leaderboard. It should be noted that I did not create the art or music for this game. all art and music used was freely available. below is a list of credits for the art and sounds I used: Art SpaceShip - "E 45 Aircraft" - by 3dhaupt on free3d.com Asteroid - Asteroid - by printable_models on free3d.com Skybox - Space Skyboxes - StumpyStrust on opengameart.com Music / Sound https://opengameart.org/users/matthew-pablo - http://www.matthewpablo.com - level 3 and 4 music https://opengameart.org/users/haeldb Brandon Morris - menu music Deceased Superior Technician (DST) - railjet - level 2 music http://www.nosoapradio.us https://opengameart.org/users/manofsteel sPACE - level 1 music https://opengameart.org/users/dokashiteru - gas pickup sound http://wrathgames.com/blog - explosion sound David McKee (ViRiX) soundcloud.com/virix - Out of Fuel sound https://opengameart.org/users/wobbleboxx - wobbleboxx.com - Light power down sound
    6. Yesterday
    7. Timeline Games

      Major Bug Fixes

      Hi everyone, I just want to thank everyone who played the Slime Wars on release, and my apologizes for the various bugs that were found in the initial release, namely starting the player off on the wrong level, namely either the second level in region 3 or the final level in region 2. All of these bugs have been fixed and I hope you all are able to enjoy more of the game https://gamejolt.com/games/Slime_Wars/209402 Have a good day, Buttercreeper6
    8. Timeline Games

      Slime Wars

      Slime Wars is a retro 2D platformer that is currently in development. You fight through 6 regions. Each region will have small changes on the enemies you fight, like higher damage or you can't see the enemy until you get within a reasonable distance. Each region a have 5 levels and 1 "Boss Level", which is a small level before a boss. The game will release on October 21,2019. If your really excited to try the game out I have a, if buggy, fun and expansive beta that can be played. Also: the game is free, so why not try it? Story: On the far off planet of Mundan their lives a once peaceful race of slime at came in a variety of colors. The one to rule this world was the Rainbow Tribe. They built their civilization on the principle of unity and peace, and so it was. Until a fateful day where the different tribes began to release that the planet was running out of resources, a council of the tribes was called to see what to do next. Most of the tribes, headed by the Rainbow Tribe, wanted to take their warships and take over new planets for their resources. Others, like the Green Tribe, wanted to try and salvage Mundan and grow from there. This dispute cause what was forever known as the Slime Wars. To keep the loyalty of the tribes aligned to them, the Rainbow Tribe appointed generals the where loyal to them only. They conquered all the tribes that dared think differently, all but the Green Tribe. The fighting though, made the planet unsalvageable, making finding another planet the only option. You, a member of the green tribe, must take over the "Royal" and free the other tribes and convince them to follow your plans of finding a fresh planet, one with no sentient life. Will you save the galaxy? Or will countless planets be forever covered in slime?
    9. M0N0_M4N

      Code Name GunsBritanica

      ⦁ The game will be kinda like Monster Hunter 4 as a 90s FPS. ⦁ For now its just a prototype with placeholder art and sound. ⦁ Movement controls are typical FPS, mouse and keyboard inputs (I just added sprint). ⦁ The placeholder tutorial is kinda like Dark Souls for now (its short I promise;)).
    10. Bolt-Action Gaming

      This Week in GameGuru - 10/21/2019

      GameGuru News Some of the secret squirrel sleuths found this gem buried in GitHub - make of it what you will: https://github.com/TheGameCreators/GameGuruRepo/pull/631/commits/c570fedd8cd8ccac8e5652f8bfd4b293a775d458 What's Good in The Store There's a lot of good one off products this week: Corrosion's Survival Scripts are in a pack. https://www.tgcstore.net/pack/11155 Fredgames77 made some highly detailed zombie garden gnomes. https://www.tgcstore.net/pack/11154 Third Party Tools and Tutorials <This space for rent> Sorry guys, nothing new here :( Random Acts of Creativity (WIPs) Galaxy Hauler (By Honkeyboy) had a video put up that is fairly enticing: https://www.youtube.com/watch?v=4-GaQHaQZ4A Zelick's project "Neir" had some updates here: https://forum.game-guru.com/thread/220415?page=1#msg2622300 Naelurec by Old Flak has put up some more great screenshots: I love seeing a project with custom modelling. This kind of thing is what this community needs - more homebrew stuff with consistent art direction and quality design. It should really stand out once it's completed. Robert Hindle (Bod) and AmenMoses's latest work on a flyable spitfire looks great, as one could reasonably expect! https://vimeo.com/367610915 Free Stuff If you didn't get Granada's excellent free shotgun last week, get it this week! https://forum.game-guru.com/thread/221213 https://www.tgcstore.net/product/33551 AlexGCC made a free 'Russian Sign'! In My Own WorksLife is still hectic with the basement remodel, work issues, new baby, etc. However I've been slowly nicking away at getting minor things taken care of as well as outstanding issues. I've recently begun making new skies for space settings again - but none of the newest batch has been up to par. I'll probably release the failures as freebies once again. Lastly, my Cyberpunk Noir weapons kit is FINALLY fixed and on the store. If you are a book owner, ask me for a free key so you can get a copy of these for free. View the full article
    11. [The original post with its formatting can be found at the Unity UI Profiling entry] You spend an infinite amount of time optimizing your Unity UI. But, all it takes to really screw up performance is a sneaky modification on a tiny attribute of an almost invisible Canvas UI element. And when that happens, not even Unity UI Profiling will save you from dropping frames. Are you ready for the road ahead? This is what happened in my last project... I worked hard to optimize the several UI panels of our port to Oculus Quest. This was mostly about reducing the overdraw level to an acceptable amount to make sure the GPU would be all comfy with the real 3D rendering. So I worked on Unity UI Optimization for at least a month and made pretty damn good progress. At some point, it was so well optimized that the GPU timings were barely moved by the UI. The opaque UI shading techniques I applied compensated most of the overdraw caused by UI Layering (elements drawn on top of other elements). There I was, with a super optimized hybrid UI system that effectively occluded the 3D elements drawn behind it. It became very easy to discard the rendering of these occluded fragments. However, I was far away from being done... When I hooked the Unity UI Profiler, one thing caught my attention. I saw an overwhelmed CPU taking over 1 ms per frame on UI rendering. That's a hell lot of time for a platform that gives you a budget of 13 ms for the whole game execution: physics, logic, 3D rendering, input, VR, networking are all in the same bucket. And I've seen cases where UI kills CPU performance even more. Unity UI: Expensive Build Batches And that is the thing: UI can be optimized to be GPU-friendly, but that doesn't directly translate into being CPU-performing. In fact, CPU and GPU have very different tasks to accomplish in Unity UI Rendering. No wonder, I suggest you approach CPU and GPU optimization very differently, as seen in my previous blog post about Unity UI Optimization. Doing more of Unity UI Profiling showed me the obvious problem: the UI was constantly being re-created every single frame, i.e. there was a Canvas Rebuild happening every frame. A constant hit of 1 ms on the CPU... ouch. But why would Unity do this to me? I thought Unity cached the UI Canvases... Actually yes, that is correct. Unity effectively caches the canvases to make sure they are built just once. The problem arises, though, when you change the properties of any of the UI elements of the canvas, such as a color, a position and so on. That means, all animations we love, such as button hover effects, are killing your performance and you might not know it. When UI property changes happen, Unity does the famous Canvas Rebuild that will crush your game's performance. A Unity UI Canvas Rebuild makes Unity iterate over all UI elements of that Canvas to generate an optimized list of draw calls (a set of vertices, colors, materials, etc.). And Canvas Rebuilds take longer than a Seat Panda doing a 0-60 mph test. That said, once you've acknowledged you suffered from constant UI Canvas Rebuilds, the natural question to make is... Why am I suffering the Canvas Rebuilds and what can I do about them? ​Answering that innocent question led me to spending 5+ hours researching this topic and empowering the Unity UI Profiler. Let's see how. Quick Navigation (they all redirect to the original blog page) 1. Unity UI Profiling: All Good, until... 2. Unity UI Profiling: A wild Canvas Rebuild appears! 3. Finding the Saboteur: a politically incorrect brute-force approach 4. Bonus: Augmenting the Unity Profiler for UI Optimization 1. Unity UI Profiling: All Good, until... Let's say we have a weirdo of a UI in front of us. That UI is barely doing anything but sitting there, being annoying to the player who just want to see something through it. As a collection of 350+ images using a Grid Layout Group, it (miserably) looks like this: Unity UI Profiling Example And that's fine, even if it contains 350+ images. They will normally be rendered in just two draw calls, as there are two unique images that are not atlased in a sprite atlas. Effectively, I can see in the profiler there's almost no overhead on the CPU side. Most of the time we're under 0.01ms, which is pretty damn good. Unity UI Profiling: Sneaky Spike (...Most of the time) ​Wait, what was that CPU spike at the end of the graph? 2. Unity UI Profiling: A wild Canvas Rebuild appears! What has just happened there at the end of the Unity Profile? The Unity UI CPU cost has more than doubled in just a second, how weird. I want to play a game Find the two differences in the samples below (you may want to click on them for zooming in). Unity UI Profiling: Cheap Canvas Unity UI Profiling: Canvas Rebuild I'll give you five seconds to find it out. 5, 4... Ok here's a hint to make it easier: Unity UI Profiling: Canvas Rebuild Overhead Yikes! PostLateUpdate.UpdateRectTransform and UGUI.Rendering.UpdateBatches really wanted to take all the highlight in today's show. What do these regions do? The first, UpdateRectTransform, implies that a transform of a specific object has changed, and therefore Unity has to run some expensive logic to keep visuals coherent. We don't know whether it was a position, a rotation, a scale or any other of the RectTransform properties. Heck, we don't even know if it was just one attribute or all of them. Was it one object, or multiple? In any case, which ones? This is the problem: we do not know. The second cost, UpdateBatches, relates to the fact that the whole Canvas geometry has to be rebuilt. This process is famously known as a Canvas Rebuild. A canvas rebuild implies that Unity goes through all the Canvas hierarchy to generate a list of draw calls, so to speak. The vertices, indices, colors, uv's of all elements are computed and then a batching pass is done to we merge as many draw calls as possible to reduce the CPU overhead of issuing them to the graphics driver. Now we know what's going on, kind of. We're on the right track. But how do we go about avoiding these canvas rebuilds? What is causing them? We just need to find out more specific information... Summary An attribute change in a UI element will mark the element itself as dirty A UI element can be totally dirty, but can also be partially dirty: vertices-dirty, layout-dirty, material-dirty. Partial dirty states are cheaper to recover from Unity will rebuild canvases entirely, as soon as any of its elements are marked as dirty Canvas rebuilds are expensive on the CPU, avoiding them is the key 3. Finding the Saboteur: a politically incorrect brute-force approach We are still to give an answer to the following question: Who's triggering that sucky Unity UI Canvas Rebuild? It turns out, there's no fast way of finding that out, especially if your canvas hierarchy is immense. But, to start out, I'll show you the brute force approach for finding the source of UI Canvas Rebuilds. 1. Keep the Unity UI Profiler recording Filter the metrics so you can focus on what is important: Rendering, Scripts, and UI. Keep an eye on the baseline to have a visual cue of your current baseline cost, which should include the expensive Canvas Rebuilds. 2. Deactivate UI Game Objects and compare Select a group of game objects and deactivate it. Compare the performance baseline. If the baseline didn't improve much, continue deactivating game objects till you see a significant improvement. 3. Find out who is modifying its properties Now you managed to isolate which object is triggering your Canvas Rebuilds. But, who's actually causing those? Is it a script scaling it? Or maybe an animation changing its position? It helps to do a right-click on the RectTransform and press "Find References in Scene" Once you know who's causing the UI canvas rebuilds, do something about it, such as disabling animations or transforms. Ruben, how am I supposed to follow this approach in a huge UI hierarchy? Don't give me crap I told you it was going to be neither fast nor fun, but your players asked for it. That's the thing. Having a huge hierarchy in place is not ideal in the first place. Exactly those massive, deep hierarchies will make your Canvas Rebuilds incredibly expensive on the CPU. But big and nested UI hierarchies can (and will) happen, so expect canvas rebuilds to hit you where it hurts the most: your players' game-play experience. While the brute force approach helps finding the source of canvas rebuilds, this does not scale in the long-run. Becoming more professional about optimizing UI is what got me into creating a tool that would give me all the answers I needed to match my players' expectations... Canvas Rebuild Profiling 4. Bonus: Augmenting the Unity Profiler for UI Optimization By now, hopefully, I stressed enough how frequent and impactful UI Canvas Rebuilds can be. These troll canvas rebuilds that infested my game stole 10% of my entire CPU budget! As we saw, there is a slow brute-force approach for finding the source of a canvas rebuild. Then, I hope you'll be able to do something about it, based on the strategies I posted on my Unity UI Optimization post (visit it, it's free, I promise!). But such as error-prone approach is a process a real guru would never settle for. You can literally spend days trying to avoid canvas rebuilds, but the moment you expect it the least, they'll come back just to disappear as soon as you attach the Unity UI Profiler. This becomes crucial if you're doing VR development. You don't want canvas rebuilds in your world-space UI. Like not at all. If you don't get rid of these, you're very much likely to convert your players into patients. I get it, I will get rid of the canvas rebuilds. But the Unity Profiler won't tell me much about those! What advice can you give me? I'm glad you asked. It turns out we can convince the Unity Profiler to give us useful information about who's messing with the performance of our UI. You and I can augment the functionality of the Unity UI Profiler. We do so by altering the Unity UI source code that is publicly available. Once you have the source code, you'll want to find the code functions where the Canvas Rebuilds take place. Then, all we need is some BeginSample and EndSample Profiler API magic. If you're running Unity 2019.1 or earlier, the Unity UI source code is available for free in their Bitbucket repository. You can follow their guide there to download, install and modify it. My suggestion? Use a newer Unity version, at least 2019.2.0. New versions of Unity include the UI source code by default, as the UI system is now part of the package manager. That's the hassle-free way of doing this. Here's a list of code regions I found during my investigations where you could add the Profiling API calls: CanvasUpdateRegistry.cs: function PerformUpdate Graphic.cs: function SetAllDirty Graphic.cs: other functions such as SetVerticesDirty, SetMaterialDirty, etc.. Unity UI: Profiling Source Code Useful? Yes. Artist/Designer-friendly? No. That's why I wrote a small open-source Unity Extension to enhance the Unity Profiler for you. The free tool will allow you to quickly switch over profiling modes to make sure the performance of your game is on top. The best part of the Unity Profiler enhancer? It just works outside of the editor, effectively replacing all the aspirins you've been taking while profiling your UI in Android and other platforms. Here it is, all its power under your control with two simple buttons: Buff my Unity Profiler Nerf my Unity Profiler. Grab it now here:
    12. MarkK.

      craft_01_texturePass

      @Rutin What a wild month. I knew I had an unattended comment in the queue. I've been at it pretty hard, Finally settled on some realistic moves, which are still a bit ambitious for one guy. I'm torn between Unity and home brew which is winning over here. 'Lov the Unity, fantastic tool. For me, home brew scratches that spot just right, so it's hard to resist. With that said, I'm fairly happy with a new raw ogl3 framework I'm putting together. The focus is on getting up and running quickly with the common elements (menu, game state, timing, display management, input, shader management, logging....) so I can get serious with the Challenge Group. I was leaning toward an upcoming code review and/or community source share. (deciding if it's worth it. been wanting to put something in that git thing for quite a few years now.)
    13. I will make a simple prototype in OpenGL v1.1. Later I will replace v1.1 to v3.0. I will write interesting effects using GLSL. I will think how to add Unit Testing using NUnit and NSubstitute (mock-objects) My source code will be here (it draws a one triangle for a while): https://github.com/8Observer8/TicTacToe_OpenTkOpenGL11CSharp I create a public board on Trello: https://trello.com/c/dXgd3zxg/1-tictactoeopentkopengl11csharp I completed only two steps. Trello and GitHub are very useful tools for game development.
    14. B.Black

      2D Winter Asset Pack

      Winter themed 2D art pack. Including animated characters (Spine animation + classic Sprite animation). Also, some fancy themed particle systems are inside. Pack contains: •140 sprites + PSD files • Fully animated character • 3 backgrounds • 4 light sprites • Winter themed tiles • 6 Particle systems • Demo Scene
    15. Overloaded

      Pixelorama v0.3 is out!

      Some things never change. Some of them is Pixelorama’s UI. I was having some bad days lately, but I managed to work on Pixelorama… when I could. I was hoping this release would come out sooner, but eh, here we are. So, changelog: New animation timeline features: Ping-pong loop, and… onion skinning! You can choose how many steps in the past and future you want to look, and you can toggle Blue/Red mode! There is also an option to import new frames without deleting the others. New custom project file, .pxo! If you save your art as .pxo, all the hot data you need like layers, frames and color pallets get saved. It’s a smart saving system, like its father (me). New rectangle selection tool. Make selection, drag selection, hold Shift while dragging to drag the selection’s contents, copy/paste selection, you can only draw INSIDE selection, selection persists between layers and frames, use selection to select (duh) pixels from canvas and save them as… …CUSTOM BRUSHES. The gentle laborer shall no longer be forced to use the pixel brush! You can resize ’em, re-color ’em, map ’em to your mouse buttons. And yes, custom brushes get saved in .pxo files. Told you they’re smart. Do you ever make tiles and want to see if they are seamless? Pixelorama’s got you covered with its new Tile Mode! Do you ever wish to see your art from different zoom levels at the same time? Pixelorama’s got you covered with its new Split Screen View! Do you ever wish to crop your sprites? Pixelorama can now crop sprites. Re-organized the menus and added an “About” window where you can find more info about Pixelorama. And more importantly, donate. Tile mode and split screen view in action. Whoosh! Showcase video time? Showcase video time! If you want to ease my pain, you can show your support by donating on PayPal and Ko-Fi. Or you can just send me love. Anything is appreciated. Thanks for your time and as always, happy painting! Pixelorama is available on GitHub and Itch.io! View the full article
    16. Devlog #4- Saving Space October 22nd, 2019 Connect with us on Social Media: Facebook: www.facebook.com/TumultuousProductions Twitter: https://twitter.com/TumultuousGame Join our Discord Server: Join the Yami Discord Want to Join the Project? Fill out our google forms Online Application For more about the Studio : About Us Tumultuous Productions Check out our website for Yami! https://tumultuousproductions.site/index2.html For more about Yami: Our Game: Yami Weekly Updates Week 4: Discover the world of Raum The game of Yami takes place within the planet Raum, known for its harsh climates and immense gravity upon its surface. Raum has four moons, and orbits two suns at the center of its solar system. Below is a brief description of each of the heavenly bodies players will spot in the sky during their gameplay, as well as concept art produced by Tumultuous Productions’ talented artists! Moons: Shattered Twins: Two smaller moons within the Raum sky, encircle one another in their own gravitational pull. Debris and rocky dust swirl around both moons as they rotate around one another. Some of the smaller dust and debris have begun to form a faint ring around the moons. The Eye of Rage: The surface of this larger moon is covered completely with oxidized iron, giving it a reddened appearance to the inhabitants of Raum. This moon has an asynchronous cycle with the Eye of Mourning, with one day a year the two ‘Eyes are Open’ and one day a year when the two ‘Eyes are Closed.’ These two days were considered sacred to the ancients, and signified important events. When the Eye of Rage is full in the sky, it is considered an omen for danger or violence. The Eye of Mourning: The surface of this moon is covered with vast oceans and two polar ice caps, giving it an impression of a teary eye in the sky. This moon has an asynchronous cycle with the Eye of Rage, as aforementioned. When this moon is full in the night sky, it is considered an omen for great sadness or loss. Suns: The two suns of this planet are part of a binary star system, where the two orbit around one another due to their intense gravitational pull. There is a ‘thread’ between the two in the sky, as one star is slowly absorbing energy from the other. Dorhen: The larger of the two suns, a Class O Blue Giant Star, giving it a large and blue appearance in the day sky. Ettas: The smaller of the two suns, a White Dwarf star, which has a luminous white light in the sky, but provides little heat to the surface of Raum. (Concept art of the celestial bodies within the world of Yami) Saving and Loading your game in Yami Within the game of Yami, there will be various locations where the player will be able to save their game. When returning to your journey, you will be able to load your game from multiple save slots. Below are our concept designs for loading screens and save files. (Save/Load Concept) Weekly Member Spotlight: Seik Lucid For this week, I asked one of our hard-working and incredibly talented coders, ‘SeikLuceid’, a few questions about how they got into coding, and what their creative process looks like. Q: What is the process for coding a video game? A: “I could go on for days on this subject, game engines, and psuedo-code, both of which are good tips: but what it all comes down to? Breaking your goals up into their smallest parts, smaller than you might be able to consider them as even a 'part' of the goal if possible, then figuring out how to make those pieces work towards your end goal. Psuedo-code is a great tool, Adaptability is important, but functionality is your main goal, especially starting out. If it works, it can be refined. Personally, I use Pseudocode, then I use in-game prompts or debug lines, then I fill them in one at a time, piece by piece, until I get the functionality I need. Afterwards: I begin worrying about cleaning it up, optimizing it, and refactoring it into adaptable, and readable code. Q: What made you interested in making a video game? A: “As with most game enthusiasts, playing games as a child. I spent a lot of time playing games, indulging in the stories and enthusiasm that surrounded games. Unlike the modern days, games were a secret hobby you did by yourself, when no one was around when I was young. Games didn't even really have a multiplayer. Arcades were still a thing, if that helps to place it for you. By the time it became socially acceptable to play games, was about the time I got my first computer, and really started exploring the wide world of gaming. Sharing stories with a vast audience, and entertaining children who perhaps spend much of their time alone, within their own head, as I did. That's ultimately what my game development is fueled by.” Q: What do you like best about the Yami team? A: “The Yami team really stands out to me solely based upon the fact that there is such a constant flow of communication. I've worked on a few teams before, even been part of the problem in them, in which you inevitably had to talk through a chain sequence of people to get clarification or instruction. Personally, I'm glad to be a part of a decent environment, where I feel as if forward progress is being made. You'd think with more people that would be evident, but it's really not.” Q: Tell us briefly about yourself! A: “I'm really not an about me type of person, honestly, ask anyone who knows me, they learned 'about me' by being around me for years, and still learn the most basic things sometimes years down the road. In terms of game development though, I've worked on five separate projects, have two ongoing, participated in one game jam, am participating in a second currently, and have been pursuing this field off and on for years. I have a wall of sticky notes with game design notes on them from my many projects, I can't throw them away because I'm never sure if they'll come up again later. I have a whiteboard, but I never erase it, so it's basically one big sticky note now itself. I love RPGs, I have fancied myself a writer, to about the same degree of success as a game developer, which means none so far! I am horrible at art, practicing, but it's nigh fruitless thus far, hopefully that changes over time! That's about all there is to know about me, at least that I am able to think of!” Q: What is something about coding that most people don’t know or understand? A: “Programming is not a difficult skill. It 'seems' difficult because of the syntax, because of higher level programmers min-maxing their code to be as efficient or as minimal as possible, but code can be as large as it takes to accomplish what you need. The act of programming is not hard, but it is a skill that you gradually improve at. I'm still a novice, my code is probably ugly and unclear as it gets, when it's just for me especially, but it'll function as I intended. There are certainly better ways to accomplish what I have, there are likely more 'adaptable' ways to do it as well, but it's functional. That's where programming begins. Once you can accomplish everything you can think to do in code, then you can expand upon those ideas, try fitting them in similar but not the same situations, update the code to see how you can morph it to work differently, but without destroying how it worked before. Clean it up, make it easy to read, make it easy to follow along with. Many bugs will make you just read through your code, following the logical path, trying to figure out where the issue could be: So if you are having trouble doing that, your code could use some maintenance!” ~Stay tuned for our next DevLog issue where we learn about another NPC in Yami as well as concept art of our game’s first boss! We will also be posting updates regarding our game’s website, which is coming soon to the public!~ Remember to: Connect with us on Social Media: Facebook: www.facebook.com/TumultuousProductions Twitter: https://twitter.com/TumultuousGame Join our Discord Server: Join the Yami Discord Want to Join the Project? Fill out our google forms Online Application For more about the Studio : About Us Tumultuous Productions Check out our website for Yami! https://tumultuousproductions.site/index2.html For more about Yami: Our Game: Yami
    17. Last week
    18. ricvalerio

      AOE Spells

      While the spell system has been in the game for a long time, it has been mostly in a very primitive form. The introduction of factions allowed me to clearly define who is a friend and who is a foe. That had an immediate impact in the spells, because now I can make rules of who can be the target of the spells, so I can now declare that it can affect "allies", "enemies", or both. From here, I continued with the momentum of working on the spells, and added spells wit an area of effect. To do that, I had to split the task into a few different subtasks, and the most interesting part was in fact making the system that applies the effect on the targets that step into the area of effect. It turned out to be quite simple, but nevertheless a very effective way to create an area of effect. As for the clients, they only receive enough information to show a visual representation. Now I want to add more effect types, like for example slowing, freezing, disorienting, stun, etc. As usual, I will be doing a video on this development and post it on my devlog on YouTube, at https://www.youtube.com/channel/UCyOt8sPTqNxRseUzpzUEQQg
    19. ricvalerio

      Online RPG

      Follow me on the journey of creating an MMORPG. Along the way, I will share my experiences, implementation choices, techniques, decisions, tips and tricks, until the release.
    20. emanubit

      PulseHazard

    21. LordArt

      Crazy Synth Solos!

      Ever since I played my bother's keytar, I've always wanted to write an awesome synth solo. I am very happy that I got the chance to write one for the Rank: Warmaster Soundtrack. The only problem was I'm not very good at soloing in C# Phrygian, so I transposed my keyboard so that I could play in E Phrygian instead (a much easier scale to play for a non-primary pianist like me). Here is a small preview! Full story »Original post blogged on Rank: Warmaster Dev Blog. View the full article
    22. Mindshell_Team

      Deadly Dread

      Deadly Dread is a survival horror experience. A corrupting entity has infested a space station, trapping you in, and turning the crew and the environment against you. Will you be able to escape before your mind surrenders to madness, or a creepy monster kills you while cowering in a corner? Death will come for you, unstoppable and unpredictable. Any new attempt to survive will require all of your skills to success, as every time the game layout, foes, objects and weapons you'll need will be different, making each playthrough unique. First person gameplay, with different approaches to survive, either stealth or shooting. Rogue-lite, where permadeath, which implies a new run after being killed, is not impairing fun. Each playthrough relies on a different map layout, including different enemies, tasks, objects type and location. Smart AI. During a playthrough,enemies will learn from your actions,and will become better at spotting you, focusing on their senses (sight, hearing, even the perception of your fear) Dynamic environment. You can interact with the world around you on your favor, like taking cover in a shelter, throw an object to mislead an enemy, or breaking a light to cower in the shadows. RUN.HIDE.FIGHT...STAY ALIVE! SURVIVE Wounds are not the only things to pay attention. The air itself is toxic, so you shall plan your moves to save your oxygen reserve OPPORTUNITIES Use distractions or find hideouts to avoid enemies when your combat resources are on short. ENVIRONMENT Each playthrough is unique. Experience different game threats every time, find your own way to survive. ESCAPE Escaping from Endeavor won't be just as easy as running to the end of a series of rooms. The space station has been heavily damaged, so you'll need to complete some tasks before being able to leave. 3-DEADLY MONSTERS There are currently three special enemies that could pursue you during each playthrough, each one with its own behavior and strategy to find you. HAZARDS The space station is a dangerous environment that can (it will) also threat you, changing during gameplay, blocking your escape path, breaking down and damaging you, sometimes forcing you to find an alternative way. GAME FREEZE While being a challenging game, Deadly Dread allows you to make a snapshot of your gameplay, "freezing" the current status and letting you recovering from there, unless you've died. PERMADEATH Death doesn't forgive. The playthrough in progress is over and cannot be recovered.
    23. Hi all! To celebrate the upcoming release of my third book on shaders (Nov 14th) I'm giving away a 1-year Unity Plus license. You can join the giveaway here: https://www.2dshaders.com/unity-giveaway/ enjoy!
    24. ProjectTaival

      Dev Diary #042 - SitRep 02

      Hello and welcome to this weeks Dev Diary! For the last two weeks, I have been spending time further examining the effects of re-scaling the heightmaps and searching for the optimal size I should aim at first. Since there is no further findings to go into detail for, I can only announce that for my purposes, the 40k heighmap for the 4km2 -area is more than enough, giving an accuracy of 10cm between data-points (or vertices, when talking about 3D models). I also found out, how long it takes to upscale pictures to 400k size with my current PC specs and that was frustrating to say the least, with over 2 hours waiting time. Conclusion; aiming for 1cm map accuracy was frankly an overkill, to say the least. One problem still remains, as to how can I combine the land areas effectively in the game engine, without having to join them together manually, one by one? That is one thing, that I'm trying to find out for this week. Here is a filler image from 2 weeks ago, a 5k x 5k portion from the 40k heightmap, with a 100:10:1 subdivide. Thank you for tuning in, and I'll see you on the next one! You can check out every possible mid week announcements about the project on these official channels; • YouTube • Facebook • Twitter • Discord • Reddit • Pinterest • SoundCloud • LinkedIn •
    25. Timeline Games

      Full Release Today!

      Hi everyone, Today marks the full release of Slime Wars, after 5 long years of development. It is avalible for Windows, Mac and Linux and is free ... so why not try it? Have a wonderful day, Buttercreeper6
    26. Welcome to our twenty-seventh blog post! In this one, we wanted to begin to delve into a specific topic of combat, which are enemy armies. Combat overall in this game can get fairly overwhelming, and difficult to keep track of. But not impossible. One of the ways we wish to emphasize that plausibility revolves around basic combat. We can begin to push what is possible and what isn’t be simply placing more and more foes to be fought. This game is highly based around its combat, after all, so putting that at the forefront is our core design choice. It becomes something that isn’t so simple- its not a boss fight, nor is it statically generated. It is completely random. You’re forced to fluidly follow the world and react to things as they come at you. Which we believe pushes the challenge and design more. As we get even further along, we imagine you’ll be tasked with facing a great many of foes. And, given your training at the earlier stages, you should be amply equipped in dealing with it. It all comes back to our core design we wish for the game- your army clashing against an opponent’s army. Results can go a variety of ways- you can have your entire force wiped out from under you, or perhaps you escape with only a few injures. Or only a single warrior dies. Or you escape completely unscathed, and able to press onward. Maybe a difficult foe blocks your way, so you look for an alternative route. These are things you’ll need to deal with as you improve your control and understanding of the warriors you command. Your soldiers will take damage, consume mana, be positioned incorrectly, die, so on and so forth, and as you fight against these multitudes of foes, you’ll begin to see the importance of dividing your focus so all warriors get the attention they need, evenly. Equally as importantly, you’ll learn to fight with the various disadvantages outlined above, and hone your skills further. Lastly, these designs are not completely unfair. Your progress is retained as you traverse. So, even while you may be faced with a very difficult task, just know the reward is said progress that you will not be forced to repeat. --- Thank you for viewing our post! Support and interest for the project has been rapidly growing ever since we began posting here, and we're incredibly grateful for all the wonderful feedback so far! We hope this project interests you as much as we love developing for it, and please look forward to more updates coming in the very near future! If you’re brand new, consider checking out our trailer and overall description of the game here.
    27. Yyanthire Studio

      Moonrise

      Moonrise is an open-world real-time strategy game. Explore a vast land rich with demonic creatures. Establish a base, and venture forth to eliminate the powerful beings that have overtaken it. As you venture, you will come across great artifacts to bolster your warriors, and great resources to enhance your fortifications. In this land, the will of the leaders is absolute. One false step, and all of your creation will fall under. Intricate care is necessary for your warriors to survive to the next battle. The creatures of this world are powerful- are you able to stand up to them? Explore- Explore a world rich with conflict, where there’s always a new challenge to endure. And reap the rewards of such ventures. The lands are wide and vast, and the journey will be perilous. Do not get lost- always know your way back home. Gather Resources- All of this world has something to offer- whether it be the nature around, or from the souls of defeated enemies. Use those resources to build your base and your army, and wage war against the vast enemies of this land. As you explore more, you will find powerful foes- slay them, and grow your warriors even stronger with the mystical objects they have to offer. Build an Army- Build up your home base not only to act as a fortitude against the enemy onslaught, but also to enact key, pivotal research points. Whether you wish to give your warriors greater health and mana, or advance them down further into their class, building your base is the only true way to get the advancements necessary for engaging more powerful foes. Research- Whether you choose to spend your hard-earned, limited resources on empowering all warriors, or just a select few, researching various upgrades for your army will allow you to further craft and define the complexities of your army to a solid degree. And those who wish to venture even further will find themselves that much more fruitfully rewarded. Wage War- At the heart of Moonrise is waging war against the multitudes of foes of the land. Foes will wildly vary in volatility, and it is up to you to command your warriors in such a way to slay them without becoming slain yourself. Never stop moving- movement is key to avoiding attacks from enemies while still striking at them yourself. You can avoid enemy attacks by simply moving out of the way before the attack lands. By using clever tactics, you can survive many adversaries and come out unscathed and ready for the next fight. Invoke powerful spells to your advantage- there are many different beings at your disposal. Making use of their talents is the only way to come out successful, and to defeat even the strongest of enemies. In Moonrise, there are dozens of spells, each with wildly different uses, able to be enacted and used as how you see fit to command. State of the Game- This project is very deep into its development cycle now. There is a considerable amount of work that has been done to make the game playable, and as the game sits, it is currently in an Alpha state. There is still more work to be done- we have yet to finalize key features like a saving system, and have yet to get further into our desired open world elements. In addition, while we do have a lot of art done for the project, there is still some remaining, and we have a lot of animations we still need to create. Music and sound effects are the same story. But, as of right now, the game definitely plays like how we envisioned it- lots of tactical complexion backed up with a lot of intricate micro requiring you to not only think intelligently about what you are engaging, but also act swiftly before your units get overwhelmed and killed. Our current goal in regards to the project is to be able to release a playable game by 2020, or sooner if plausible. We may also consider releasing a Beta version of the game for many to play and test, given enough people are interested, but even with that there will be some time before we reach that point. Given the game’s current state, we believe that it would be beneficial to begin to show off the game to you all, the community. Let us know what you think of the project, just by simply typing a comment below. We’ll be happy to answer any questions regarding Moonrise. Thank you for viewing our page! Check us out on IndieDB: https://www.indiedb.com/games/moonrise
    28. Last weekend I was still thinking through how I wanted to store all the map, texture, and sound assets for cut-scenes. Since then I've managed to work through the asset management, and have completed playback of the opening cut-scenes for levels in story mode. There are a few things coding-wise that I'm not entirely happy with, but cut-scene playback does now work without issue. I did attempt to refactor the rendering of maps into something re-usable for both the main level, and maps displayed during cut-scenes. I ran into technical issues getting the shared rendering code to work, and ultimately back-tracked to duplicating the code. Not where I want to be there for sure... The C++ 11 std::function and lambda expressions are what I struggled with a little there. I'm keeping a mental note to explore these further so that I won't struggle with it next time. During both game-play, and cut-scene playback, maps are fully rendered every single frame. It should be possible to instead render them to a separate texture, and just treat that fully rendered map as a sprite. Performance hasn't been an issue, given how simple this game is. But it's something I'll be keeping in mind for the future. In other news, I am super relieved that I chose to use GitHub, and push to it regularly while developing this game. I had a catastrophic failure with my main development PC, and have been able to continue working on this game without interruption on my laptop. Phew!! 😅 Ok, it's not entirely true it has been without interruption... I have a nasty habit of accidentally tapping the touchpad on this damned laptop while typing, and having the cursor reposition itself all over the place in my editor. 😩 With cut-scene playback effectively in the bag, it's time to start actually crafting the opening cut-scene for story mode. Then I'll be working on adding more types of food, crafting more levels, and generally working on the actual game I want to make! I've added everything I'll be working on as Issues over on GitHub:
    29. The Garden of Eating will be my second entry here on gamedev.net, a clone of the classic "Snake" game. I'll be using this as a platform to evaluate the SFML library, and to gain further experience in game development in general! Version 1.1 is available on my GitHub account! Story Mode Alpha Version 1.2 is available on GitHub as of Oct 6, 2019. My main goals at the outset: Option to play in a window or full screen. 2D graphics using sprites. Some basic sound effects and background music. I've reached an early milestone for "phase 2", which includes support for building custom story-based campaigns. The story mode currently includes support for: Placing obstacles on the playing field -- ie. map design! Ability to spawn multiple food items at a time, with the ability to define spawn zones on the map. One extra type of food: carrots, which heal the snake by a small amount. One type of danger: a spike trap. A scoring system. Some additional visual enhancements. My overall plan for "phase 2" is to provide a complete (albeit slightly silly) story-based game play mode: Brief story intro. Continue to add different types of fruits / veggies, with different effects on the snake. Progress through multiple levels of increasing difficulty. Graphics and animation enhancements. Controlled music loops that adapt to the game play.
    30. Zurtan

      Golden Fall

      Album for Golden Fall
    31. Zurtan

      Golden Fall

      Album for Golden Fall
    32. ▼ Watch the Devlog on YouTube ▼ ▲ Watch the Devlog on YouTube ▲ Hey everyone! I recently started the development of N.E.S.T, an action-packed, looter-shooter mobile game, and have been logging the progress through videos on YouTube every week! You can view the full playlist here. I would greatly appreciate if you could support the development of this game by subscribing to me on YouTube here, or by following me on itch.io here. Thanks for your time, and hope to see you all there!
    33. Daniel Lochner

      N.E.S.T

      N.E.S.T is an action-packed, looter-shooter mobile game that entrusts you to save Earth from an alien invasion after a rogue interstellar radio message leads them straight here. Unconventionally however, these aliens don't arrive via spaceships. Instead, large nests crash into Earth's surface, and it is up to you to destroy them all before the aliens regain their full strength, and take over our beloved planet. The development of this game is being logged through weekly devlogs on YouTube, and the full playlist can be viewed here. You can support the development of this game by subscribing to the developer on YouTube here, or by following him on itch.io here.
    34. davidkilmer

      Burn Baby, Burn!

      It is now time to implement FIRE! It seems odd that just now, after eight months of development, we are implementing fire into this game, being what it is (essentially a caveman). I think I have now come across one of the few same issues that I have spawned from the inception of this code. That is that base form aux tiles are not really treated as Item_Objects, but not visa versa, and that therein lies what I believe to be an issue. Essentially, to add burn, I went right to the Item_Object file and added Burn Hours and Item To Replace When Burned. This seems logical as if there is 0 for burn hours, the item is not burnable, anything else, it can burn for that long before being replaced with what would presumably be a useless version of the item originally burned. The problem, is Trees only exist in the fashion of being a aux tile, and that is it. Bushes could burn too, and they also only exist as a tile and not anything else. So we will start another “controller” and call it the fire controller. The purpose of this controller is to be the center point of a class called ‘fire_locations’ which will be attached to all Item_Objects that are on fire as well as tiles that are burning. It will also keep time on burning items and tiles, and switch the items and tiles once burned ( adding and removing the fire object as well ). That file is now started, a class as discussed, and some basic functions and a update that updates all the burning locations. Game runs normally and now we begin to try and figure out how this is all going to work. I am thinking that an Item_Object can have a “UseType” enum, where I have placed some values such as Fire, Shelter/holding, mining, cooker, forge . So the bow drill can be of UseType Fire, meaning that when it is used ( so either the use button is pressed, the user than places the item on the map, a fire starts assuming something is there to burn ), or in the event it is a shelter, it is now a semi permanent item on the map. This use type will help determine what happens at interaction and production of other items. We are starting to enter a crazy area of development, and I would hate to point out the flaws in my own coding design, but they are starting to become apparent now. I never once have thought about having prefabbed game objects containing the Item_Object script, versus constantly creating blank game objects and running the script and its appropriate actions/reactions on the fly. Honestly, I am not sure which one is better, but I fear/feel it will become more apparent as we continue on with this. It is only a prototype, and I guess that is where I can hang my hat. So, now that I have just opened a can of worms, lets take a single worm and make him tick. Lets start a damn fire! ( last night, I realized a rain storm should put fires out lol ). Success! Our little guy can build a camp fire and light it with his bow drill, and he can even light the forest on fire ( little shit! ). Lighting is not right, needs to flicker, isn’t lighting the player, not close enough to the camera, fire isn’t counting down its own clock, and the player can walk through the fire, pick up his campfire ( which goes into a void? Not back in the inventory, but of course, we don’t want this behavior to occur anyways. ) So yeah….. got some work to do! AAAAAHHHHAHAHAHAHAHAHA!!!!!! View the full article
    35. I made a simple example with checking of collision with right wall: Plunker: https://next.plnkr.co/edit/Bgf18uHzIkrRw9oW?preview CodeSandbox: https://codesandbox.io/s/texture-movement-webgl-10-typescript-3v8c6 GitHub + Build Instruction: https://github.com/8Observer8/texture-movement_webgl10-typescript private GameLoop(): void { this.Update(); this.Draw(); requestAnimationFrame(() => this.GameLoop()); } private Update(): void { this._x += 2; // Check a collisiion with the right wall if (this._x > this._gl.canvas.width) { // Move an object to left wall this._x = 0; } mat4.identity(this._modelMatrix); mat4.translate(this._modelMatrix, this._modelMatrix, vec3.fromValues(this._x, this._y, 0)); mat4.rotateZ(this._modelMatrix, this._modelMatrix, 0 * Math.PI / 180.0); mat4.scale(this._modelMatrix, this._modelMatrix, vec3.fromValues(32, 32, 1)); let uModelMatrix = this._gl.getUniformLocation(this._program, "uModelMatrix"); this._gl.uniformMatrix4fv(uModelMatrix, false, this._modelMatrix); } private Draw(): void { this._gl.clear(this._gl.COLOR_BUFFER_BIT); this._gl.drawArrays(this._gl.TRIANGLE_STRIP, 0, 4); }
    36. Deside to change an indication of enemie's level (it can be 0-2 with different health, weapon, and some abilities). Before it was shown by icon of different colors. It was a draft solution. Now it shown by props. For example - jerboa and racoon:
    37. Homeship

      Owl Shooter (Manager Killer)

      The project is unequivocally non-profit and applicable to such tasks: - go through the entire sequence of the project’s release in Steam, - get the project in the portfolio - Practice low-budget indie marketing. - game development skills upgrade ) And all this - with a minimum budget. The game is done on Unity. Some free content assets from the asset store. Many of them are highly modified. All code is mine. The plot and setting of the shooter is based on the comic strip by Alexadr Dyakov "Owl - is an effective manager. The Hare from the comic strip will act as the protagonist. His opponents: jerboas, raccoons, bats, wolves (as the most guards and security forces of the owl) and owls themselves. Duration of the game - 5 locations (Forest, Plant, Offices, Snow-capped mountains, Desert). 2-3 hours of gameplay. The emotional goal of the game is to respond to the experiences that arise when reading a comic book.)) The use of characters and several pages of the comic book has already been agreed with the author of the comic book. Game Features: - "dismembered" - you can shoot \ tear off an enemy limb, tail or head (which is lethal, of course). Also, the "fifth point" (ass) is vulnerable for some enemies. - several types of weapons for making "meat": fork, axe, chainsaw, flamethrower, grenade launcher, machine gun, double-barreled shotgun and one futuristic weapon avaliable close to the end of the game - a lot of blood and violence - high game dynamics (not DOOM but... )) - the possibility of attacks from the back, which provides the mechanics of "silent killings" - enemies have a limited view, and respond to sounds - weather system (snow, rain, fog, thunderstorm, wind), change of time of day - localization of hits and change in the behavior of opponents, depending on their condition. We trying to make it cheap (in development), simple and fun as possible. At the moment, alpha version of game is already ready. All described features of the game are implemented already. Current development status: - game mechanics (moving, interacting, shooting, damage models) - READY - UI - READY - metagaming (purchase of weapons and ammunition between locations, briefing and debriefing) - READY - AI of opponents (attacks, evasion, player search, reactions to changes in the situation, state of stunning, etc.) - READY - first location (passage scenario, content, level design, cut scenes) - READY - rest of locations - WIP the software part is 95% complete. Polishing gameplay, optimizing and bug fixing in progress. The following specialists are invited to the project enthusiastically: 1. Sound-designer 2. 3D artists (modelers) - enviroment props 3. 3D Animators - there are 4 characters need to be animated Planned Steam release - september-october 2019.
    38. Trying to bake a lightmaps for finished two locations: Forest and Factory. Unity crashes anywhere after 6-9 hours of baking. Reason: "not enough RAM, error I\O baking data". My PC config is: 1. RAM 16 Gb 2. CPU P4 G3250 3,2GHz. 3. Windows 7 SP1 64 bit. At the crash moment: CPU - full loading both cores RAM - full loading of 16 Gb Swap file is above 30Gb (50 Gb HDD is free) Unity GI cache is 11 Gb.
    39. Filling a canvas with set color. It is one of the shortest web application in WebGL 1.0 and JavaScript. It set a clear color and fill the canvas with the color. You can run this applications in Playground (in Plunker), watch demo, read code, make Fork, write something, send a link to your friends: https://next.plnkr.co/edit/nGfFeDfD9WbGs1aS?open=index.html&amp;preview Plunker: https://next.plnkr.co/edit/nGfFeDfD9WbGs1aS?open=index.html&amp;preview CodePen: https://codepen.io/8Observer8/pen/VwwmxLd JSFiddle: https://jsfiddle.net/8Observer8/akv6eh0o/ <!DOCTYPE html> <html> <body> <canvas id="c" width="256" height="256"></canvas> <script> var canvas = document.getElementById('c'); var gl = canvas.getContext('webgl'); gl.clearColor(0.2, 0.5, 0.3, 1); gl.clear(gl.COLOR_BUFFER_BIT); </script> </body> </html>
    40. dimi309

      Gloom

      This is a doom-style game, for the fall 2019 gamedev challenge. It runs on Windows, MacOS and Linux. It is nothing spectacular, since it was put together over the course of a couple of weeks. Part of what makes it interesting is that it was built using the small3d framework which, admittedly, was initially developed for far more modest purposes. To build the game, the Vulkan edition of the small3d framework is required. Precompiled binaries are provided for Windows and MacOS though. On MacOS, execute the gloom.sh script from the command line, from within the binary directory, otherwise it might not work. Gloom has been developed in C++. The 3D models have been created using Blender. There is a note in the sounds directory giving credit to the creator of the sound file.
    41. [The original post was published with its original formatting in The Gamedev Guru's Blog] Heya, Unity Addressables fan. Last week, I posted a short but powerful article detailing three ways Unity Addressables can help you developing better games. The article was very well received, thanks for your active participation. Just at the end of that post, you were given the chance to test your knowledge in Unity Addressables through a short quiz. The goal I had in mind when creating the quiz was to help you become aware of the areas you might be less familiar with, so you can get to develop your skills where you need the most. I'll confess that, initially, I didn't expect many people to go through the quiz. After all, quizzes can be daunting and, as usual, there's this extra babbling coming from me. But to my surprise, the quiz results well outperformed my expectations. I'm really happy to see that so many people accepted the challenge. You all rock! I got some interesting statistics out of the quiz. Here are some figures I wanted to share with you: The greatest part of the people who started it, about 80%, actually were determined enough to finish it The average score was about 12, which is pretty damn good for an API that was only introduced recently Less than 5% of the quiz participants fell in the Troll Guru rank About 50% are part of the Apprentice Guru group Over 40% of the participants scored enough to be Enlightened Gurus But only 5% made it to be considered The Final Boss Guru So, congratulations if you were part of the quiz experience! And independently from the score you got, I am sure it will not take you much effort to reach the production-level required score of 20+. I'll be helping you along the path. In this post, I will explain the most interesting challenges posed in the quiz. Some answers might differ depending on your particular context, so make sure to comment at the end of the post if you had a complementary experience. If you didn't complete the quiz before, do it now before reading further. Do not cheat. I'll know. What were your results? Are you a Troll Guru, an Apprentice Guru, an Enlightened Guru or The Final Boss Guru? Share your results in the comments section. Trusting that you finished it, let's have a look at the questions and some of the answers. The format should be self-explanatory, but I admit I could have chosen less cheesy graphics for it— yes, that's me. Question 1: Intense Memory Pressure An angry player leaves a 1-star review because your game uses too much memory. You... Answer in public, telling the player to upgrade their device and then come back This is a popular answer somehow. As much as we might feel like answering this, chances are, we have been too busy (or lazy) to implement a proper architecture. Blaming players for playing with a brick-phone won't get us more sales, so a better strategy is to fix our mess. Switch to a more advanced texture compression method, e.g. ETC2 to ASTC This is helpful and you should indeed switch to more advanced compression methods, where possible. But this solution will only take you so far. You'll get moderate gains in memory usage and texture quality, but they'll not be enough to cover your memory pressure issues. Split your scenes into sub-scenes, so less content is loaded in memory In general, sub-scenes used to be a good solution. I've used them in the past with great success. However, if you are having bad reviews already, chances are it is too late to introduce such a massive change in the architecture of your game. Better to look somewhere else. Implement an asset lazy-loading mechanism through AssetReferences Over 75% of people agreed on this, that's great. AssetReferences are likely to give you the biggest gain for the buck. The migration to this workflow is usually straight-forward and much easier than the other alternatives. However, be aware that, in some cases, it might be hard to work around the asynchronous requirements of the Unity Addressables API. Question 2: Endless Loading Times You press the play button. By the time your in-game scene is loaded, your coffee is cold. You... Blame the artists and ask them to put every texture into atlases. Also, you buy a faster PC 10% of the subscribers chose this one. I love you guys. Reduce the texture size globally, so asset loading is much faster. You don't submit these meta file changes in your versioning system I've done this a few times recently. It works. However, the pay to price is high. Your versioning system might go nuts and your changelists will be full of garbage. This is indeed hard to manage, as if you ignore these temporal texture import settings modifications, the real changes will mostly go unnoticed and won't be submitted. Create custom scenes that contain just the functionality you are working on Creating sub-scenes for faster iterations might be a possibility for your game, but in my experience, they tend to be left unmaintained. With time, they break and one might spend more time fixing them than the gain you eventually had back then. Consider implementing sub-scenes only if you don't see these problems in your project. Remove direct references and add indirect references instead, so only the required assets are loaded Indirect references for the winner. Direct references will implicitly ask Unity to load all their content as soon as the script holding them is instantiated. Indirect references, however, gives you full control over the when/how/what. That means, you can delay loading until you need it, if at all, saving you from unnecessary loading times and wasted memory. Question 3: What Play Mode Script? You are currently implementing materials for your new characters. You want to try Addressables, so in the Play Mode script section of Addressables, you select... Fast Mode: we want it always fast, after all This is a valid option, but fast mode does no validation at all of important aspects of development, such as asset dependencies and cross-references. If there are no substantial changes in the content you're working on, fast mode will be fine. Otherwise, we can do better. Packed Play Mode: yes! we want our characters to be packed No! The Packed play mode requires you packing the assets every time you do a change in your addressable asset contents, otherwise you'll end up loading the old versions. You don't want to be packing every time, it's a huge time sink. But you might consider packed play mode once you're done working with addressables content to gain faster iterations, as these assets will require minimum processing while being loaded. 35% of the Guru Challengers chose this answer. Virtual Mode: it sounds safer than fast mode Virtual Mode is the option I suggest you using while actively working on your addressable content. The virtual mode is fast enough to keep iteration times short and at the same time, it'll give you useful validation checks to avoid screwing it up and finding out the mess way too late. Question 4: Oops... Error Diagnosing You try Addressables but you don't recall your assets looking pink in your Android device. How weird! You... Enable the ADDRESSABLES_LOG_ALL symbol, make a development build and check the logcat logs If you came to me with such a description, I wouldn't necessarily take you down this road directly. The main issue with adding scripting defines and checking the logs on the device is the time it takes to prepare such a build, deploy it, test it and gather useful information from the logs. There are indeed better ways to tackle this, but certainly keep this as a backup option if they fail to give you an accurate diagnosis of the problem. Set the play mode script to Packed Play Mode and run it in the editor to further diagnose the issue with the Addressable Profiler Emulating as much as you can the environment in which the content will be displayed is my preferred option, as it takes the least total amount of time. You do this by selecting the packed play mode in the main Addressables Window settings. The Unity Editor will load the addressable resources directly from the built content, so this is expected to give you a similar behavior than on the device, as long as the editor can load such a content. You can also try running it in virtual play mode, which does some validation on top of the traditional asset loading pipeline for addressables. Don't forget to count on the Addressable Profiler's help, a tool that will inform you about the addressable operations that are taking place at all times in your game. This answer was correctly chosen by 66% of the participants. Post in StackOverflow and Unity Answers 12% of you see value in posting questions on these platforms, as there are always people willing to help. But preparing a reproduction project, posting and refreshing your screen with F5 is likely to take you much longer than just diagnosing and fixing the problem yourself. Trust me, this should be your last resort. Question 5: Heavy Video Packing You want your mp4 trailer video to be included in your game. You... Toss it into the StreamingAssets folder The StreamingAssets directory works just fine, especially when coupled with famous video plugins you find in the store. The assets stored in that directory are not packed together like Resources do but rather left as individual files when your game is installed. Its simplicity and easy I/O is the reason it is the default method of playing video. The biggest con is that the assets stored in StreamingAssets are forcefully packed in your distributed game from the beginning, so they are likely to take a lot of space in your build. Why would your users have to wait 5 minutes longer just to download the credits video that will be played at the end of a 30+ hours game? Mark it as Addressable, add a "videos" label to it Sure, making it addressable sounds cool. But adding a "videos" label to it? Usually, labels are used to download all assets belonging to that label category at once. Unless you have a very specific use case, doing this is not likely to help your project. Mark it as Addressable, adding it to a "videos" group with the following attributes: static content, no compression Videos are not likely to change, so making them static makes sense. Also, there's no need to compress them, as the used video codec should already offer you compression. Adding LZ4 or LZMA compression on top of this already-compressed content will only incur in CPU overhead. Your users' battery will drain faster as well. I'm sure your players wouldn't appreciate it. Mark it as Addressable, adding it to a "videos" group with the following attributes: dynamic content, LZMA compression Dynamic, compressed content is by far the most commonly chosen answer. But it is a misleading one. For the reasons stated above, you should avoid using compression on already compressed content. And videos are often enough very static, so by marking that group dynamic you wouldn't be helping your asset building workflows. Most people (46%) thought this was to best option. Question 6: Memory on Instance Releasing You loaded your asset once through LoadAssetAsync. Now you're done with it, so you... Call Addressables.Release, so the memory is immediately released There's no guarantee that the memory will be freed right away, as the current documentation correctly points out. But do not worry about it too much, it will be correctly freed by Unity. 23% popular. Call Destroy, we better make sure we free that memory up Addressables is, as of now, unaware of traditional Unity instantiation and destroy mechanisms. If you do so by yourself, you are doing it at your own risk and bookkeeping. If you mess it up, the API and OS are unlikely to be happy about it. And you will know. Call Addressables.Release, so the memory is released at some point in the future The documentation implies that the memory occupied by addressable assets will be freed at some point in the future after calling the Unity addressables release method. You can count on Unity smartly deciding when it is time to do just so (e.g. low memory situations, Resources.UnloadAllUnusedAssets, etc.). You guys got this one right! Question 7: Loading with LoadAssetAsync You're excited about doing your first Addressables.LoadAssetAsync. So you call it and use its returned handle like... while (handle.Status == AsyncOperationStatus.Succeeded) ; I confess to you that I've tried this method to try to force a synchronous behavior out of the Addressables API (e.g. Photon Networking under Unity Addressables). But you can guess what happened after seeing the answer's smiley. My computer's fan started spinning insanely fast and I had to reboot the computer as the OS became utterly unresponsive. I'm not trying this again any time soon, thanks. Doing this loop is likely to cause a deadlock, as part of the loading process is executed in Unity's main thread. And that line of code is the easiest way to block your main thread. await handle.Task; or yield return handle; These two solutions are asynchronous ways of waiting for the loading process to finish before continuing with our code. That's great stuff for you and me, as they offer great readability and are easy to maintain. However, be aware they incur on some performance penalty. handle.Completed += OnLoadCompleted; This is the simplest and yet most powerful option to do something after the asset has been loaded into memory. Keep in mind, though, that you're introducing lambdas and/or callbacks. They will reduce the readability of your code and therefore make your programming style more dangerous. Unless you are a pro, of course. Question 8: Migrating to Better Workflows You have a bunch of skyboxes living as direct references in your Skybox manager as a list of materials. Those are eating all your memory, so you... Move them into the Resources folder and start using Resources.Load as you need them No! Bad boy! Don't ever use the Resources directory for heavy assets. They are a major cause of pain, tears and burnouts in large scale projects. It is indeed surprisingly easy to misuse the Resources API. Read more info on why it is so here Put all skyboxes in an asset bundle that you will load appropriately Asset bundles were a much-needed solution back then. But we have better solutions now with Unity Addressables. The issue is that working with asset bundles is way more tedious and expensive to implement and maintain than just using Unity Addressables. Unless you're doing a port and you don't want to touch much of the original systems, try to avoid them. Replace the list of skybox materials with a list of AssetReference's and load them as you need Using Unity Addressables is probably the best option to tackle this kind of memory issues. One of the reasons it is such a silver bullet is because you can easily migrate from the most popular approaches of managing content such as direct references, resources API, additive scenes and asset bundles. Unity Addressables are a simpler way to develop more efficient games. Decrease the skybox texture sizes Tweaking the texture import settings works up to a point. This has an upper ceiling limit, as you cannot infinitely go lower in memory usage (and quality) without re-categorizing your 3d game into pixel-art. This just doesn't scale well. Chances are very high that you didn't reach the rank of The Final Boss Guru. But that's good, because that means there's massive room for improving and optimizing the way you develop and ship games. And what is more important, your players will appreciate the expertise you build in each of these areas. The only place you want to read 1-star reviews is at the app store of your competitor's game. Given the importance of delivering enjoyable experiences to your players, I will share something with you. Between you and me: I have a work-in-progress plan for maximizing the potential of your game with Addressables. In the upcoming weeks, I will be revealing to you more information about the Unity Addressables level-up program I'm developing. That program is going to get you to the production level you need to deliver the games people will deeply enjoy (purchasing and) playing. To make sure you don't miss on the upcoming content, subscribe now to the newsletter. I'll keep you posted. Till then, comment below on what you would like to learn the most and also how you plan to use Unity Addressables in your project. See you soon on the blog! Rubén
    42. DavinCreed

      Doomish

      6 Doomish - Done 5 Doomish - Almost Done... Except Fer Them Levels 4 Doomish - About 70% Done 3 Doomish: About Halfway Done 2 Doom: More Art Assets 1 Doomed Beginnings This a doom clone for the game dev challenge. I'm adding in a few things, a dodge and a GameDev.net power up. Other than that, I'm going to try to get a game that is Doom. Controls: A, D - Turn W, S - Walk Q, E - Strafe Right Ctrl - Hop/Dodge Space - Use/Open Enter - Shoot Escape, P - Pause Menu 1-6 - Switch Weapon
    43. Vulkan Mobile Best Practice: Picking the Most Efficient Load/Store Operations the article describes how the architecture of mobile GPUs is different from PC shows why load/store operations have a significant impact on mobile present a demo application to profile the various load and store operation wayback-archive Raw DirectX 12 the tutorial shows the steps necessary to render a single triangle using the D3D12 API wayback-archive Raw WebGL the tutorial shows the steps necessary to render a triangle in WebGL using Typescript wayback-archive Massively Parallel Path Space Filtering in Game Development excerpt of Siggraph 2019 talk that proposes averaging of neighboring rays into cells using a jittered access + filtering to remove artifacts of discretization wayback-archive Radeon™ GPU Analyzer 2.3 for Direct3D® 12 Graphics the article shows how to use the Radeon GPU Analyzer to generate hardware native ISA disassembly, provide resource and register usage statistics wayback-archive GOON – VOXEL OBJECT the article describes a demo scene effect that uses a 2D height map on a flat 2D shaded object to simulate the appearance of 3D voxels wayback-archive Handling Depth for Spheretracing next part of tutorial series shows how to extend a sphere tracing implementation in Unity to use the depth buffer correctly shows the necessary shader state changes and how to calculate custom depth output in a pixel shader wayback-archive GGX Derivation the article presents the derivation of the GGX BRDF wayback-archive A Journey Into Journey’s Sand Shader part 1 of a Unity tutorial series about the sand rendering in Journey show visually the contribution of the different shading components wayback-archive Thanks to Michael Riegger for support of this series. Would you like to see your name here too? Become a Patreon of this series. Read more
    44. Well, well, well ... look who's here! It's you again! Welcome to your favourite Weekly Updates blog! This week was a very proactive one. I managed to add several new challenges. In all, there are 5 new and unique challenges. So, without further ado, let's get started! New Challenges First of all, as most novelties are platform challenges, I will introduce them one by one. I will just introduce them and briefly describe how they work. I've also recorded videos for most of the challenges. All of these challenges are of the generic type. This means that any of these can be chosen for any level. That's why they all have a heavy vaporwave/shopping mall theme. But keep in mind that I haven't had the time to incorporate them into the game yet. Thus, no loot for now... Challenge #1 The first challenge consists of several vertically moving platforms and three distinct elevations. The idea is to use the moving platforms to climb the central obstacle to reach the final elevations. The most observant of you have probably noticed that the middle elevation has a cracked wall. This is a useful shortcut to avoid wasting time on moving platforms. Here's a small video showing it off: Challenge #2 This second challenge consists mainly of two symmetrical forked paths with several mobile platforms. At the end of each branch, a switch can be found. The idea is to activate both of those. Once they're both on, a super-secret room opens up at the beginning to reveal the loot. If you make a mistake, use the nearest ladder and start again from there. After all, you can't rush these: you'll have to take your time ... Challenge #3 This challenge is not so much a "platform" as a "puzzle" ... It does not have a mobile platform, but ladders and stairs. This challenge consists of a series of toggle switches. Here, whenever a switch is toggled, its immediate neighbours get toggled too. The trick here is to toggle the right sequence of toggle switches to turn them all on at once... Some would say that this kind of puzzle is a "classic". While they're somehow right, the thing is that here we can't see all switches at once. Thus you have to memorize it. Once all toggle switches are on, the loot will appear at the back of the room. Challenge #4 For this next challenge, there's a balanced mix of puzzling and platforming. It's split into three sub-challenges: a toggle switch puzzle, a moving platform challenge and lastly a pressure plate puzzle. The first one is a 3x3 version of the switch puzzle seen in challenge #2. However, unlike the latter, it's much more open and less convoluted. The second one is a platforming course. Any mistakes will result in you restarting the whole course. Finally, the last one is a pressure plate puzzle. The idea is to use pushable blocks to activate pressure plates. Except it's not as easy as it seems... All of these must be completed in order. After clearing everything, the last part opens up, revealing the loot. Unfortunately, this challenge isn't complete yet. There are essential things not yet implemented, like pushable blocks... So no video for now... 😢 Challenge #5 Finally, here's the last challenge. A pure platforming challenge, it's quite vertical and very spacious. The goal is quite simple: climb the tower. There are moving platforms to help you. But be warned: these platforms are small, narrow and quick. Proceed with caution! However, make one mistake and it's back to square one. So take your time and don't rush! Minor Updates Added Screen Space Reflexions Next Week For the next week, I plan to add more challenges while trying to integrate these first in the game. There are several ways to do it, but to stay in the theme of the vaporwave I think I'll replace the steps by an elevator (small elevator music included). I just need to model it and to add it to the maps' generation process. Otherwise, I still have pieces of equipment to add. After that, it's your usual suspects. So yeah, that's about it!
    45. Textured Rectangle in pure WebGL 1.0 and TypeScript. I use glMatrix for Linear Algebra. Playground: Plunker: https://next.plnkr.co/edit/4pnm93F1eWQuvpYg?preview CodeSandbox: https://codesandbox.io/s/textured-rectangle-with-transforms-typescript-s7gfb
    46. Vilem Otte

      DOOM: Post Mortem

      For past 2 months there was a challenge running here on GameDev.net - this time I finally decided to participate. INTRODUCTION I, as many others, remember DOOM as one of the first (if not first) 3D games that we have played. GROOM is inspired by DOOM, built upon custom in-house ray tracing library, it allows you to experience a small map rendered with path tracer. The single level design is inspired by level from DOOM 2 - Dead Simple. This is not the only similarity with DOOM, having half-robot and half-demon spider-like enemy is another, and AI and behavior is also similar (enemies need to be 'activated' by shooting, otherwise they are not aggressive). WHAT WENT RIGHT? The whole idea of mine was bringing a real time path traced game (as DOOM was essentially a game using ray-casting). This whole had to begin with building a ray-tracer. Or to be precise a ray-tracer library that is fast enough to render complex environments at interactive frame rates. For this I was putting together something I will refer to as "OpenTracer" (subject name to change) - which ended up in OpenCL based library for ray-tracing. If something went right, it is indeed this ray-tracing library. It actually ended up having quite interesting features like: Support for BVH ray tracing (built using SAH, HLBVH, MULTI-LEVEL) MULTI-LEVEL BVH being the most useful, allowing not just for dynamic scenes, but also instancing BVHs (even bottom level) can be dynamically rebuilt (for characters with skeletal animation) Semi-programmable pipeline (would need a bit of work, but still - possible) Support for textures (building big texture atlas, which is then used during rendering) Somewhat useful library interface (building 'data buffers', requesting BVH built for those, etc.) Due to library design, it is technically re-usable Etc. I just went a bit ahead and wanted to try rendering some nice pictures, let me show an example here (of Crytek's sponza), the following image was rendered in under 1 second on AMD Radeon Rx 590 (interesting fact - it can run on Intel HD 620): Fig. 01 - Sponza path traced (note, I have placed enemy from DOOM into it) Other than that, what went right is actually finishing the project. With longer competitions (like 2-months ones) the original interest goes away after short time, and you need to keep working on the project to actually finish it. WHAT WENT WRONG? If I can state which parts I'm not satisfied in the project - the list would be quite long. But first and foremost it is the scale of the level and having a lot more programmer's art than what I wanted. The actual art for the game was made within last 72 hours before final deadline, not sooner. Luckily the first thing I did was blocking out the design for the level: Fig. 02 - Block out design of the level Of course, having a good art requires time - so I had to make as much as fast as possible - most of the models ended up being blocky. Additionally to that I was probably saving way too much geometry to end up with high performance (the actual performance hit by having more triangles isn't really a problem ... as there is BVH acceleration structure - theoretically doubling the geometry adds just single additional level to it). In the end I was actually able to build up most of the map, and an enemy (which has a hand made skeletal animation). Although not nearly at the quality I wanted. SOMETHING I LEARNED I have hit the typical problem for most challenges or jams and that is - time management is critical (I have literally planned what to have finished by when - to actually be able to finish the game). Some deadlines were done long before, some few days after. But mostly I have kept to written features/dates and that helped me finish the project. Unlike Ludum Dares (in which I participate regularly) time management for longer project is different (additionally you also have to fit in work/business and family into it ... and yes, even recent Ludum Dare was put into the plans). Apart from that, I've found out that handling dynamic scenes with ray-tracer is far harder compared to standard renderers like Direct3D (or even software rasterizeration ones). While I was working with ray-tracing a lot during my studies, I have actually never worked with fully dynamic scenes or dynamic deformable objects in it. CONCLUSION The challenge was actually quite interesting, I enjoyed it a lot (especially due to fact that I could work with ray-tracing). If you want to try it - go ahead and try playing the game.
    47. Hello there! This blog post serves as a post-morten of sorts for my latest game: PulseHazard! PulseHazard is a DOOM clone, built to replicate as close as possible the DOOM style of gameplay and atmosphere as and entrant to the GameDev.net August Challenge. This was my first time using Godot, and that brought it pros and cons: Pros: Godot is REALLY easy to get started with, the editor is a mix of Unity/Game Maker and has a node tree organization system that makes communication between nodes very simple. Godot supports several languages, but I stuck with GDScript, it is the more documented (more on that below) and has an easy to understand syntax. Its API has several ready to use functions for common tasks such as game pause Cons: Using Godot for anything 3D (even as simple as this game has) is a chore sometimes. Importing models from Blender can take some serious work (tip : always use the gltf exporter, over the Collada or Godot solutions) and be prepared to reassign all the textures if you plan to do so. The editor is somewhat unstable and some weird bugs can occur, such as your nodes moving out of place without your consent. Also, the documentation is seriously lacking. To the point that some examples are really old and don't work anymore. On the bright side, the docs are, along with the engine itself, open source. So, if you are up to the task, you can make changes and fix some issues with the editor, renderer etc. Replicating the DOOM experience was really ease, thank to the extensive documentation about the original game, easily found on the internet. From enemy behaviors to graphic related parameters, anything can be found quite easily! In order to make this project, I barely played the original game, to be honest. However, I'm fully aware that some aspects of my game will not replicate 1:1 to the original DOOM because of that. The hardest part to get right was definitely the 8-sided sprites. Godot offers dot product calculations to help with that. However, 3D math was never my "forte", ao I still thing this is one of several aspects that still need work. I also had problems with the Shotgun spread shot, but I didn't have time to finish it before the Challenge Deadline. So that's it! I plan to keep working on this project and, who knows, maybe turn it into a commercial game someday! Please, check PulseHazard and have fun! Any feedback is appreciated Have a nice day! Bye!
    48. gametable

      Dots and Boxes

      Tabletop Dots and Boxes is gametable's third game. Dots and Boxes is a fun and simple classic pen-and-paper game for 2 or more players. The game starts with an empty grid of dots. The grid can be any size and Gametable's Dots and Boxes has a handful of board sizes to choose from. Players take turns connecting 2 unjoined horizontally or vertically adjacent dots. A player who completes the fourth side of a 1x1 box earns one point and must take another turn. The game ends when all lines are drawn and boxes are claimed. The player with the most points wins. If more than one player has the same high score, the game is a tie. Features: Up to 4 players 4 computer difficulties to challenge Different board sizes to choose from A number of fun game board themes Automatic game saves so you can come back anytime Neato Programming Notes Creating a challenging AI for this game was... hard. It turns out that a simple Minimax or Negamax based solver doesn't work well as an AI for more than 2 players. We had to do quite a bit of research to find an AI approach that would work well. We stumbled upon a little known algorithm, Hypermax, that did the trick. Additionally, the game state tree for even a fairly small dots and boxes board is absolutely massive and pretty much unapproachable for real time AI. We spent the majority of coding time on this project figuring out how to reduce the search space with intelligent move generation, ordering, and culling. The AI turned out pretty great and is extremely challenging even in two player mode. We're extremely proud of this technical achievement.
    49. Hey GD.net community! We're excited to have joined and be whipping up a first blog post to announce release of our Dots and Boxes game. A little background about us, gametable.org. We're a non-revenue side project game site created by a few friends honing their game development skills. We don't show any ads and don't have any intention to in the near future. Most of our games will likely be parallels of classic real world games or modernizations of simple old school computer games. Now on to Tabletop Dots and Boxes- This is one of our favorite childhood games. When we learned that we'd all played it on pen and paper as kids, we figured it would be fun to take it digital. We kept the UI and SFX relatively simple, stealing the overall look-and-feel from our previous two games. Where we stretched our legs with this game is artificial intelligence. We poked around on the web and found a number of existing dots and boxes games, the best of which offered play for up to four players. We thought this was a nice touch and decided to tackle it ourselves. 4 player pass and play was easy, but creating an intelligent AI that wasn't overly paranoid and ran in a relatively small amount of time was difficult. We tried a number of classic approaches using minimax, then negamax, then negascout. All three suffered from acute paranoia. After way too much time hunting we found an extension of minimax, Hypermax, that solved the issue. To our surprise this algorithm was employed in a 90's NES game called "Spot." Spot is based on the 1990's 7-UP mascot and is 2+ player connect four style game. Playing it is on our todo list. Hypermax is so similar to minimax with ab pruning that we had a little trouble implementing at first. We kept making assumptions about how it works. When we eventually landed on a working version of the AI, the solution was stunningly simple and elegant. If you want to talk about it, shoot us a message. Even with Hypermax, getting the AI to hit deep evaluation depths with limited evaluation time was still a challenge. The game state search space for even a small dots and boxes board is massive. Toss 4 players into the mix instead of 2 and the evaluation overhead just goes up. The first thing we did to overcome this was move all of our AI code out to a web worker to take the load off the rendering thread. Next, we spent weeks identifying intelligent move generation, ordering, and culling rules to dramatically reduce the search space. If you give the game a go on a larger board size with 4 players you will still see it take a moment to generate an AI move when game is about 1/2 complete, but its well within tolerable levels for a player. We're super stoked about the AI we came up with for Dots and Boxes. Its a heavily studied problem and a number of excellent AIs exist but not many that run in real time and pose any real challenge. We believe ours does and haven't seen a better one out there yet. Give it a shot and let us know what you think. Looking forward, we'd eventually like to add multiplayer support, but that is a ways down the line. More new games first! What classic games should we build next? Cheers, Gametable.org
    50. The Load/Save code is confirmed working, even with the cities and AI. So now the game state can have progress! Also, we have our first two multiplayer tests. The first was local and because of a bug, could only do three people. The second lasted for 3 hours and had 6 people (thank you testers!), and was done over the internet (which was actually a first!). There were no complaints about performance or lag, so I think the networking code is working well. There are two known bugs that need to be tracked down, but such is development. They weren't critical enough to stop a lot of melee battles in space! Both pulse based and beam based ships were tried out. A lot of good feedback was had, and everyone enjoyed themselves. Currently, it was simply dog-fighting in space. However, the biggest comment was how one got destroyed. Meaning, depending on what got hit, a person might lose a weapon (or all of them!) and limp along. They would experience the controls freezing when their engines exploded but didn't kill their ship, etc. So it felt more like dying by pieces rather than all at once, so it was a fresh experience. Some of the feedback was taken to heart, so some of that is the screenshots enclosed. One was a sense of movement. So that got implemented by green “grid lines” as shown. Also, whatever is targeted now has a listing of who owns that object (building or ship). So it makes it easier to know which if your friends you are blowing up! Other code additions have been getting the camera working again so that some of the “out of body” screenshots are now possible again. More to the point, the collisions with the ground with ships and weapons now works correctly finally. As shown in the screenshots, the ship one is flying is smaller than one thinks. The lighter blue triangles are showing the progression of the beam across the surface of the planet if it was perfectly smooth. The darker blue triangles are the same triangles as the lighter blue, but follow the terrain. In the end, you can see where the impact is on the ground. These beams are from an older design that had a longer than usual range. I look forward to more multiplayer testing and scenarios as time moves forward. Hopefully there will be some videos of that at some point. Full story »Original post blogged on Rank: Warmaster Dev Blog. View the full article
    51. gametable

      Checkers

      Tabletop Checkers is gametable's second game. Our Checkers game can be played with a friend or against one of four computer difficulties. The goal of Checkers is to remove all your opponent's pieces from the board or prevent them from making a move. The game is over when one player has no remaining pieces or can't make any valid moves. You may also elect a draw if each team only has 1 king remaining. Features: Four computer difficulties to play against Pass-and-play two player mode Three board sizes: 8x8, 10x10, or 12x12 Four fun board themes to choose from Show Moves, Hint, and Undo options to help when you're stuck Force Jumps option for tournament style play Automatic game saves so you can come back anytime
    52. gametable

      Tic Tac Toe

      Tabletop Tic Tac Toe is gametable's first game. Our Tic Tac Toe game can be played with a friend or against one of four computer difficulties. The players, X and O, take turns marking spaces on a 3x3 grid. The first player to get three in a row wins! Gameplay is simple and nostalgic. While not a technically challenging game to develop, we're still proud to call this our first game.
    53. JohnyBGooD

      PC Devlog #7: Building System.

      Greetings, Now our alien can build Holographic Bases with a variety of unique features. The building process consists of 2 stages: energy floor design and creating of items. The alien can create 3 types of energy spheres, they can be combined in many ways. This gives us different energy schemes for further building. The items require a certain amount of energy in the floor beneath. Currently 2 types of items are ready: nutrients farm and resource farm. I plan to add much more items with unique and interesting features in the future. In the video you can see the process of building along with an episode of building resources gathering. Video demonstration is here:
  • 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!