Jump to content
  • Advertisement

All Activity

This stream auto-updates     

  1. Today
  2. Ravyne

    Large Tilemap Storage

    A 2D array is usually more than sufficient for 2D map storage and iterating through it. As long as you're not falling into any performance anti-patterns (e.g. drawing the entire map instead of just the screen, not walking the layers/cols/rows in memory-order, failing to batch draw calls, etc.) Draw efficiently, iteration is not going to be your bottleneck. Back in the day we were drawing 320x240 screens with ~450 tiles (1 dense layer + 2 sparse layers) using software blitters at 60fps on 66mhz 486s, albeit at 8-bit color. What's often more useful is chunking the whole map into regular sections, either so that you can stream them from disk or just to keep memory use down if it's a concern on your platform -- but that approach ultimately only amounts to a 2D array of map sections, which themselves are 2D arrays of tiles. Even something like a quad-tree is likely over-thinking a 2D game. There's an article floating around about optimizing minecraft-like cube storage, where they looked at various more-complicated storage schemes like RLE arrays and compressed octrees -- the conclusion was that plain old 3D arrays were the winner anyway, and I think Minecraft world sections are (or were) something like 32x32x256. Drawing performance comes from how they generate and optimize draw calls from this simple storage, not coming up with any sort of clever storage.
  3. Iron-Warrior

    Toon Shader Using Unity

    This tutorial is published with the permission of Erik Roystan Ross of https://roystan.net. Roystan writes articles about game development using Unity. GameDev.net strongly encourages you to support authors of high quality content, so if you enjoy Toon Shader Using Unity, then please consider becoming a patron. You can view the original article at https://roystan.net/articles/toon-shader.html. Source code at https://github.com/IronWarrior/UnityToonShader. Become a Patron! Interested in posting your articles on GameDev.net? Contact us or submit directly.
  4. Hello - I recently started designing a tile-based game, but I'm not exactly sure what would be the best method for storing my tiles in the map that will be displayed. I understand that most maps are a simple 2D array with each dimension representing the different axes (x, y), but my game has massive quantities of tiles that need to be displayed at once (I don't have an exact number, but I know it will be over 60x30, which is 1800 at once). I'm fairly certain that the aforementioned construct will be too simple and costly for my needs. I'm also looking to delve into simple procedural generation in the future, meaning I want my method of storage to be able to be easily modified/populated. The best analogy of a game I could give for reference is Terraria, since it has both procedural generations and a bunch of tiles. To simplify, my question is basically: What would be an efficient way to store a map with large amounts of tiles (in the thousands), while still allowing the construct to be populated relatively easily? Thanks for any input/help.
  5. Yesterday
  6. chimchooree

    When code just isn't enough...

    I don't understand what kind of game you're going for, but there are lots of very basic and childish examples of gamification of good deeds out there. I thought about mobile apps that track your daily tasks with RPG elements like https://habitica.com/static/home, "chore bingo" like https://www.laramolettiere.com/product/chore-bingo/, and the point systems that clubs commonly have for tracking and rewarding participation. To explain better, my AWANAS club at church gave me points for bringing friends, memorizing Bible verses, and completing my homework. I could spend those points as currency the little store and buy little toys or candies. The members with the highest points got special prizes. I hope these examples give you more context for where your game fits in this "genre." Anyways, try not to get paralyzed by the blank sheet of paper. Getting stuck in the planning phase is no good. Group your ideas and find a couple of options for the identity of your game - the platform, the basic mechanics, etc. Once you can rewrite your basic concept into some actionable technical requirements, you can begin a simple prototype. Testing a prototype would help you talk about something concrete. Good luck. I remember your first blog here and wish you well!
  7. Not sure about the Direct Manipulation API, which bit/interfaces were you looking at specifically? I was under the understanding it was built on the window events, but maybe I understood it wrong. I am surprised raw input didn't report anything, which exactly did you register for? I am sure I recall some stuff specifically about contact points / touch pads. There is also WM_TOUCH, do you get any messages for that?
  8. Actually - after digging through Chromium's source code the answer is that there's a whole separate API I wasn't aware of. Direct Manipulation is both fast and powerful, as well as painfully complicated to manage, especially if your codebase is OpenGL-based (which mine is). After I got the bulk of the thing running it turned out that since the DM provides asynchronous scrolling updates, it requires access to an IDCompositionSurface-based draw object, which is based on DirectX. In practice this means building a layer between GL and DX simply to support scrolling. In case anyone is reading this and wondering, apparently the easiest way to go about this is via ANGLE. I'm presently snooping though Chromium's codebase, trying to figure out if it's worth the headache and I'm on the verge of giving up. I'm actually annoyed to boot that MS doesn't allow the API to function without attaching an output device and source buffer to the compositor (that is to say I haven't found a way to have DM simply report scroll/touch offsets/transforms/viewports as basic numbers - if anyone knows a way, I'd love to daisy chain these into my own existing render stack). I'm on a regular laptop and trying to figure out how to handle a good old touchpad/trackpad. My guess is that DM gets this data directly from the driver.
  9. Hi everyone, I'm trying to implement the displacement mapping technique by William Donnelly from GPU Gems 2: Chapter 8 for a project. I'm working in XNA/MonoGame and using HLSL for my shaders. The problem I'm having is how to create the distance map and I'm not really understanding how I would go in creating it. I know that Nvidia has released the code for that chapter but the files are in c++ and I'm not familiar with c++ so its been throwing me off on how to recreate it in c#. Any explanation on how I should go about in creating the distance map would be extremely helpful. Thanks for any help or suggestions.
  10. GoliathForge

    Battletech Developer Journal - 03

    This blows me away because it's exactly what I do. First with string ID then ah, cool a numeric ID. Now I've hit the more you learn the more you realize you don't know thing. Nice one.
  11. I'm happy to help. When I first discovered enums oh so long ago, I thought, "These things are awesome! It's a strongly typed value I can use and bring clarity to my code." And that's mostly true. It's honestly not too much trouble to keep bolting on more hard coded logic any time you want to add a new type. But once you start working on bigger projects with people who want new things... and they can't code the new stuff themselves... UGH! Now I have to take time out of my day to do some boring grunt work when it should be as simple as someone copying/pasting a file and changing a few values.
  12. GoliathForge

    Battletech Developer Journal - 03

    The lone wolf maybe thinks about it a little different because he's already in there but yup, smells like that here for certain. Data driven you say? Thanks for the nudge.
  13. I'm Chris Eck, and I'm the tools developer at HBS for the Battletech project. I've recently been given permission to write up articles about some of the things I work on which I hope to post on a semi regular basis. Feel free to ask questions about these posts or give me suggestions for future topics. However, please note I am unable to answer any questions about new/unconfirmed features. A few weeks ago we started a more stringent code review process where everyone is supposed to put changes on a feature branch and then get those changes code reviewed and tested before merging it back in. For most devs I imagine that's between 1-2 feature branches a week. But my task list is a bunch of small, unrelated changes all over the system so that was 1-3 feature branches per day. Needless to say, everyone has been super busy working on Urban Warfare (and things are looking awesome by the way) so I had a big backlog of these. That couple with a Jira/Confluence hiccup meant I spent most of last week implementing code review feedback and merging my code back in. But I still worked on a couple of interesting things and I have 3 years of working on Battletech to pull from. So if I don't write one of these Journals it's cause I'm being lazy. New Region Types Until recently, we only had a few region types: Positive(Gold), Negative(Red), and Hidden defined by a RegionType enumeration (enum) in code. In the early days we felt like this would be enough to differentiate and identify the different region types. But after we shipped, there was still a bit of confusion about particular regions. Like the Escort Destination region in Capture Escort - is the player supposed to stand there? Or the Ambush Convoy mission has a Negative escape region for the enemy. The purpose is to prevent the enemy from getting there, but standing there is actually a good thing. To clear up this confusion we decided to implement new region types, and expose more data to the user like varying regions by color and then adding region labels. At first I was just going to add more values to the RegionType enum, but as I worked through it, I became more aware of the hard coded switch statements tied to its label and color. Bleh. Even though it was more work right now, I refactored RegionType to be a new RegionDef data file. For each region type there will exist one of these RegionDef files. There, we can specify what colors, the labels, and descriptions of the regions. // Original enumeration enum RegionDisplayType { Hidden = 0, Positive = 1, Negative = 2, } // Sample of some hardcoded colors tied to different region types public Color GetRegionColor(RegionDisplayType regionDisplayType) { Color regionColor; switch (regionType) { case RegionDisplayType.Hidden: default: regionColor = Color.clear; break; case RegionDisplayType.Positive: regionColor = UIManager.Instance.UIColorRefs.GetUIColor(UIColor.Gold); break; case RegionDisplayType.Negative: regionColor = UIManager.Instance.UIColorRefs.GetUIColor(UIColor.Red); break; } return regionColor; } // New RegionDef files get one file per Region Type. { "Description" : { "Id" : "regionDef_EvacZone", "Name" : "Evac Zone", "Details" : "When active, move all of your units into this zone to evacuate your units.", "Icon" : "" }, "FutureColorHex" : "#F79B2680", "ActiveColorHex" : "#F79B26FF", "FutureLabel" : "Future Evac Zone", "ActiveLabel" : "Evac Zone" } Now the only code I have to write is letting the designers choose which region they want and drive the choices off of the files in the RegionDef folder. All those hardcoded switch statements get converted over to just using the appropriate bits of data like selectedRegionType.ActiveLabel. And now, any time a designer wants a new region type, they can add it themselves by just creating a new Region Def file instead of pestering me. Localization Since we're going to be showing region labels now, that's some new text in the game. New text in the game means new translations to be made. The developer who normally handles Localization tasks was busy doing other things so after a quick 15 minute discussion on how things worked, he sent me on my way. First I needed to write up a RegionDefStringsCollector class. Since I'm working with a json file, it's pretty simple. I inherit from a Json String Collector base class, tell it my ResourceType (RegionDef) and just override my Collect method. Then there's a Localization class that has a list of all the Collectors. I add an entry to my new class and then the next time the strings get collected for localization, all my new data will get collected. public class RegionDefStringsCollector : JSONDataStringCollectorBase { // Tell the JSON collector what type we are public RegionDefStringsCollector() : base(BattleTechResourceType.RegionDef) { } // Collect our strings into the locTable protected override void Collect(string jsonText, EditorLocTable locTable, string source) { RegionDef def = new RegionDef(); try { def.FromJSON(jsonText); if (def.Description != null) { Util.CollectDescription(locTable, def.Description, source+".Description"); } Util.AddToLocTable(locTable, def.ActiveLabel, source + ".ActiveLabel"); Util.AddToLocTable(locTable, def.FutureLabel, source + ".FutureLabel"); } catch (System.Exception e) { Debug.LogError("Error reading " + source + " " + e); return; } } } Work Bench And this weekend I was productive at home too. I ordered a bunch of lumber for some projects around the house and knocked out my work bench. Somebody said look at all those tools in the blog post image that he doesn't use. Well here's proof that I do! Tips from your Uncle Eck Be careful with your use of enums, they can be a code smell that something isn't quite right. If you find yourself hardcoding logic to specific enum values, you should definitely consider switching to a data driven system. That way when people change their minds, they can just change the data in a file instead of having to change code and cut a new build. Plus it makes modding your game that much easier. Links Previous Journal: https://www.gamedev.net/blogs/entry/2267089-battletech-developer-journal-02/ Next Journal: Stay tuned Twitter Post: https://twitter.com/Eck314/status/1118878585736003585
  14. RPTD

    Vulkan? OpenGL? What........?

    I guess then I need to hurry up putting those finishing touches in place
  15. GoliathForge

    When code just isn't enough...

    okay. well, if my idea is going to be a success, I think I need more than a handful of people looking at my creation. So, as I'm building what will be viewed as long lasting / desirable art, I need more. A lot more. Each telling the one next to them about this great thing that got built. A percentage will fade,some may trickle in. All depends on that crowd that pumped the idea to how ever many spikes you could get out of the thing. <'gotta stop here dude. I've reached my poetry limit> See you around the next bend.
  16. Embassy of Time

    When code just isn't enough...

    Oh, I don't mind sharing, I just respect that people rarely find my code very... elegant. It's not advanced enough to warrant protection, at this point it's mainly a few PHP file handlers and some GUI generation (text based, for now). If you want to see it when it's done, you're more than welcome! What exactly do you mean by that? It sounds interesting!
  17. Davicus

    Artist looking for team/partner!

    Hi CookieLover, Our team has two programmers and one other artist and a number of musicians on smaller 2d games using the GODOT engine. I have a gamejolt page and we have started programming a proof of concept for a WWF style wrestling game. If all goes well the programming should be done in a couple months. You can message me here or email me at david1platt@zoho.com.
  18. JoeJ

    "I hate naming things"

    Just this old video: Far from ready for a game. I really hope i can continue on this maybe in some months...
  19. GoliathForge

    When code just isn't enough...

    Too bad. If we were all open with source, this party might really kick into warp speed. (or be flooded by the copy/paste guys and gals) Tough call.
  20. GoliathForge

    When code just isn't enough...

    In a way I was thinking something similar outside your blog entry. How can I mass a population and inexorably make my idea better? edit: or maybe the other way around (or both) Have a great day.
  21. Embassy of Time

    When code just isn't enough...

    Oh no, I meant "look at the resulting game and say what you would add" or something like that. My code is never pretty enough for outside viewing!
  22. r1ckparker

    Controlled Randomness

    You probably want a bit of randomness in your game, for example when enemies shoot a bullet or how long an explosion lasts. However sometimes you want it to be the same every game, so the player will know that an enemy will enter the stage and always shoot a bullet. You want some randomness, but consistent randomness so it is the same every time. "When replaying levels, enemies always appear in the same location and follow the same behavioral patterns" One way to do this is to have an array and load this with pre-calculated random numbers. When your game needs a number, call the next one off the stack and loop back to the top when you have run out. One cool thing you can do with this is save a replay. If you capture the player's inputs each tick, then in theory everything in the game should play out the same way. You could use this for demo mode or as a save feature.
  23. The information is stored here, but in a nutshell I am looking to work with a programmer to develop a voxel engine ( Nice chunk of this done !) and help with gameplay using unreal engine.
  24. Gnollrunner

    Vulkan? OpenGL? What........?

    From what I understand (and I may be wrong) only the Start Citizen modified version of CryEngine supports this and of course that's proprietary. I checked into Lumberyard before and I saw some banter about it but nothing that said it was implemented yet. In fact just about every major engine has some forum posts where a few people have asked for it. The only one which defiantly has it that I found is UNIGINE and that's kind of pricey. I guess you might be right. It's better to defer this stuff until later.
  25. Irlan Robson

    Points constraint approach

    Here is a summary of three approaches that can be used for hair/rope simulation: - Mass-spring System: Here particles are connected via linear springs. Equation of motion can be solved using an implicit integrator to support large time steps and avoid instability. This is typically used for cloth simulation in movies and some games (LucasArts, Blender, Pixar). - Position Based Dynamics: Kind of what you're using and commonly used in games. Fast but as an iterative solver, constraints can break. - Featherstone: Fast and supports any time step. Large velocities may lead to instability and blow up the simulation. Can be used for simulating inextensible hair. Featherstone is a single step approach. It works in reduced coordinates. Constraints are always satisfied. However, large time steps might lead to instabilities, but we can add damping to improve stability.
  1. Load more activity
  • 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!