| Things I wish someone told me when I started working on my game Posted: 16 Apr 2020 12:36 AM PDT Hey gamedevs! Over the past two years I was building a side passion project - a game that I released on Steam a couple of months ago. I made a lot of mistakes throughout the development process, and I was keeping a list of notes for my "past self". This list may not apply to your game in particular, or to your engine / language (I was using Unity / C#), but I believe someone could find a thing or two in here that will help them out, so I am going to share it. Things I wish someone told me when I started working on my game. - Making a complex, polished game that is worth releasing and has even a slight chance of success will be 100x more difficult than you have ever imagined. I cannot overemphasize this.
- Use the correct unit scale right from the start, especially if you have physics in the game. In Unity, 1 unit = 1 meter. Failing to set the correct scale will make your physics weird.
- Sprites should be made and imported with consistent size / DPI / PPU
- Make sure that sprites are either POT, or pack them into atlasses
- Enable crunch compression on all the sprites you can (POT + crunch can easily turn 1.3Mb into 20Kb)
- Build your UI from reusable components
- Name your reusable UI components consistently so they are easy to find
- Have a style guide document early on
- Use namespaces in C# and split your code into assemblies early on. This enforces more cleanly separated architecture and reduces compile times in the long run.
- Never use magic strings or even string constants. If you are typing strings into Unity Editor serialized fields that are later going to be used for an identifier somewhere, stop. Use enums.
- Find big chunks of uninterrupted time for your game. 2 hours is way more productive than 4 separate 30 minute sessions
- Design should not be part of a prototype. Don't try to make it look pretty, you will have to throw it away anyway.
- Don't waste time on making "developer art" (unless your goal is to learn how to make good art). If you know it will still look like crap no matter how hard you try, focus on what you know better instead, you'll commision the art later, or find someone who will join the team and fix it for you.
- Avoid public static in C#.
- Try doing less OOP, especially if you're not too good at it. Keep things isolated. Have less state. Exchange data, not objects with states and hierarchies.
- Avoid big classes and methods at any cost. Split by responsibilities, and do it early. 300 lines is most likely too much for a class, 30 lines is surely too much for a single method. Split split split.
- Organize artwork in the same way you organize code. It has to be clearly and logically separated, namespaced, and have a naming convention.
- Don't just copy and slightly modify code from your other games, build yourself a shared library of atomic things that can later be used in your other games
- If you use ScriptableObjects, they can be easily serialized to JSON. This is useful for enabling modding.
- Think about modding early on. Lay out the initial game's hard architecture in a way that you can build your core game as a mod or set of mods yourself. Game content should be "soft" architecture, it should be easily modifiable and pluggable.
- If you plan to have online multiplayer, start building the game with it from day 1. Depending on the type of game and your code, bolting multiplayer on top of a nearly finished project will be ranging from extra hard to nearly impossible.
- Do not offer early unfinished versions of your game to streamers and content creators. Those videos of your shitty looking content lacking game will haunt you for a very long time.
- Grow a community on Discord and Reddit
- Make builds for all OS (Win, Linux, Mac) and upload to Steam a single click operation. You can build for Linux and Mac from Windows with Unity.
- Stop playtesting your game after every change, or delivering builds with game breaking bugs to your community. Write Unity playmode tests, and integration tests. Tests can play your game at 100x speed and catch crashes and errors while you focus on more important stuff.
- Name your GameObjects in the same way you name your MonoBehaviour classes. Or at least make a consistent naming convention, so it will be trivial to find a game object by the behaviour class name. Yes, you can use the search too, but a well named game object hierarchy is much better. You can rename game objects at runtime from scripts too, and you should, if you instantiate prefabs.
- Build yourself a solid UI system upfront, and then use it to build the whole game. Making a solid, flexible UI is hard.
- Never wire your UI buttons through Unity Editor, use onClick.AddListener from code instead.
- Try to have as much as possible defined in code, rather than relying on Unity Editor and it's scene or prefab serialization. When you'll need to refactor something, having a lot of stuff wired in unity YAML files will make you have a bad time. Use the editor to quickly find a good set of values in runtime, then put it down to code and remove [SerializeField].
- Don't use public variables, if you need to expose a private variable to Unity Editor, use [SerializeField]
- Be super consistent about naming and organizing code
- Don't cut corners or make compromises on the most important and most difficult parts of your game - core mechanics, procedural generation, player input (if it's complex), etc. You will regret it later. By cutting corners I mean getting sloppy with code, copy-pasting some stuff a few times, writing a long method with a lot of if statements, etc. All this will bite back hard when you will have to refactor, and you either will refactor or waste time every time you want to change something in your own mess.
- Think very carefully before setting a final name for your game. Sleep on it for a week or two. Renaming it later can easily become a total nightmare.
- Name your project in a generic prototype codename way early on. Don't start with naming it, buying domains, setting up accounts, buying out Steam app, etc. All this can be done way later.
- When doing procedural generation, visualize every single step of the generation process, to understand and verify it. If you will make assumptions about how any of the steps goes, bugs and mistakes in those generation steps will mess everything up, and it will be a nightmare to debug without visualization.
- Set default and fallback TextMeshPro fonts early on
- Don't use iTween. Use LeanTween or some other performant solution.
- Avoid Unity 2D physics even for 2D games. Build it with 3D, you'll get a multi threaded Nvidia Physx instead of much less performant Box2D
- Use Debug.Break() to catch weird states and analyze them. Works very well in combination with tests. There is also "Error Pause" in Console which does that on errors.
- Make builds as fast as possible. Invest some time to understand where your builds are bottlenecking, and you'll save yourself a lot of time in the long run. For example, you don't need to compile 32K shader variants on every build. Use preloaded shaders to get a significant speedup (Edit > Project Settings > Graphics > Shader Loading)
- Make all your UI elements into prefabs. It has some quirks, like messed up order with LayoutGroup, but there are workarounds.
- Avoid LayoutGroup and anything that triggers Canvas rebuild, especially in the Update method, especially if you are planning to port your game to consoles.
- Nested Prefabs rock!
- Start building your game with the latest beta version of Unity. By the time you'll be finished, that beta will be stable and outdated.
- Always try to use the latest stable Unity when late in your project.
- Asset Store Assets should be called Liabilities. The less you are using, the less problems you will have.
- Make extensive use of Unity Crash Reporting. You don't have to ask people to send you logs when something bad happens. Just ask for their OS / Graphics card model, and find the crash reports with logs in the online dashboard.
- Bump your app version every time you make a build. It should be done automatically. Very useful when combined with Unity Crash Reporting, because you will know if your newer builds get old issues that you think you fixed, etc. And when something comes from an old version, you'll know it's not your paying users, but a pirate with an old copy of the game. If you never bump your version, it will be a nightmare to track.
- Fancy dynamic UI is not worth it. Make UI simple, and simple to build. It should be controller friendly. Never use diagonal layouts unless you want to go through the world of pain.
- If you're building a game where AI will be using PID controller based input (virtual joystick), first nail your handling and controls, and only then start working on AI, or you will have to rewrite it every time your game physics / handling changes.
- Use a code editor that shows references on classes, variables and methods. Visual Studio Code is great, it does that, and this particular feature is crucial for navigating your game code when it grows larger.
- A lot of example code that can be found online is absolutely horrible. It can be rewritten to be way shorter and / or more performant. A notable example - Steamworks.NET
- Uncaught exceptions inside Unity coroutines lead to crashes that are impossible to debug. Everything that runs in a coroutine has to be absolutely bullet proof. If some reference can be null, check for it, etc. And you cannot use try / catch around anything that has a yield, so think carefully. Split coroutines into sub-methods, handle exceptions there.
- Build yourself a coroutine management system. You should be able to know what coroutines are currently running, for how long, etc.
- Build a photo mode into your game early on. You'll then be able to make gifs, nice screenshots and trailer material with ease.
- Build yourself a developer console very early on. Trying things out quickly without having to build a throwaway UI is fantastic. And later your players can use the console for modding / cheats / etc.
- Don't rely on PlayerPrefs. Serialize your game config with all the tunable stuff into a plain text format.
- Never test more than 1 change at a time.
- Do not get up at 4AM to find time for making your game. Do not crunch. Have some days off. Exercise. Eat well (maximize protein intake, avoid carbs + fat combo, it's the worst). Don't kill yourself to make a game. Have a life outside your passion.
- Unless you are a celebrity with >10k followers already, spamming about your game on Twitter will be a lost cause. #gamedev tag moves at a few posts per second, and most likely nobody will care about your game or what you recently did. Focus on building a better game instead.
submitted by /u/spajus [link] [comments] |
| Breast Physics in Motionbuilder (Simple & Effective) Posted: 15 Apr 2020 11:42 PM PDT |
| My Indie Game Was Featured as Latest News on IGN Posted: 15 Apr 2020 04:42 PM PDT I was shocked to see Boot Hill Bounties on the front page of IGN today. I'm overwhelmed and grateful for the indie community and everyone who helped me. But I also feel guilty because I know there are many, many indie game projects that deserve attention as well. So I thought this would be a good opportunity to pay it forward by sharing any insight I can about some things I've learned along the way as an indie developer. They say don't make your dream game as your first project, but there is a loophole. Don't make your dream game as your first project, but do make part of it. Take a small part or element of your dream project idea and turn that into a game. For example, if you want to make an MMORPG with a thousand quests and enemies and minigames, you shouldn't start with that. But what if one of those minigames is fishing. Okay, just make the fishing and turn that piece into its own game. This way you get some experience, a finished game, and a piece of your dream project completed all at the same time. And most of all you're still working towards the idea that has you excited so you stay motivated. Find a pipeline for QA testing. Don't trust yourself to find all the bugs in your game, you already know how to play your own game and may subconsciously avoid trying certain things. Most of the negative reviews for my games are from releasing them with too many bugs. The bugs can be fixed, but the reviews are going to stay forever. Additionally, have a list of things that must be checked in a game after every change post release. No matter how tedious or how certain you are that it's all going to work. Many times have I created a new bug while fixing or tweaking something else. On Steam, this isn't such a problem because it's easy to update. But on a console platform like Switch you don't have as much freedom to update. Learn how to take criticism. Opinions are subjective, but players are never wrong about how something in a game makes them feel. Period. But also not period because I'm going to elaborate. For example, if a player says that something in the game was frustrating - they may be wrong about what is making them feel frustrated, and they may be wrong about how they think it should be fixed. But they're never wrong about having a feeling. It's technically impossible. So if you get feedback that something is frustrating or confusing, you don't need to just change it the way they suggest it be changed, but you do need to address it and determine the real cause. It's more important that visuals stand out rather than be high quality photorealistic. I know I didn't follow this one because the visuals in my games are not very original - something I would like to change in future games. But since there's so many games coming out, I think having something that's visually distinct is just as, if not more, important than quality. Quality is in high supply, originality and excellent art direction is not. For example, look at a game like Minit. I think it's simplistic art direction makes it stand out to its benefit. All this might just be my own personal preferences though. Don't expect anyone to get your elevator pitch. Some game concepts sound great in a short pitch but some of the best games ever probably don't. Only the developer has the full vision in their head and we can overestimate others' ability to get it with just words. I've often heard devs say they feel a bit deflated after telling someone else their killer idea. Don't let that disway you, it still might be a great idea - just poorly presented. If you really want someone to understand your idea then at least try to create some mock up art. Set clear expectations when working with a team. I didn't work with a team but I have seen teams fall apart for usually the same reason. Everyone on a team cares about the project, but some will care more than others. It's actually not possible for every member to care the exact same amount and no one should expect this. It doesn't mean those who care less are bad or anything, this is just always going to be the case. But what often eventually happens is the team members who care more will grow resentful that they are caring and doing more than the team members who do not care as much. Then infighting starts and teams fall apart. So you need to have expectations under control and a plan for avoiding this resentment. submitted by /u/DapperDaveW [link] [comments] |
| Graphics mistake = RAINBOW LASERS Posted: 16 Apr 2020 09:32 AM PDT |
| Cave of The Dead - New indie game for SteamVR Posted: 16 Apr 2020 11:38 AM PDT Hello everyone, I'm an indie game developer and I've been wanting to get into the VR scene for some time now, I finally did and this is my first creation, it's currently in alpha stage and more features will be added (like in-game rewards & leaderboards)! What do you all think? :) https://youtu.be/iMymTgDXaWs submitted by /u/EGYbkgo9449 [link] [comments] |
| How Obsidian Designed The Outer Worlds' Quests Posted: 16 Apr 2020 06:05 AM PDT |
| Is it possible to make a high res asset that can both be for print and use in game? Posted: 16 Apr 2020 11:01 AM PDT This may be a simple question but I'm not finding a direct answer anywhere. I am working on a game outside of the pixel art scope for the first time and really trying to make sure I do this resolution stuff right. So far what I've learned is that 300 DPI is best for print, but 72 DPI is fine for game assets. I want to be able to print some assets if I ever need them for a convention/flyers etc but with the larger I size assets won't that mean the more I'll have to shrink the image in game allowing allow of the details to compact and look jagged or off? What is the best way to approach this? If the images are done in illustrator would this help? Also, 72 DPI or 300 DPI? submitted by /u/chibi_tris [link] [comments] |
| Publishing on Steam Posted: 16 Apr 2020 08:32 AM PDT It's been a couple years in dev, but I'll be finally releasing Angle Wars on Steam in a few months (don't think I'm allowed to post a link to the store page). I'm wondering, for those who have already released something on Steam...is it worth doing trading cards/achievements, from a sales perspective? All my spare time has gone into play testing and polishing, but as I'm getting closer, I'm wondering if I shouldn't be overlooking at least achievements. Have you found that people really care about those any more? As a gamer, I always found it slightly amusing/satisfying when an achievement would pop up, but it never would have influenced whether I bought a game or not, or how good I thought the game was. Thanks! submitted by /u/digitalpesto [link] [comments] |
| 7 Strategies for Increasing Game App Revenue, Engagement, and More Posted: 16 Apr 2020 07:57 AM PDT |
| Depth Vs Complexity - Game Design Theory @Game Dev Underground Posted: 16 Apr 2020 11:55 AM PDT |
| I want to make a game and my main reason for doing so is the story. Should I just make it a visual novel. Posted: 16 Apr 2020 11:40 AM PDT The title pretty much explains it. I have an idea of a game I want to make based opon my struggles to find myself in life as a 17 year old at the moment. I was thinking of making it an RPG, but Since the story is the main focus, I worry that it wouldn't be any good in terms of being an Rpg, so should I just make it a visual novel? Mind, it's just a pipe dream at the moment, I would make it by myself, but I still have to improve at drawing, coding and start getting in making music before that happens. Thank you for taking the time to read this and please tell me whatr you think. submitted by /u/5ashll [link] [comments] |
| I am making my own Star Wars VR game Posted: 16 Apr 2020 11:39 AM PDT |
| 'Fire' equals will to develop my first game! Posted: 16 Apr 2020 11:36 AM PDT Got a game idea! Pretty new on gamedev but i'm learning each day (UE4) i'm developing animations using assets that ive also created, wondering if its possible to export them back to UE4 and somehow use the FPS mode to trigger them as i pick them assets around my environment! Any comments? Here's a sample! Thank you, be safe! https://reddit.com/link/g2kq4t/video/l7720cvz48t41/player submitted by /u/tulextreme [link] [comments] |
| Looking for help / advice Posted: 16 Apr 2020 11:34 AM PDT I have been wanting to learn game design and developing for quite some time now and have found that to be rather difficult with a potato PC. After some research i have found the parts I would need to build a budget PC powerful enough to smoothly run the programs I need. Priced at around $500, which since I live in South Africa comes to R10 000 (a lot). I now find myself lost and unsure of how to make the money so I can continue my path to hopefully achieving my goals one day. So here I am asking you for help, to offer me any idea that could potentially help me to work towards acquiring the equipment I need. Leave your ideas in the comments, I'll be trying everything that looks promising and will share the results. submitted by /u/Phanamatic [link] [comments] |
| European Games BizDev Gathering - event for all european dev studios to meet publisher and investors Posted: 16 Apr 2020 10:26 AM PDT 13/14th of may here is the link: https://www.egbg.eu/ fee for devs is 35€ + tax. its for the community. hosted by EGDF (meta organisation for many european game associations lobbying for the industry). there is already quite many publishers and investors confirmed and registration started yesterday. submitted by /u/vane303 [link] [comments] |
| racing game starter library and editor (work in progress) Posted: 16 Apr 2020 10:17 AM PDT |
| Here is Part six of my new beginner tutorial for a small 2D platformer in Unity. In this Part, i will show you, how you can implement multiple jumps like double or triple jumps. Posted: 16 Apr 2020 09:45 AM PDT |
| Tutorial for PGMMV engine - How to Make Floating Platforms Posted: 16 Apr 2020 07:24 AM PDT |
| My first attempt at Pathfinding Posted: 16 Apr 2020 03:13 AM PDT |
| We're building PROJECT SHARES, a collaborative platform where everyone earns a fair share. Every time you contribute to a project you earn shares. And every dollar the project earns is split among all shareholders. Posted: 16 Apr 2020 03:04 AM PDT |
| Unity Set Text On Button Click Event in C# Script Posted: 16 Apr 2020 06:26 AM PDT |
| Desolate City: The Bloody Dawn (Enhanced Edition) Posted: 16 Apr 2020 06:16 AM PDT |
| GameDev Stream Hangout w/ Roman Papush (16/4/2020) Posted: 16 Apr 2020 05:54 AM PDT |
![[link]](https://i.redd.it/gk8d7gfpl4t41.gif){kind=link}
![[link]](https://i.redd.it/tfgnkphdn5t41.gif){kind=link}
No comments:
Post a Comment