Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Learning'.

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


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Audio
    • Music and Sound FX
  • Business
    • Business and Law
    • Career Development
    • Production and Management
  • Game Design
    • Game Design and Theory
    • Writing for Games
    • UX for Games
  • Industry
    • Interviews
    • Event Coverage
  • Programming
    • Artificial Intelligence
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Engines and Middleware
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
  • Archive

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Game Dev Loadout
  • Game Dev Unchained

Categories

  • Game Developers Conference
    • GDC 2017
    • GDC 2018
  • Power-Up Digital Games Conference
    • PDGC I: Words of Wisdom
    • PDGC II: The Devs Strike Back
    • PDGC III: Syntax Error

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • Art Critique and Feedback
  • Community
    • GameDev Challenges
    • GDNet+ Member Forum
    • GDNet Lounge
    • GDNet Comments, Suggestions, and Ideas
    • Coding Horrors
    • Your Announcements
    • Hobby Project Classifieds
    • Indie Showcase
    • Article Writing
  • Affiliates
    • NeHe Productions
    • AngelCode
  • Topical
    • Virtual and Augmented Reality
    • News
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical
  • GameDev Challenges's Topics
  • For Beginners's Forum
  • Unreal Engine Users's Unreal Engine Group Forum
  • Unity Developers's Forum
  • Unity Developers's Asset Share

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams
  • GameDev Challenges's Schedule

Blogs

There are no results to display.

There are no results to display.

Product Groups

  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 16 results

  1. Unlock Audio

    Learning to Embrace Criticism

    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.
  2. This video tutorial is very great! For example, we want to add a cube on a scene: bpy.ops.mesh.primitive_cube_add() You can read about this API function in the documentation: primitive_cube_add Create a work folder with the name: mock-object-for-primitive_cube_add-api Open Blender and safe project in the work folder Open "Scripting" tab in Blender from the top menu Open your favourite Python editor. I use VSCode. You can read about how to use VSCode with Python here Python in Visual Studio Code Create a file with the name "main.py" in you favourite Python editor. This file must be placed in the "mock-object-for-primitive_cube_add-api" folder Write in the "main.py": print("hello from blender") You can run this code from command line terminal or from VSCode internal terminal. Press in VSCode "Ctrl+`" and enter command: python main.py You will see in the console terminal this message: If you opened "Scripting" tab in Blender you will see an ability to open Python script in Blender. Click on the "Open" Button in Blender Script editor inside Blender Choose the "main.py" file and click the "Open Text Block" button Open the Blender console terminal. For this you need to select in the main menu of Blender "Window" and select "Toggle System Console" Run the "main.py" script from Blender. For this you need to place your mouse pointer on text area and press "Alt+P" button You will see this message in the Blender console terminal: If you will change a code in an external editor like VSCode you need to reload in the Blender text editor. For this you need to press the "Alt+R+R" button You need to add only one file: "main.py" to the Blender text editor. Another files you need place in the work directory: "mock-object-for-primitive_cube_add-api" Copy this code to the "main.py" file: main.py import bpy import sys import os # Get a path to the directory with .blend file # There are the scripts in this directory dir = os.path.dirname(bpy.data.filepath) # Is the directory in the list with included # directories? If no, include the directory if not dir in sys.path: sys.path.append(dir) import object3d_service # Reload module. It is necessary if you use # external editor like VSCode # For reloading module you need to press in # Blender: Alt + R + R import importlib importlib.reload(object3d_service) # Note. You do not need to open all scripts in Blender, # you need only this script from object3d_service import Object3DService def main(): objectService = Object3DService() objectService.create_cube() if __name__ == "__main__": main() This is another files that you need to copy to the work directory: test_blender_service.py import unittest from unittest.mock import MagicMock from object3d_service import Object3DService class BlenderServiceTest(unittest.TestCase): def test_myTest(self): # Arrange object3DService = Object3DService() object3DService.blender_api.create_cube = MagicMock("create_cube") # Act object3DService.create_cube() # Assert object3DService.blender_api.create_cube.assert_called_once() object3d_service.py from blender_api import BlenderAPI class Object3DService: def __init__(self): self.blender_api = BlenderAPI() def create_cube(self): self.blender_api.create_cube() blender_api.py import bpy class BlenderAPI: def create_cube(self): bpy.ops.mesh.primitive_cube_add() Delete a default cube from the scene. Now you can reload Blender code editor ("Alt+R+R") and run the code ("Alt + P"). You will see that a new code will be created: You can set breakpoints in "main.py" because there are mock-object for Blender API. And you can run unit tests using this command: python -m unittest You will see that unit test are passed.
  3. 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).
  4. 8Observer8

    GameDev Books

    Updated 3/27/2019 I created a new section: Math and Physics I added a new link on this nice book: Beginning Math and Physics for Game Programmers I study how to write my own game engines using modern OpenGL/C# and WebGL/TypeScript. I advice you this book: C# Game Programming: For Serious Game Creation. This book shows how to write your own game engine with maintainable code using TDD. This is a great book. It is not for GameDev only. It shows how to develop big projects in general. I know that you like to write games using Game Engines like Unity. By this book you will know basics of Linear Algebra, Shader Math, Game Physics and so on. Shader Math is important for Unity too because you need to write shaders for Unity. HLSL and GLSL are very similar. It is a great book really. Behaviour-Driven Development: 2014 - 10 - BDD in Action: Behavior-driven development for the whole software lifecycle - John Ferguson Smart. Source Code: https://www.manning.com/books/bdd-in-action Test-Driven Development: 2013 - 12 - The Art of Unit Testing: with examples in C# - 2nd Edition - Roy Osherove. Source Code: https://github.com/royosherove/aout2 Writing Games: 2010 - 06 - C# Game Programming: For Serious Game Creation. Source Code: 9781435455566.zip (121 MB) 2015 - 09 - Build your own 2D Game Engine and Create Great Web Games Using HTML5, JavaScript, and WebGL by Kelvin Sung, Jebediah Pavleas, Fernando Arnez, and Jason Pace. Source Code: https://github.com/apress/build-your-own-2d-game-engine 2017 - 10 - Pro HTML5 Games - 2nd Edition - A.R. Shankar. Source Code: https://github.com/apress/pro-html5-games-17 2018 - 04 - Unity in Action - 2nd Edition - J. Hocking. Source Code: https://www.manning.com/books/unity-in-action-second-edition Computer graphics: 2013 - 07 - WebGL Programming Guide - K. Matsuda, R. Lea. Source Code: https://sites.google.com/site/webglbook/ 2013 - 06 - Computer Graphics Principles and Practice - 3rd Edition - John F. Hughes, Andries van Dam, Morgan McGuire, David F. Sklar, James D. Foley, Steven K. Feiner, Kurt Akeley. Source Code: http://cgpp.net/about.xml Math and Physics: 2004 - 04 - Beginning Math and Physics for Game Programmers - Wendy Stahler 2011 - 06 - Mathematics for 3D Game Programming and Computer Graphics - 3rd edition - Eric Lengyel 2011 - 11 - 3D Math Primer for Graphics and Game Development - F. Dunn, I. Parberry 2013 - 04 - Physics for Game Developers - 2nd Edition - David M. Bourg, Bryan Bywalec 2014 - 05 - Physics for JavaScript Games, Animation, and Simulations - Adrian Dobre, Dev Ramtal Multiplayer: 2015 - 05 - Multiplayer Game Development with HTML5 - Rodrigo Silveira. Source Code: https://www.packtpub.com/code_download/21527 2015 - 10 - Multiplayer Game Programming -  Josh Glazer, Sanjay Madhav. Source Code: https://github.com/MultiplayerBook/MultiplayerBook
  5. Initially, it wasn't pretty, and I have been told about 300 times to go watch tutorials when asking for help in discord... while trying to do something I was following in a tutorial. Trying to program starting out is like trying to walk down a hallway where you can't see the doors or windows on either side of you. Everyone else around you is screaming dude just turn the knob, you sit all puzzled, "What knob?" All that aside I feel things are going much smoother now about three months into this. I still struggle from time to time with super simple stuff like GetComponent while on the other hand being able to write a functioning weather system based on coroutines (timers). Actually being from an art background is one of the reasons I wanted to start this blog. I don't feel like an artist going into programming is a story I hear as much as maybe a programmer spiffing up his art skill or just plain out hiring a starving desperate artist to do the work for him. I wanted to share with you a few of my achievements in the past week. Progress often feels like you are surrounded by obstacles eager to kill you while you struggle to get moving. And just when you feel like you are finally moving you seem to hit a red light every 3 seconds. At the end of the day though you know you have to just get back up tomorrow and keep on swimming. Obviously, that is the only way you will ever open doors to opportunity!
  6. Let's write an executable documentation for server side calculator. Specifications: "Add(a, b)" method must to sum positive numbers. Specification name: Add_SumPositiveNumbers_ReturnsSum "Sub(a, b)" method must to subtract positive numbers. Specification name: Sub_SubtractPositiveNumbers_ReturnsSub Instruction: Create the "calculator-nodejs-jasmine-es5" folder Run these commands to install Jasmine locally: npm init -y npm install --save-dev jasmine Create the "jasmine.json" file in the "calculator-nodejs-jasmine-es5" folder Copy the content for the "jasmine.json" file from the link: https://jasmine.github.io/setup/nodejs.html and make some changes, see the content below: jasmine.json { "spec_dir": "src_specs", "spec_files": [ "**/*_tests.js", "!**/*nospec.js" ], "random": false } Open the "package.json" file and add the command to run tests: "scripts": { "test": "node node_modules/jasmine/bin/jasmine.js --config=jasmine.json" }, Try to run tests. Enter the command: npm test You will see a message that "No specs found" Create the "src_shared" folder. Create the "calculator.js" file the the "src_shared" folder Create the "src_specs" folder. Create the "calculator_tests.js" file the the "src_specs" folder Add our specs described above to the "calculator_tests.js" file: calculator_tests.js var Calculator = require("../src_shared/calculator"); describe("Calculator", function() { it("Add_SumPositiveNumbers_ReturnsSum", function() { // Arrange var calculator = new Calculator(); var a = 5; var b = 2; var expectedSum = 7; // Act var actualSum = calculator.Add(a, b); // Assert expect(actualSum).toEqual(expectedSum); }); it("Sub_SubtractPositiveNumbers_ReturnsSub", function() { // Arrange var calculator = new Calculator(); var a = 5; var b = 2; var expectedSub = 3; // Act var actualSub = calculator.Sub(a, b); // Assert expect(actualSub).toEqual(expectedSub); }); }); If you will run tests using the command "npm test" then you will see the message: Let's implement these methods and run tests using the command "npm test". You will see that the tests are passed. calculator.js var Calculator = function() { }; Calculator.prototype.Add = function(a, b) { return a + b; }; Calculator.prototype.Sub = function(a, b) { return a - b; }; module.exports = Calculator;
  7. FishingCactus

    A Simple Format to Archive Design Decisions

    Before starting production on Nanotale, we took some time to prototype various typing gameplay ideas. When prototyping, you have to focus on the things you want to test, and iterate on them as fast as possible. There is no time to document everything. But the prototypes do not always speak by themselves. (Sometimes there is no playable build to keep, like the time I tested interactive dialogs by acting as the NPC and talking through Slack with a colleague. We will get back to that.) So we needed a way to archive what we learned from each iteration, in a format that would be quick to write and read. The Problem This is a common problem of design documentation. How to keep an account of the decisions that led to a design as it is? It is interesting to keep a trace of previous iterations, to look back at the evolution of a design. But more importantly, it is a waste of time if another designer (or your forgetful self) makes changes that recreate a problem that has already been solved, just because they have no knowledge of the history behind that decision. For all those reasons, I was looking for a practical way to link each feature to the decision path that led to it. It needed to be quick to write and to read because if we have to go back and read multiple paragraphs of history, we all know no one will do it. Surely, someone already came up with a solution, right? A Solution Sadly, I could not find anything related to game design. The results I found were tools to keep track of programming design decisions in code, as it seems programmers need a similar solution for similar reasons. Eventually, I found a research paper about an experimental tool made to present design decision-making in a simple way. It gathers “decision elements” from different sources (code annotations, designers’ UML diagrams…) and organizes them visually in a hierarchy, like bullet points. If you want to know more about the technical details of their tool, it is called “DecDoc: A Tool for Documenting Design Decisions Collaboratively and Incrementally” (Hesse, Tom-Michael & Kuehlwein, Arthur & Roehm, Tobias 30-37. 10.1109/MARCH.2016.9) I took inspiration from their bullet points presentation. It is brief, the icons convey a meaning that does not have to go through text. When taking notes, only a few words are necessary. It is great for what we want. Here is a made up example of what it can look like for game design: ☝️ We need X to give game experience Y ✔️ There are no other games doing X ⚠️ An aspect of X can be too costly 🔑 can be limited to a few occurrences 🔑 We can try the different way Z instead ⇒ Give Z a test to decide ❓ How does this affect W? And here is a real example form the prototype of the dialogue system I was alluding to in the introduction. To give a bit of context, it was a test for a typing based branching dialog. Typing highlighted keywords would make the conversation go forward on the topic of the chosen keyword. The playtest challenged the idea of having secret keywords the player could type by himself, that they would have learned from another NPC. Our Version We took a few generic icon types from the original source and added others as they were needed. Here is the full list of the icons we have: ☝️ Postulate Let's admit that… 👉 Assessment We already know that… ❓ Question Uncertainty to be resolved or define 🛑 Problem This is / creates a problem / inconsistency ⚠️ Risk This seems risky and may not be fun/doable 🚩 Flag This problem will probably come up later on ⊕ Intention The motive behind a decision or design ⭐ Opportunity A good thing that can be developed 🔑 Solution Proposition of a solution 💡 Idea Proposition of an additional feature ✔️ Argument for Argument in favor of ❌ Argument against Argument against ✏️ Note Additional information ⇒ Decision Final decision of what we are doing All the icons are basic Unicode emojis and not images to gain time and ensure full compatibility. The bullet point notes of each prototype where copy pasted into Slack for the whole studio, and you can now see an example in this article, without extra work. They can also all be drawn quickly, at least in broad strokes, to be used when taking notes with pen and paper. Extended Use When we entered into production and decided to use a wiki as our design document, we ported the icon system to it. The wiki tool that is made to convert => into ⇒ was modified to also change :idea: into 💡. Here is another example, taken from the wiki page about the consumption of “mana” to cast spells. We ended up using those icons to add quick “work in progress” notes in our design documents. The most common is the idea icon (💡), used whenever we want to add an idea to an existing page for later review. The couple problem (🛑) - solution (🔑 ) identifies problems and solutions to evaluate whenever we can take the time to redesign the feature. The intention icon (⊕) has been added later, specifically for the wiki, to justify the purpose of a feature. Game design documents are in a constant work in progress state, evolving during development. They are often out-of-date from the latest changes if you do not have someone dedicated to that (which, on our small team, we don’t). The tool and format we use to write them should support that. With our system, whenever we see a bullet point with an icon, we know that the information is still part of an ongoing discussion. Other team members can trust what is written because what is unknown or unsure is also documented. The design process is transparent in the documents. In the future, that system will evolve a bit like a new language. On one hand by adding the icons we need, and in the other hand by removing the ones that are not used to avoid cluttering. The list as it is now is probably a bit too long. Now that I have told you everything, I would love to know if that system can be useful to others, or if other solutions exist. Thank you for reading.
  8. Investment in game-based learning companies was sharply up in 2018, according to leading serious games analyst firm, Metaari. A total of $2.25 billion went to 133 companies. In contrast, $948.2 million was invested in 150 game-based learning companies in 2017. While the number of deals declined slightly in 2018, funding levels were much higher and investment more than doubled. Almost 100 companies reported raising substantial funds. Seventeen PreK-12 academic-facing companies obtained funding in 2018. Twenty-one corporate-focused companies producing game-based training were funded. China is the education technology center of the universe, at least for now, according to Adkins. In 2018, 51 Chinese game-based learning companies garnered a combined total of $539.3 million. Nearly 50% of all ed tech investments made in 2018 went to Chinese companies. “This is the first time in the history of the industry that China overtook the US. A stunning $7.22 billion was invested in 207 Chinese learning technology companies in 2018,” Sam Adkins said. Metaari produces annual reports on the global game-based learning market. The reports, available from Serious Play Events, include an analysis of the catalysts driving the market as well as both a demand and supply-side analysis, providing publishers with the ability to choose high-yielding opportunities. In July, Metaari predicted a 37.1% CAGR growth rate for game-based learning products over the next five years. That growth would mean revenues will more than quadruple to well over $17 billion by 2023. Metaari’s Global 2018-2023 Game-Based Learning Market is available for sale from Serious Play Conference here: www.seriousplayconf.com/reports Metaari also produces reports on the Mixed Reality Learning Market and the Market for Mobile Educational Games.
  9. James Proctor

    Unity Unity MMO Creators - Youtube channel

    I've started a Youtube channel for anyone wanting to make a Indie MMO using the Unity3d game engine. Topics include: Business Kickstarter uMMORPG kit Atavism SpatialOS Community Building Interviews And more You can access the channel here. Intro Video: