Jump to content
  • Advertisement


The search index is currently processing. Leaderboard results may not be complete.

Popular Content

Showing content with the highest reputation since 10/11/19 in all areas

  1. 4 points
    (I have been asked about my limited writing here, and the reason is simple: My dad died in February, only a week before my birthday, and I have been... 'less' ever since. Hopefully, I am now getting back into some level action now. Hope my content will start to interest people again!) I have a problem. In fact, I have a *cluster* of related problems. One is perfectionism, in that I hate publishing anything as finished unless it lives up to some ridiculously high standards. Another is that I cannot work on something without getting an avalanche of constant ideas that could improve it. Those two sort of play off each other, driving me insane with anything that I am the sole authority over. Most people likely recognize this; it is the bane of many creatives. I am trying to solve this problem these days. I recently got back into writing the final draft of the first Embassy of Time book(s), and I have accepted that I need a new kind of structure. I'll leave the writing structure to my Tumblr blog and the like (social media is still chaos to me), but I found a way I might break the back of the problems I have with developing games. I call it Play From Zero. Think of any game you would like to develop, but have not yet started work on. Imagine a line going from 0 to 1, from nothing to a complete product. This is my and anyone's usual view of it. Finish the product, then publish. Maybe a WIP / Early / Alpha version on the way, but those are just 'test versions', not something 'complete'. What if the developer cut that imaginary line into microscopic pieces? What if every bit of programming had to leave a complete product? I'm not saying you should have complete AAA games done in a few hours. Instead, everything you do should make a small, but worthwhile, change in your game. After a 5 hour programming session, you have a tiny, simple game. After the next 6 or 7 hour session, that game has a new feature. It's not a WIP, it's a better game, fully playable. Complexity is built along the way, as tiny 'micro-features' stack up. Of course, you can plan a complex product in advance, but whenever you actually do anything, you're aiming for a tiny, but worthwhile, expansion on your game. You need to finish the game every time you work on it. There is no "this will be cool when I finish it... some day"! It's a thought. I have not yet started down this path, because I need to focus on some writing and animation first and foremost. I have pulled together enough money to dedicate 2020 to my work on The Embassy, and I need to plan more strictly than ever before to make the most of it. That means spreading myself less. But I hope to soon starting my first Play From Zero project, and hope a few in here will pay interest and give me some good, honest feedback on not just the game at any stage, but the idea of a growing, organic, and most of all playable product. Does this make sense? Tell me in the comments!
  2. 3 points
    Currently, the only "playable" level is still full of placeholders - I'm still hoping for having the game finished on 18th, but we will see. In worst case - there might be some place holders left (while the game would still be playable). In the meanwhile I have added: Full physics (based on Bullet), not just character controllers, but even rigid bodies are technically supported (I'm still not sure whether I will do anything with them) Ability to control behavior of entities (doors, elevators and such are possible - but I don't think I will have enough time to make art for those, so we might be limited here) Improved the speed of dynamic BVH building by about factor of 10+ (by simply going through my code and removing dumb things) Get rid of most of the limitations (like total texture size was originally limited to just 8192x8192 texels, technically this is much higher now) Finished some sort of player movement I'm kind of satisfied with I'm realistic, the competition ends in about 2 days (and as most of us - I still have to be at work during those). I personally will be glad if I manage to make the scope I wanted for proof of concept demo - that includes: Simple menu (New Game/Exit) Single level Single type of enemy Single weapon Player can die in the game and player can win the game Some sort of Doom-ish UI Some advanced ray tracing effect or two I know this isn't much (and is most likely barely covering the scope for the challenge). In the meanwhile - behold - the placeholders (and no that 0.44 GRay/s is not joking - I'm currently limited by performance of actually displaying the buffer, not ray tracing nor BVH updates at all)!
  3. 2 points
    I have estimated that I will not be able to finish this challenge in time. I have started it too late and without a clear direction from the beginning. I managed to finish the necromancer character, the AI and most of the map. But I had some problems with projectiles going through walls and sometimes going in weird directions without any kind of apparent reason why. I have decided not to release the game as it is because it has some broken gameplay mechanics and I'd rather not release the game like this. I might continue working on it when I have more time and not be busy with other things as well. Well, it was fun anyway and congrats to the community members who succeeded in this challenge! Cheers.
  4. 2 points
    Hello, I am alive. I've actually been split between projects, and I have been a little burnt out, but I am back. I decided to not force the player to only have one colony. So that means we need a solar system. In the original game, there was a squad grid that you could choose where to build colonies, and only on specific slots. However, I wanted something a little more modern. A solar system with a hex grid surrounding the planets, and you could choose from orbit where to pick. I've spent probably two weeks researching rotation and procedural planets. Shout out to Sebastian Lague and his amazing tutorial on Procedural planets on youtube that I used as a base. I couldn't find any tutorials on grids and rotating a planet, so I've had to spend the past two weeks with trial and error to figure this out, but I've finally done it. And it rotates! So if I click on a hex, it spins the planet to face the camera onto the hex I clicked on. Next step: Make the grids transparent, add some UI to pop up when a hex is clicked, have grid coordinates appear for the hexes, and start building a solar system to explore.
  5. 1 point
    Hello and welcome to this weeks dev diary! Today I'll show a couple of ways to slice up your images into smaller portions, one that doesn't require any plugins and one that need you to download a script. The following tutorial uses the default settings for GIMP, just like a fresh installation with no previous installations that might have retained some of your old settings. The GIMP Version is 2.10.12 The Manual Way Slicing the image manually can be really work intensive, depending how many parts you want to slice your image to and is by no means an efficient way to do it, but will suffice for anyone who wishes to divide their image to 4 x 4 tiles or less. 1. When you have loaded up the image you want to slice into smaller pieces, go to image > Guides > New Guide... 2.a When you click on the "New Guide..." the following box appears. 2.b Now you have to do some math and divide your image into as many parts as you want. You have to do this both horizontally and vertically as many times as you need guides. For this tutorial I'll make the image into 4 x 4 tiles, meaning 3000x3000 pixels in size, as per 12000 / 4 = 3000 - this means that I need to space all the guides 3000 pixels apart from each other, adding 3000 to each position. i.e. the first guide to 3000, the second guide to 6000, and the third guide to 9000. 3. After you have added your guides, your image should look like this; 4. Go to Image > Slice Using Guides - Click it and GIMP will divide the image for you into separate images and switch your view to the last piece. The original image will still be intact. GIMP will use the same filename that your original file has, but add to the row and column number to the end of the name, like seen in the above image filename, on the top right corner. Original filename in this example is; M5213A-texture-12000x12000.png The last piece has an addition at the end of it; M5213A-texture-12000x12000-3-3.png The below image showcases how GIMP organizes the tiles. First number represents the Column and the second number represents the Row; 5. Save each image separately, by going to File > Export As... (or using shortcut of Shift + CTRL + E). The file extension is the same as the original file's, so no need to change any setting when saving the files. The default export path is the one that the original image resides in, so you may want to create a new folder for the image slices. There is also several plugins that helps with saving multiple tabs in GIMP. The Much More Automated Method 1. First, download these plug-ins; ofn-layer-tiles Export Layer 2. Install both plugins into C:\Users\"Your-Username"\AppData\Roaming\GIMP\2.10\plug-ins Note that the "2.10" folder is the version of the GIMP you have installed and will change after each update that changes the first or second version number. Now your plug-ins folder should have these files. 3. After opening GIMP and your image file, remove the ".png" from your layer name. This will ensure that the "Export Layers" plugin names the layers correctly. 4. Go to Layers > Tiles > Split tiles (by rows and columns)... 5. Choose how many rows and columns you want, no need to change other settings, unless you want to specify different naming schemes. Read the plugin instructions for more information on that. For the purpose of this tutorial, I will be splitting the image into 4 x 4 tiles, just like before. By default, the slicing process named the files with the same logic as GIMP, the first number represent the Column and the second one is the ROW. The only difference is, that the plugin starts the numbering from 01 instead of 00, that GIMP starts from. This can be changed in the settings how ever, if this is important to you. To make the numbering start from 0, change "{column1:02d}-{row1:02d}" to "{column0:02d}-{row0:02d}". 6. Press the "OK" button and the plugin will change the image into separate layers. 7. Go to File > Export Layers... Choose the folder you would like to save the images to and your preferred file format. After you are done, click "Export". The Plugin will save each layer as a file and depending on the size of your original file, this could take some time. Conclusion For my needs, these plug-ins are gems. I'm just surprised how come GIMP does not include these kind of functionalities out of the box. But then again, open source programs tend to rely more on community to add more functionality to the core program in the form of plug-ins and scripts. One thing that should be a out-of-the-boc functionality, is the "Save All" option for saving all open documents easily and fast. Hope this was of use to you 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 •
  6. 1 point
    A number of years ago, I had the opportunity to work on a trailer with a very established music producer. To give you an idea: he had recently finished contributing to a Rihanna album. I was ecstatic for the opportunity. I get to work with and learn from this guy?! YASS! We listened through the music track I had written and he began picking out potential improvements with the arrangement, mix, production, etc. I scribbled down everything I could, taking no offense whatsoever. I mean, who was I to question what he was telling me? We talked for a bit - I had some questions on how to tackle some of the issues he brought up. The session ended with me having some serious homework. But I was STOKED! I spent five days moving things around, changing settings, making small tweaks. This was me giving my all. I wanted to impress him SO much. By the time we met next, I couldn't think/hear of any way I could do better. The next step was to watch his face light up when he heard how good I was. Right? We pushed play and he seemed to like it. He listened all the way through without stopping and even had a positive look on his face. Not the utterly enthusiastic reaction I was looking for, but hey, he was kind of a quirky personality. When it ended, we sat in silence for a few seconds before I asked "what do you think?" "B+" B+?! Hey! That's not bad! I mean, if he's saying B+, then for most people it's really good! Maybe a few small tweaks and we're good to go. For a second there, I was SO HAPPY! Then he says, "Unfortunately, we're in a business where it's either A+ or F." He then proceeded to list off even more homework than he had given the last time we met. It was a bit devastating - I felt like I had given 110%. And it definitely seemed like I hadn't impressed him. It’s moments like this that can crush your spirit and make you feel like giving up on a piece of creative work. While in the short term that experience stung, I realized criticism is actually an opportunity and encouraging, though it can be perceived very differently for any creative artist than for most other professions. For many amateur artists, to criticize their work is not criticizing a thing they did, it is criticizing an intrinsic part of themselves. There's a lot to unpack here. First, it's important for an artist to realize the criticism is not about direct attacks on their self-worth. The issue is how criticism is expressed so that it aids communication, the experimentation process, or it's execution - not a personal, intimate artistic failure. As a creative whenever you put a piece of work forward people will have opinions about it. It will naturally feel like they are attacking your level of skill. You must develop a thicker skin. Second, the fact that someone is criticizing your work means they think it's worth having a potentially uncomfortable conversation about. Not only that, they think you're worth having that conversation with. Think about it - we all have people in our lives who we've kinda given up on. - They always talk about the things they're going to do but never actually attempt them. - Everything is someone else's fault - not theirs. - Their idea is so bad that you can't even begin to determine how to communicate everything that's wrong with it. At a certain point, we stop caring. We stop saying "I don't know if that's a good idea.." We stop pointing out what doesn't work or what does. We stop expecting them to follow through. Ultimately, we stop taking them seriously. To that end, we stop objecting. We stop trying. We stop criticizing - because we feel the idea is so terrible, or the person won't or can't act upon our input. So why try to help? If someone criticizes your work, it means they think the potential of your idea is worth being uncomfortable about. It means they think that if they tell you their thoughts, you'll understand them and are capable of implementing them. Criticism means someone thinks you and your idea are worth helping. It means they think you and your ideas have value and can be better than they currently are. While my additional homework from the producer was initially disappointing, it also meant we were making progress. My music was worth working on and I was worth talking to. It took a while, but we ended up with one of the best overall tracks I've made. Those sessions became a learning experience in craft and in self. Be happy if someone is willing to tell you that something isn't A+ and why. Welcome it. Embrace the criticism! Be sure to check out Unlock Audio and grab some free stuff. Want to reach out? hello@unlockaudio.com Elliot Callighan is a composer and sound designer, and the owner of Unlock Audio. He also teaches in the film and game programs at DePaul University and is an Officer in the Army National Guard.
  7. 1 point
    Good day to you! Welcome to this new Weekly Updates blog entry! Last week was, overall, pretty packed. After a short strategy time, I managed to come up with a plan that I think will be more impactful than before. So without any further ados let's get this thing started, shall we? Platforming The main theme of this Weekly Updates post is probably platforming. Players could always jump but, so far, these were mostly used as a defensive technique. These were really helpful for range players but literally useless to everybody else... To fix this, I decided to sprinkle the levels with a bit of platforming. Basically, some tunnel rooms will now spawn stairs. These will, in turn, lead to platforming challenges that'll reward players with good-old-fashioned loots. Similarly, I'm also planning to have hidden shortcuts scattered around too. The idea is that some normal rooms will contain super secret stairs under breakable props that will allow the player to skip some rooms. The difference here is that instead of loots these will open up to an exit. Platforming Challenges Each platform challenge will be created by hand. To spice it all up, there'll be level-specific challenges as well as generic ones. When generating the level, those challenges will be randomly picked. Some challenges can also include a puzzle to solve. These challenges will be composed of several platforming elements. The idea is above all to offer a lot of diversity and to propose several unique challenges while simplifying their conception. Let's take a look: Moving Platforms First, let's look at moving platforms. These types of platforms move along a predetermined path. Most of the time, this type of platform moves linearly from one point to another. Players can, with good timing, jump on it to enjoy a free ride. At any time, players can land from them by jumping or simply dropping them. Some platforms will move rather in a cyclical movement (for example, making circles or following a predetermined circuit). Players must, therefore, time themselves correctly and use these platforms to their advantage. Rotating Platforms Secondly, there is another type of platform not very different from the previous one: the rotating platform. Basically, they are functionally identical to moving platforms. They too allow players to enjoy a free trip. However, unlike mobile platforms, they rotate rather than move. Some turn on themselves and others turn on different axes. They can also rotate at different speeds. Therefore, players must again use timing while dealing with them. Ladders Finally, here is the last one: the ladder. Ladders are, like in real life, practical tools for reaching things that are normally too high to access. In the game, players can climb ladders by simply approaching them. Once mounted, players can now move both vertically and horizontally on the ladder. Players will automatically dismount the ladder once they reach any of its extremities. To rapidly drop from a ladder, players can press the jump key. This pushes players off the ladder. Since the game takes a first-person perspective, ladders behave almost identically to those found in Source Engine games (Half-Life, Counter-Strike, etc.). Thus, players are free to look anywhere they want while still being able to freely use any ladder. That's about it for platform challenges. Here's a video showcasing a placeholder simple platform challenge: Puzzles Secondly, I've managed to refine puzzles and add a new puzzle piece. There are still two types of puzzle pieces but now there a new sub-type of the pressure plate. Now there are two types of pressure plates: round ones and square ones. The idea is to have two distinctly different models for two different types of pressure plates. The round pressure plate acts like your typical button. This means that once it's pressed down it stays down. The square one needs constant pressure to stay active. Usually, players can use some kind of weight (like a pushable block) to keep it on while solving other puzzles. Minor Updates Added some pressure plate animations and transitions Remapped puzzle pieces UV maps to use different tints Changed most puzzle pieces shader to offset UVs to vary the model's colours a bit. Next Week To be honest, here, I'm hoping to really get it going with platforming challenges and puzzles. I really want to get these things started and see where this will go. Aside from that, it's your usual suspects... Otherwise, I'm still constantly thinking about what to do next... It's been so long without any conceivable revenue and perhaps it's time to do something about it. What it is is still unsure. Perhaps it's to either create some kind of Kickstarter campaign or something alike... Perhaps it might even be taking a bit of work on the side to stay afloat. I really need to think about it because any false move could put the game in a bad position. I really believe in what I'm working on right now. It has a very unique approach to Vaporwave that I haven't seen a whole lot of. Usually, designers stick with either neon colours on a dark background or retro PSX aesthetics. However, I didn't see any love for Memphis Desing nor 90s design. This really makes me think that I'm on to something. But anyway, let's try to make it work in the first place!
  8. 1 point
    After more than 10 years as a Game Designer in very successful companies (Senior Game Designer at Matific, Lead Game Designer at TabTale, Owner at Lookandfeel Games), I had — and still have — the privilege and the opportunity to utilize data from hundreds of millions of users around the world. Now’s my time to share my knowledge with the world. For a long time, game designers utilized data through playtesting, usability sessions, data, and reports in order to ensure the best experience for their players — and their products. The great thing about working in big game companies is to have a dedicated data-analysis team to analyze the games’ data and tell me their pros and cons, including interesting insights and trends. Sorry to disappoint — your idea didn’t work. To disappoint? Hell no! Thanks for the opportunity to tell me I should rethink my design so I won’t continue to think that I nailed it, while in reality I didn’t. How can I improve otherwise? How can I gain mastery otherwise? Based on data-driven insights, good ideas are being duplicated and leveraged in my next projects, and the ‘trial balloons’ are being adjusted or dropped accordingly. Here’s my best practices bible with lessons learned from +250 games — proven by data to improve your monetization, retention, user experience & engagement. UI POSITIONS Speaking on mobile games, considering that most players are right-handed, the devices have comfort-to-reach area and hard-to-reach area depends on their orientation: Now take a look at the below examples from various mobile games: As you can see, in the most comfort-to-reach area, the best practice is to place interactive elements which can lead to monetization: Store button More apps Ads Users are likely to interact with these elements — unfortunately even by mistake. Those mistakes are what we call a dark-UX, but it’s proven to maximize revenues. Note that for bottom ads, you must include at least 10 pixels margin from the ad to the interactive content in order to follow ad-serving guidelines in most of the platforms. SLIDERS Because the screen’s real-estate is limited, and the content in games is just getting bigger, sliders become a very handy component to expose many options to the users regarding extra content, without the need to navigate away from the main scene. Here are five examples of different slider designs which offer horizontal or vertical sliding, used in world-selection, shop, landscape categories\items selection, portrait categories\items selection, and avatar customization: Because the slider’s content expands outside the screen, we need to help the users understand there’s more content inside. Here are the best practices for sliders: Partly visible items: Make sure that content which expands outside the screen’s border will still be partially visible on screen, so users will understand there’s more of it. Animate from end to start upon launch: When introducing the slider to the users, either by automatic event or by a user-initiated event, make sure to launch it on its end-of-content, and scroll-reverse automatically to the beginning of its content. If your slider contains lots of content (i.e. 10 steps to scroll from beginning to end), you can just start from “step three” of the slider and then animate scrolling to “step 1”. This will show the users that there’s more content on the other side. POP-UPS Pop-ups are a good game component for delivering abstract and informational messages to users. Here are some useful best-practices: Associate visible UI with hidden UI via animations: When pop-ups are opened due to user-initiated action on an interactive item\button, animate their launch from the triggering button (i.e. scale up a store-pop-up from the store-button, and scale down the store-pop-up back to the store button upon closing). This way users will associate the pop-ups with their initiators better. Have a semi-transparent dim background behind popups: Because they often require a user-action, and might be big in size on screen, we should help the users understand that their session is paused, but still reachable. Pop-ups should be seen over a dim background that will allow the users to see a bit of their session behind (the dim background should animate quick fade-in parallel to the pop-up open animation, and fade-out parallel to its closing animation). Avoid the X: Many pop-ups contain a default design choice of an “X” button to close them. Most users recognize this “X” button as a pattern of an ‘annoying’ content and closing the pop-up instantly. If your pop-up contains valuable content to the users, and you’d like to increase the probability that they’ll read this content, make sure that the “Close” button will be designed as one of the user’s choices and not as an “X” button. Note: Don’t have duplicate options with the same meaning (i.e. both “X” and “Close” in the same pop-up; users will just tap the “X”). Pro tip #1: Tapping the dim background should close the popup as if tapping “cancel”, unless it’s a store popup — then only closing via “X” will close the store. Pro tip #2: Popups with rich text (such as intro story popups) should show their “X” or “Continue” button only after 2 seconds delay. This way users will be more likely to read the important content of the pop-up rather then instantly close it. USER CHOICES (VIA POP-UPS) As I mentioned above, lots of pop-ups require user-action as they are offering the users to take a decision. Here are several examples of pop-ups which asks the users how to proceed — do you see a pattern? As you may see, the rule of thumb here is as follow: User decisions which are good for your game are placed on the right side of the popup — As a game designer you want your players to confirm a purchase, you want your players to share the game, you want your players to spend in-game currency… etc. : User decisions which are bad for your game are placed on the left side of the popup —As a game designer, you won’t want your players to quit the game, disconnect, reset progress… etc. : Although you might think that this is considered as a dark UX, it can actually help the users a lot — you don’t want your users to accidentally reset their progress, do you? Anyhow, the key here is to lead the users to take a decision you want, which is good for your game’s KPIs (IAP, retention, engagement, viral exposure, sharing and so on). Tip: Associate a button color with its function (negative is red, positive is green, neutral can be blue). REWARDED VIDEOS Rewarded-video ads become an industry standard in the past years, as part of a freemium model in mobile-games, which boost revenue and considered as a “win-win” situation (the users who cooperated with the offering to watch an ad, will receive an actual in-app reward in return). The best icon to represent rewarded video ads should look like a film clapper board with a play icon on it (we’ve tested lots of different icons and this one worked best). Here are several examples of rewarded video offering in different mobile games: As a game designer, you should think carefully what the prize is going to be, how to reward it and for ‘how long’. The main scenarios are: Permanent — Once the ad is watched, the users receive the prize for an unlimited time (i.e. get an item which is added to their inventory and stays there for good). Per Session — Once the ad is watched, the users receive the prize and it’s available to be used anytime during their current session. Once quitting the game and getting back on a later time — the prize is not there anymore. This can be helpful in order to increase session time. Per Scene — Once the ad is watched, the users receive the prize and it’s available to be used only at the current level (i.e. getting a booster, or ‘another try’). The rewarded video prizes should be significant and not ‘little things’ — otherwise, users won’t want to waste their time on the ad. As a game designer, you should think about what your users will want from your game. Pro tip: Don’t tell users what reward they’re getting, to make the reward more exciting (motivate their curiosity and surprise — and increase the probability that they will watch the ad). DRAGGABLE OBJECTS An intuitive game mechanic on mobile is ‘dragging an item’, though many times it can harm the game experience if not done right. When exporting game assets such as PNGs, the design can be very creative, while ‘behind the scenes’ of the device they are all rectangles with some transparent area. The default anchor points for rectangles are either the top left corner or the exact center. As a game designer, try to demonstrate how the object should be dragged as if dragging it in the real world — where the actual holding point of the item should be positioned for the user: Default anchors are often outside of the dragged object (top left corner). Even when centered, the dragging won’t make sense to the user most of the time. Here are important best practices for draggable objects: Set a custom anchor-point offset on draggable objects so the user’s finger will not hide them: Most of the times the default anchor points will have to be adjusted and get a custom offset so the draggable item will be visible despite the user’s finger on the screen. The grab area of small draggable items should be larger than their actual canvas size. The dragged item should be in front of other items when dragged (Z-index wise). In special cases (i.e. inserting an object inside another object) this should be customized. Use glow or dashed-outline for drop-zone areas. Don’t expect the user to understand immediately where the dragged item should go to. The best case is when having an intuitive ‘drop-zone’ (i.e. dragging a food item to a mouth) — in this case, no need to highlight the mouth, but just animate it ‘open wide’ when the food item is dragged. Users will know what to do. Pro tip: In general, pulling is easier than pushing (i.e., for right-handed users, dragging from left to right is easier than dragging from right to left ). If your game is designed for kids, try to have pulling over pushing by design. RATE US DIALOGS Lots of game designers are using the ‘rate us’ dialog too soon — calling the users to rate their experience before they actually formed an opinion about your game. When done right, using the ‘rate us’ dialog helps to achieve better ratings on the stores and helps organic promotion. So how to do it? The ‘rate us’ dialog should meet the user on the following scenarios: After a big achievement or big satisfaction point (i.e. defeating a boss, completing a world, winning a major challenge, etc.). After accumulating small satisfaction points (i.e. win 10 badges). To maximize the probability that users will rate your game, the ‘rate us’ dialog should be designed as follow: Have a relevant presenter, looking at the user. ”Rate button” should be with positive color (i.e. green) and more noticeable than the ‘later’ button. Also, if you followed the best practices mentioned in the ‘user decisions’ section above, you should know by now that its position should be on the right side. Tip: Never use “5 stars” reference — it’s against Apple’s guidelines. STORE DIALOG The design of your store dialog is critical to your selling. Many times the store dialog will offer some ‘full version’ deal along with some other in-app purchase options. Here are a few examples: To maximize the purchases of the full version, you can follow these guidelines: Make sure that the ‘full version’ button includes a presenter from the game, with noticeable eyes (preferably looking at the user). The ‘full version’ button should be stronger in color, larger and more attractive rather than the other in-app offerings. Add a ‘breathe’ animation to the full-version button(scaling up to 104%, then back to 100% two times, then stop for another 6 seconds before repeating the animation). The title of the full-version button should be bigger than its inline content. Have a clear “Discount” or “Best Deal” ribbon on the full-version button. Pro tip: If you are selling content such as extra levels, worlds, etc.., allow the users to enter the locked content screen and only then open the store dialog with a dim background behind it (rather than opening the store dialog ‘outside’ when clicking the locked content on the level-selection screen). WRAP-UP I’m glad to take the opportunity to share my knowledge with this community and I hope that this info will provide value to lots of game designers, game developers, and product owners. This best practices bible for game design UX is formed from big data (and I mean — BIG — TabTale alone has more than 2 billion downloads and ranked among the top 10 publishers in the world several years in a row), but I also watched it executed for real with more than 500 users (at Matific I have the privilege to watch more than 500 users play my games in large scale events by the Israeli Ministry of Education where kids from all around the country are competing in a yearly Math-Olympics session). One thing I’d like you to remember along the way is that these are not ‘rules’, these are best practices. I recommend you to adopt them in order to get a better starting point, but don’t expect them to magically turn your game into the next hit. Now you are ready! If you liked what you read please help me spread the word — it means a lot Amir Dori https://www.linkedin.com/in/amirdori Senior Game Designer at Matific (2016 to date) Lead Game Designer at TabTale (2013–2016) Owner at Lookandfeel Games (est. 2009) Lecturer at Mentor College (Metagame & Game Design course).
  9. 1 point
    If you love developing hard games but aren't a good player yourself, you have a challenge ahead. Unity Immediate Window: Sample Project Last week, while working on a game, I noticed that I could not beat my own levels anymore. I wanted to reach the final boss, so to speak, and that single thingy took me longer than I'd be happy to admit. It might be the age, or that the game is simply too hard. So I started looking for different ways to save time. As always, cheating was an option. I also thought of making a special, shorter version of my gameplay to avoid playing through the same hard spots every single time. After all, I just wanted to test the final boss! As you know, there are many ways of approaching this. But, in my case, I came up with an alternative approach that ended up being surprisingly useful. This strategy helped me shortening the testing times of my games plus cutting the design iteration times. If you are a programmer or designer, this article will give you insight into a second approach for handling these challenges. If you have any other role, well, share this article with the right person. To present the use case, I looked for an open-source game on GitHub. And so I found a cute little game called Popcorn that I borrowed from TheAislan (full credits to him!). It's a basic 2d platform game that features simple 2d physics mechanics, perfect for our use case. Check the screenshot above, isn't it adorable? I'll start off by telling you how I used to deal with testing... Level 1 Developer: The (Infamous) Grind Level 1 Unity Developer: The Grind A decade ago, grinding was my preferred way of working (oh dear). All the testing I did was manual, and it was all fun. Then, weeks passed and the game got more and more complex. I started growing frustrated, since now playing every time took me almost 20 minutes. Tweaking the final boss scene transformed from being a pleasant moment to sucking all my mana and burning the entire QA's yearly budget. Something had to be done, and so I searched for solutions. One workaround was to split each level in multiple, even finer sub-levels. That way, we could just load the specific sub-level we want to test. This solution might work well for games whose level areas are highly independent of each other, such as platform games. This has some overhead on the programmer when it comes to scene management, but it's quite alright. Another possibility is to add custom in-game panels or UI inspectors to enabling cheating and special actions. Those could allow the developer to skip certain parts, increase stats or just disable annoying ads. These work just well, but some time has to be spent on preparing and maintaining the front-end. And here comes the classic: a configuration file to be loaded in run-time. That sneaky file can be used to choose which features or cheats to enable. That may look like below: { "GodMode": true, "AllLevelsUnlocked": true, "Gold": 500, "SkipAds": true, "UnlimitedTime": true } You can load such a configuration file through a C# script like below: [Serializable] public class Cheats { public bool GodMode; public bool AllLevelsUnlocked; public int Gold; public bool UnlimitedTime; } var cheats = JsonUtility.FromJson(File.ReadAllText(Path.Combine(Application.persistentDataPath, "cheats.txt"))); player.Gold = cheats.Gold; Of course, make sure not to enable that feature in release versions These options have one common problem: we have to pre-define what is possible in advance. We get what we programmed; we don't get what we didn't. That can quickly become a time sink: During testing, we decide we need X. Therefore, we stop playing and wait for a programmer to implement X. We then replay till that point and perform X, only to realize we actually wanted to do Y. UPSET In some situations, we could clearly profit from having more flexibility. So I asked myself: can we do better? Link to the summary Level 2 Unity Developer: the Unity Immediate Window Package You and I want to shorten our iteration times. We want to avoid pressing the stop button as often as we can. What if we could invoke whichever behavior we wished for during run-time? How less frustrated would you be if you didn't have to start a new play iteration so often? We want to stop depending on pre-defined behavior. The bribery cookies we offer to our colleague the programmer are getting way too expensive. It's our lucky day. It turns out that Unity released a package called Immediate Window. That sneaky beast of a package gives you just that: it allows you to run your DIY C# code in run-time. This might sound a bit too abstract. The benefits might be hidden. But trust me on this: Unity Immediate Window will cut your iteration times SIGNIFICANTLY (if used correctly ™) Remember that I wanted some kind of fast-forward feature to reach the final boss faster? That's exactly what we're gonna do just now using Unity Immediate Window. What we are going to do is to implement Automated Playtests. In other words: in this blog post we are making the machine play for us. No more human mistakes made. And not only that, we wanted to save time, so we will do that at 2x the speed! Here comes a very quick section on how to install this Unity Immediate Window Package. If you're a pro, skip it. A. Unity Immediate Window Installation The first step is to add the Unity Immediate Window package from Window ► Package Manager. There, just search for Immediate Window and install it. I take you are using some sort of Version Control, so remember to keep track of the changes made in the Packages/manifest.json file. Level 2 Developer: Unity Immediate Window Installation Once installed, you can easily open your new Unity Immediate Window panel by navigating to Window ► Analysis ► Immediate Window. That's all to it, really. How do you feel about a quick guided tour on this new toy? Let's get started. B. Unity Immediate Window Overview Level 2 Developer: Unity Immediate Window Overview In the above capture, you see the main and only existing window in Unity Immediate. The pink-highlighted area is the input command window. This is your bread-and-butter section where you and I enter commands just like we would in a C# script. Only that we will do it in run-time (while playing in the editor). Note that the C# syntax has been slightly simplified; for instance, typing C.Player in this project will let you see the contents of that variable in the output log. No need for Log, no need for a semicolon. In the yellow section, we see what we call the object inspector section. Here, you'll be able to inspect the contents of in-game objects and variables. You may expand the JSON-like view by clicking the arrow located on the left, as seen below. Level 2 Developer: Unity Immediate Window - Object Inspection Finally, the blue highlighted area lists the registered assemblies. You might find it helpful to explore the available types, especially their static properties. An example is shown below, where we inspect the global gravity property. Level 2 Developer: Unity Immediate Window - Assembly Inspector C. Unity Immediate Window: The Art of Making Cheats Now that I gave you a brief theoretical grasp on the Unity Immediate Window, let's apply it to our case. This is based on the Unity Immediate Level 2 GitHub repository (see below) with Unity 2019.2.X. Download the project in ZIP format directly from GitHub Or alternatively, visit the GitHub Repository Coming back to our cutie, we wanted to be able to fast-forward to the final boss without dying in the process. So... If you cannot beat the house, do some sneaky cheating Here's my first suggestion for you: create a static class that wraps the functionality you want to invoke. That way, all developers have centralized access to all functionality and you don't have to memorize as much. Let me announce our lucky winner! It is... GamedevGuruHelpers.cs!!!! public static class C { public static Player Player { get { return Player.Instance;} } public static string GodMode { get { return string.Format($"Godmode: {Player.Instance.godMode = !Player.Instance.godMode}");} } public static float TimeScale { get { return Time.timeScale; } set { Time.timeScale = value; } } public static float Gravity { get { return Player.Instance.rb.gravityScale; } set { Player.Instance.rb.gravityScale = value; } } public static void Win() { Player.Instance.Win(); } } Is it redundant? Yes. Is it helpful? Yes. If you don't like it, don't keep it. Line 1 declares a static class with a mysterious name of C. This can be thought of Cheat, CVar (Console Variable), Cockatrice or whatever meaning you'd like to give it. A single letter keeps it easy for people to remember it. Lines 3-6 define a static shortcut property to allow quick inspection and acting on the Player class. As you saw in the previous images, we only had to type C.Player to inspect its contents. Lines 8-11 offer an interesting way of toggling the God Mode cheat on or off. Instead of typing C.GodMode = true, it'll be enough to type C.GodMode so switch between modes. This syntax is less verbose for the developers using the Unity Immediate Window. Lines 13-17 allows you to change the Time.timeScale of your game. This will become handy if you are doing automated tests or want to increase the speed of your iterations, as you will see later. The same is done for the global Gravity property. Lines 25-28 will give you the option to type C.Win() in the Unity Immediate Window to trigger an instant win in the scenario. Play the game. Open the Unity Immediate Window. Type any of the commands previously mentioned. Now you can beat any game Cheating alone will save you only so much time. You still have to play manually. And THAT SUCKS. Can we do better? Aw yes! Link to the summary D. Unity Immediate Window: The Art of Automating Playthroughs I initially confessed you the difficulty we had in repeatedly testing scenarios from start to finish. It was prone to errors, to game overs and we were spending way too much time. And yet, I have seen this so often in so many projects. Having a QA department is not an excuse for making their lives harder! I live in Amsterdam and I definitely tell you I've seen increased weed consumption as game levels increased in complexity. Avoid frustration from everyone and as often as you can The idea here is simple: we want the machine to play for us. The freed time can now be spent profiling (while playing), debugging or eating the bribery cookies artists and designers gave us. In this project, we have a limited amount of input: arrow keys and jump key. This will make things easier for us, programmers. We'll start by extending our well-named class C to add basic gameplay functionality to it: 𝓬𝓸𝓹𝔂 𝓪𝓷𝓭 𝓹𝓪𝓼𝓽𝓮 baby! public static class C { // ... public static Coroutine Execute(IEnumerator function) { return Player.Instance.StartCoroutine(function); } public static Coroutine Move(float direction, float duration) { return Player.Instance.StartCoroutine(Move_Internal(direction, duration)); } public static Coroutine Jump(float direction, float force = 0) { if (Mathf.Approximately(force, 0f)) force = Player.Instance.jumpForce; return Player.Instance.StartCoroutine(Jump_Internal(direction, force)); } public static IEnumerator Move_Internal(float direction, float duration) { Debug.Log($"[C] Dashing in direction {direction} for {duration} seconds"); var startTime = Time.time; yield return new WaitUntil(() => { Player.Instance.ExecuteMove(direction); return Time.time - startTime > duration; }); Debug.Log($"[C] Dash finished"); } private static IEnumerator Jump_Internal(float direction, float force) { var groundLayer = LayerMask.GetMask("Ground"); var player = Player.Instance; Debug.Log($"[C] Jumping with force {force}"); Player.Instance.ExecuteJump(force); var time0 = Time.time; yield return new WaitUntil(() => { player.ExecuteMove(direction); float raycastDistance = 0.8f; var hit = Physics2D.Raycast(player.rb.position, Vector2.down, raycastDistance, groundLayer); var onPlatform = (hit.collider != null && hit.collider.CompareTag("Platform")); return (Time.time - time0 > 0.2f) && onPlatform; }); Debug.Log($"[C] Jump finished"); } } Disclaimer: for this article, I probably care less than you do about how pretty the code looks like. The point is to get my message across. Lines 4-7 adds the possibility of invoking C.Execute() from the Unity Immediate Window, passing it a coroutine containing a sequence of code for asynchronous execution. Neat! Lines 9-12 and lines 20-30 gives us the chance to move the character to the left (-1) or right (1) for a specific amount of seconds. We can wait on this move to finish before proceeding further in our script. Lines 14-18 and lines 32-50 do the actual jumping. Similarly to moving, this accepts a weighted direction (negative means left, positive means right). Duration is implicit, as this function will return only when the floor is reached, which is cool. A slight delay of 0.2s was added to prevent the raycasting from activating too soon. Let's put all of this together into something useful. We are going to create our first automated playthrough script for the Unity Immediate Window. Finally, we will be able to keep our hands free for whatever we want while this test runs! Switch to multi-line input (one of the top-right buttons) and hide the bulky assembly window. Are you ready? Give this a brief read, and then copy it in the input section of the Unity Immediate Window: IEnumerator SkipToFinalJump() { // Fast-forward till the final jump section Time.timeScale = 2f; yield return new WaitForSeconds(3); yield return C.Move(1, 1); yield return C.Jump(1); // Onto first platform yield return C.Jump(0.5F); // Onto second platform yield return C.Jump(0.7F); // Onto third platform yield return C.Move(1, 1); yield return C.Jump(1); // Over flame yield return C.Move(1, 1.75f); yield return C.Move(-1, 0.75f); // Descend to second platform. yield return C.Move(1, 0.65f); // Descend to ground level. yield return C.Jump(1); // First sugar block yield return C.Move(1, 0.5f); yield return C.Jump(1.0f); // Stomp over enemy head yield return C.Jump(0.8f); // Stomp over second enemy head! yield return C.Jump(0.8f); // Second batch of stacked sugar cubes yield return C.Move(1, 1.0f); // Approach edge of next platform area // Testing the final jump section Time.timeScale = 1f; C.Gravity = 0.3f; // Let's cheat a bit yield return C.Jump(0.3f); // Super high jump to a new platform C.Gravity = 1.5f; // Nothing happened here yield return C.Move(1, 2.5f); // Walk into... // ScenesManager.Instance.CallNextScene(); // Wanna go back? } C.Execute(SkipToFinalJump()); What you and I are doing here is to create an asynchronous coroutine that will perform a series of gameplay steps. Moving and jumping are our foundation building blocks for this game, so we want to time them well, one after another. Since your and my time are valuable, we will increase the time scale during the initial stage of the game and slow it down back to a normal pace when we reach the middle stage we are working on. It could be the final boss. No more waiting. Start the game, type in the playthrough script and press the Unity Immediate's execute button! Level 2 Developer: Unity Immediate Window - Playthrough Automation I love it. Now that you created a functional playthrough script, make it permanent by converting it to a plain C# file. A meaningful name could be PlayMission1.cs. The point of using Immediate was to prototype our test as we played, avoiding, therefore, our stop-compile-play iteration times. Now that we have a playthrough test in place... Link to Summary Level 3 Unity Developer (Unity Immediate): Sample Output Table Level 3 Unity Developer: Extended Playthroughs One of my all-time favorites with Unity Immediate is just this: to quickly prototype your playthrough scripts. Then, you make those permanent and enjoy the results over and over again. However, by reading on this, you'll probably have realized the possibilities that Unity Immediate offers you. Can you guess what is the next level after automated playtests? Since we already have a playthrough script in place, wouldn't it be GREAT to extend it so we record useful data useful for further analysis? What kind of data? I'll start with performance metrics. But that's not the end, nor the middle. For my game, I want to record gameplay metrics too! Gathering stats such as remaining health, energy level, remaining monsters, ship status and so on at all points during our game is EXTREMELY useful. How happy will you make your designers by giving them access to these stats automatically? Imagine how easy is now to tweak difficulty levels, for instance. Even better, this is not an exclusive feature of automated playtests. The point is to gather this data in the background from real human players! And then, you bring this information to the front-end of your designers. Answer me this question: how many negative reviews will you avoid if you had access to accurate data at every point during your playtests? Level 3 Top Game Metrics Time What's the time since we started this specific play session? Record the variability of the different play styles from your target players. Markers What is your player doing right now? Are they in level 3 of our dungeon? Are we in a shop, or fighting a disgruntled boss? By analyzing how long it took our friend, the playtester Jamie, to reach the final boss, we can estimate whether our playing sessions are too long/short for the general public. Casual games should have relatively short play cycles, for instance. You'll want to make sure of this when analyzing your data to get your well-deserved money. Gameplay variables How many remaining enemies are there now? What is the player's score at the beginning, middle, and end of the game? What is the time left at this point? Is the player progressing as fast as we expect? Maybe the initial section is too hard. How many lives does our player Tobbi have at level 8 of our dungeon? If your players nearly die when you open that door, add a terrifying Sound FX to scare the shit out of your players. Create memorable moments to receive memorable reviews Performance metrics. Prevent your players from flipping a table when they start lagging at a final boss. At this point in the game, what's our average FPS and consumed memory? Respect the specified minimum system requirements! What's the vertex and poly count in the current player's view? Did I mention you can export this as CSV files? Now we are talking business. Do your numbers in Excel any time you want. Apply all the fancy math we all learned but forgot in school. Find boring areas, tweak them. You see, I learned the Importance of Analytics in games after years of programming casual games with over 30 million players. You do not get this data back ever if you didn't give a shit about it. It's gone. Finito. Do not skip this chance to make intelligent decisions in your game. Here, I am offering you a system to record all the data you need to make your game GREAT. And once you gathered your stats, take action by applying the Strategies I also send you. > Get it now, regret it never < Conclusion In this article, I gave you one of the latest tricks I discovered in Unity. The Unity Immediate Window package allows you to run C# scripts in run-time, which effectively cuts your iteration times during prototyping phases. You saw some of the possibilities of Unity Immediate. The main take-away of this entry was to create automated playtests that you would later extend to collect gameplay data. Afterward, you will use this precious information to make intelligent decisions about your game, tweak your gameplay and optimize it. As you might have noticed, the release rate of new packages is steadily increasing. It's so easy to miss packages! But that's no problem, that's why I'm here. I am here to remind you of things you don't want to miss out on. So make sure to subscribe to stay up to date in the industry. If you have enjoyed the article, give me a hug. You know where to find me. Rubén
  10. 1 point
    This was for a Dungeon Explorer home project I was working on. When researching labyrinth, maze, or dungeon generation algorithms I found many that would create hub or tree-style dungeons, but none that would 'loop back' on themselves. I created this algorithm with the intention of designers or artists still having full control over the look and contents of rooms and corridors. As long as certain rules are followed (e.g. attachpoints are assigned to rooms and snapped to a grid, rooms have a 'footprint' object that bounds their size) rooms and corridors can be any size or shape desired. This video demonstrates the process, which is also outlined below: giphy.mp4 I did go on to make a small game using this algorithm and bar some silly behaviour (like making corridors to from a room to itself), it's worked great! A short excerpt about the algorithm, for those that might like to re-create it! Steps Randomly Place rooms within the defined area Attempt to connect all rooms together in a large 'chain' Starting with random rooms, make smaller 'chains' of rooms within the network Prune room connections from rooms that have more connections than attach points Go through all room connections and connect actual attach points Use A* pathing to create corridors between the attach points Mark all of the corridors onto the grid Actually place straight, corner, T-Junction, and crossroad corridors oriented in the correct way There's a whole bunch more complexity in each of these steps, but that's the basic breakdown! The objects you see in the gif are 3d rooms complete with art and stuff inside them, but the camera is top down and lighting set to make the gif easier to see! Each room is a prefab game object. They have their own scripts that manage the stuff contained within them, in this case flickering torches, furnaces, and other puzzles. Each room has attach points that are defined by me (in this case acting as the designer), and the dungeon generator is given a list of all rooms it should use to generate, again defined by the designer. The rooms provide information like their size, shape, available attach points etc that the generator uses to position and connect them. There are different corridor types, straight, t junction, crossroad, and corners. Each has a different setup of walls. The algorithm places them just after the steps seen in the gif, choosing which to place base on what's adjacent to each grid position and orients them. Again these are prefab game objects with other things in them (e.g. Torches). I've just used debug lines to draw out the connections for the purpose of showing it in gif format, the original version doesn't do this at all! Another example but with 200 rooms rather than 50, at increased speed: giphy2.mp4 And another 200 room demo, with no speed increase: giphy3.mp4 Note: This article was originally shared via Reddit, and is recreated here with the kind permission of the author.
  • Advertisement
  • Advertisement
  • Popular Contributors

  • Member Statistics

    • Total Members
    • Most Online

    Newest Member
  • 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!