Jump to content
  • Advertisement
  • 11/13/14 05:49 PM
    Sign in to follow this  

    Setting Realistic Deadlines, Family, and Soup

    Production and Management

    LordYabo

    Jan. 23, 2015. This is my goal. My deadline. And I'm going to miss it. Let me explain. As I write this article, I am also making soup. Trust me, it all comes together at the end.

    Part I: Software Estimation 101

    I've been working on Archmage Rises full time for three months and part time about 5 months before that. In round numbers, I'm about 1,000 hours in. You see, I have been working without a specific deadline because of a little thing I know from business software called the "Cone of Uncertainty":
    image.png
    In business software, the customer shares an idea (or "need")--and 10 out of 10 times, the next sentence is: "When will you be done, and how much will it cost?" Looking at the cone diagram, when is this estimate most accurate? When you are done! You know exactly how long it takes and how much it will actually cost when you finish the project. When do they want the estimate? At the beginning--when accuracy is nil! For this reason, I didn't set a deadline; anything I said would be wrong and misleading to all involved. Even when my wife repeatedly asked me. Even when the head of Alienware called me and asked, "When will it ship?" I focused on moving forward in the cone so I could be in a position to estimate a deadline with reasonable accuracy. In fact, I have built two prototypes which prove the concept and test certain mechanics. Then I moved into the core features of the game. Making a game is like building a sports car from a kit. ... but with no instructions ... and many parts you have to build yourself (!) I have spent the past months making critical pieces. As each is complete, I put it aside for final assembly at a later time. To any outside observer, it looks nothing like a car--just a bunch of random parts lying on the floor. Heck! To ME, it looks like a bunch of random parts on the floor. How will this ever be a road worthy car? Oh, hold on. Gotta check the soup. Okay, we're good. This week I finished a critical feature of my story editor/reader, and suddenly the heavens parted and I could see how all the pieces fit together! Now I'm in a place where I can estimate a deadline. But before I get into that, I need to clarify what deadline I'm talking about.

    Vertical Slice, M.V.P. & Scrum

    Making my first game (Catch the Monkey), I learned a lot of things developers should never do. In my research after that project, I learned how game-making is unique and different from business software (business software has to work correctly. Games have to work correctly and be fun) and requires a different approach. Getting to basics, a vertical slice is a short, complete experience of the game. Imagine you are making Super Mario Bros. You build the very first level (World 1-1) with complete mechanics, power-ups, art, music, sound effects, and juice (polish). If this isn't fun, if the mechanics don't work, then you are wasting your time building the rest of the game. The book Lean Startup has also greatly influenced my thinking on game development. In it, the author argues to fail quickly, pivot, and then move in a better direction. The mechanism to fail quickly is to build the Minimum Valuable Product (MVP). Think of web services like HootSuite, Salesforce, or Amazon. Rather than build the "whole experience," you build the absolute bare minimum that can function so that you can test it out on real customers and see if there is any traction to this business idea. I see the Vertical Slice and MVP as interchangeable labels to the same idea.
    [media]
    [/media] A fantastic summary of Scrum.
    Finally, Scrum is the iterative incremental software development methodology I think works best for games (I'm quite familiar with the many alternatives). Work is estimated in User Stories and (in the pure form) estimated in Story Points. By abstracting the estimates, the cone of uncertainty is built in. I like that. It also says when you build something, you build it complete and always leave the game able to run. Meaning, you don't mostly get a feature working and then move on to another task; you make it 100% rock solid: built, tested, bug fixed. You do this because it eliminates Technical Debt.
    debt.jpg
    What's technical debt? Well like real debt, it is something you have to pay later. So if the story engine has several bugs in it but I leave them to fix "later," that is technical debt I have to pay at some point. People who get things to 90% and then move on to the next feature create tons of technical debt in the project. This seriously undermines the ability to complete the project because the amount of technical debt is completely unknown and likely to hamper forward progress. I have experienced this personally on my projects. I have heard this is a key contributor to "crunch" in the game industry. Hold on: Gotta go put onions and peppers in the soup now. A second and very important reason to never accrue technical debt is it completely undermines your ability to estimate. Let's say you are making the Super Mario Bros. World 1-1 vertical slice. Putting aside knowing if your game is fun or not, the real value of completing the slice is the ability to effectively estimate the total effort and cost of the project (with reasonable accuracy). So let's say World 1-1 took 100 hours to complete across the programmer, designer, and artist with a cost of $1,000. Well, if the game design called for 30 levels, you have a fact-based approach to accurate estimating: It will take 3,000 hours and $30,000. But the reverse is also helpful. Let's say you only have $20,000. Well right off the bat you know you can only make 20 levels. See how handy this is?!? Still, you can throw it all out the window when you allow technical debt. Let me illustrate: Let's say the artist didn't do complete work. Some corners were cut and treated as "just a prototype," so only 80% effort was expended. Let's say the programmer left some bugs and hard-coded a section just to work for the slice. Call it a 75% effort of the real total. Well, now your estimates will be way off. The more iterations (levels) and scale (employees) you multiply by your vertical slice cost, the worse off you are. This is a sure-fire way to doom your project.

    So when will you be done?

    So bringing this back to Archmage Rises, I now have built enough of the core features to be able to estimate the rest of the work to complete the MVP vertical slice. It is crucial that I get the slice right and know my effort/costs so that I can see what it will take to finish the whole game. I set up the seven remaining sprints into my handy dandy SCRUM tool Axosoft, and this is what I got:
    never.jpg
    That wasn't very encouraging. :-) One of the reasons is because as I have ideas, or interact with fans on Facebook or the forums, I write user stories in Axosoft so I don't forget them. This means the number of user stories has grown since I began tracking the project in August. It's been growing faster than I have been completing them. So the software is telling the truth: Based on your past performance, you will never finish this project. I went in and moved all the "ideas" out of the actual scheduled sprints with concrete work tasks, and this is what I got:
    better.jpg
    January 23, 2015 This is when the vertical slice is estimated to be complete. I am just about to tell you why it's still wrong, but first I have to add cream and milk to the soup. Ok! Now that it's happily simmering away, I can get to the second part.

    Part II: Scheduling the Indie Life

    I am 38 and have been married to a beautiful woman for 15 years. Over these years, my wife has heard ad nauseam that I want to make video games. When she married me, I was making pretty good coin leading software projects for large e-commerce companies in Toronto. I then went off on my own. We had some very lean years as I built up my mobile software business. We can't naturally have kids, so we made a "Frankenbaby" in a lab. My wife gave birth to our daughter Claire. That was two years ago.
    Test_Tube_Baby2.jpg
    My wife is a professional and also works. We make roughly the same income. So around February of this year, I went to her and said, "This Archmage thing might have legs, and I'd like to quit my job and work on it full time." My plan was to live off her--a 50% drop in household income. Oh and on top of that, I'd also like to spend thousands upon thousands of dollars on art, music, tools, -- and any games that catch my fancy on Steam. It was a sweetheart offer, don't you think? I don't know what it is like to be the recipient of an amazing opportunity like this, but I think her choking and gasping for air kind of said it all. :-) After thought and prayer, she said, "I want you to pursue your dream. I want you to build Archmage Rises." Now I write this because I have three game devs in my immediate circle--each of which are currently working from home and living off their spouse's income. Developers have written me asking how they can talk with their spouse about this kind of major life transition.

    Lesson 1: Get "Buy In," not Agreement

    A friend's wife doesn't really want him to make video games. She loves him, so when they had that air-gasping indie game sit down conversation she said, "Okay"--but she's really not on board. How do you think it will go when he needs some money for the game? Or when he's working hard on it and she feels neglected? Or when he originally said the game will take X months but now says it will take X * 2 months to complete?
    pp42_marriage_conflict.jpg
    Yep! Fights. See, by not "fighting it out" initially, by one side just caving, what really happened was that one of them said, "I'd rather fight about this later than now." Well, later is going to come. Over and over again. Until the core issue is resolved. I and my friend believe marriage is committed partnership for life. We're in it through thick and thin, no matter how stupid or crazy it gets. It's not roommates sharing an Internet bill; this is a life together. So they both have to be on the same page because the marriage is more important than any game. Things break down and go horribly wrong when the game/dream is put before the marriage. This means if she is really against it deep down, he has to be willing to walk away from the game. And he is, for her. One thing I got right off the bat is my wife is 100% partnered with me in Archmage Rises. Whether it succeeds or fails, there are no fights or "I told you so"s along the way.

    Lesson 2: Do Your Part

    So why am I making soup? Because my wife is out there working, and I'm at home. Understandably so, I have taken on more of the domestic duties. That's how I show her I love her and appreciate her support. I didn't "sell" domestic duties in order to get her buy-in; it is a natural response. So with me working downstairs, I can make soup for dinner tonight, load and unload the dishwasher, watch Claire, and generally reduce the household burden on her as she takes on the bread-winning role. If I shirk household duties and focus solely on the game (and the game flops!), boy oh boy is there hell to pay. Gotta check that soup. Yep, we're good.

    Lesson 3: Do What You Say

    Claire is two. She loves to play ball with me. It's a weird game with a red nerf soccer ball where the rules keep changing from catching, to kicking, to avoiding the ball. It's basically Calvin ball. :-)
    redball.jpg
    She will come running up to my desk, pull my hand off the mouse, and say, "Play ball?!" Sometimes I'm right in the middle of tracking down a bug, but at other times I'm not that intensely involved in the task. The solution is to either play ball right now (I've timed it with a stopwatch; it only holds her interest for about seven minutes) or promise her to play it later. Either way, I'm playing ball with Claire. And this is important because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that. Now Claire being two, she doesn't have a real grasp of time. She wants to go for a walk "outside" at midnight, and she wants to see the moon in the middle of the afternoon. So when I promise to play ball with her "later," there is close to a 0% chance of her remembering or even knowing when later is. But who is responsible in this scenario for remembering my promise? Me. So when I am able, say in between bugs or end of the work day, I'll go find her and we'll play ball. She may be too young to notice I'm keeping my promises, but when she does begin to notice I won't have to change my behavior. She'll know dad is trustworthy.

    Lesson 4: Keep the Family in the Loop like a Board of Directors

    If my family truly is partnered with me in making this game, then I have to understand what it is like from their perspective:
    1. They can't see it
    2. They can't play it
    3. They can't help with it
    4. They don't know how games are even made
    5. They have no idea if what I am making is good, bad, or both
    Board-table.jpg
    They are totally in the dark. Now, what is a common reaction to the unknown? Fear. We generally fear what we do not understand. So I need to understand that my wife secretly fears what I'm working on won't be successful, that I'm wasting my time. She has no way to judge this unless I tell her. So I keep her up to date with the ebb and flow of what is going on. Good or bad. And because I tell her the bad, she can trust me when I tell her the good. A major turning point was the recent partnership with Alienware. My wife can't evaluate my game design, but if a huge company like Alienware thinks what I'm doing is good, that third party perspective goes a long way with her. She has moved from cautious to confident. The Alienware thing was a miracle out of the blue, but that doesn't mean you can't get a third party perspective on your game (a journalist?) and share it with your significant other.

    Lesson 5: Life happens. Put It in the Schedule.

    I've been scheduling software developers for 20 years. I no longer program in HTML3, but I still make schedules--even if it is just for me. Customers (or publishers) want their projects on the date you set. Well, actually, they want it sooner--but let's assume you've won that battle and set a reasonable date. If there is one thing I have learned in scheduling large team projects, it is that unknown life things happen. The only way to handle that is to put something in the schedule for it. At my mobile company, we use a rule of 5.5-hour days. That means a 40-hour-a-week employee does 27.5 hours a week of active project time; the rest is lunch, doctor appointments, meetings, phone calls with the wife, renewing their mortgage, etc. Over a 7-8 month project, there is enough buffer built in there to handle the unexpected kid sick, sudden funeral, etc. Also, plug in statutory holidays, one sick day a month, and any vacation time. You'll never regret including it; you'll always regret not including it. That's great for work, but it doesn't work for the indie at home.
    1176429_orig.jpg
    To really dig into the reasons why would be another article, so I'll just jump to the conclusion:
    1. Some days, you get stuck making soup. :-)
    2. Being at home and dealing with kids ranges from playing ball (short) to trips to the emergency room (long)
    3. Being at home makes you the "go to" family member for whatever crops up. "Oh, we need someone to be home for the furnace guy to do maintenance." Guess who writes blogs and just lost an hour of his day watching the furnace guy?
    4. There are many, many hats to wear when you're an indie. From art direction for contract artists to keeping everyone organized, there is a constant stream of stuff outside of your core discipline you'll just have to do to keep the game moving forward.
    5. Social media marketing may be free, but writing articles and responding to forum and Facebook posts takes a lot of time. More importantly, it takes a lot of energy.
    After three months, I have not been able to come up with a good rule of thumb for how much programming work I can get done in a week. I've been tracking it quite precisely for the last three weeks, and it has varied widely. My goal is to hit six hours of programming in an 8-12 hour day.

    Putting This All Together

    Jigsaw-Puzzle.png
    Oh, man! This butternut squash soup is AMAZING! I'm not much of a soup guy, and this is only my second attempt at it--but this is hands-down the best soup I've ever had at home or in a restaurant! See the endnotes for the recipe--because you aren't truly indie unless you are making a game while making soup! So in order to try and hit my January 23rd deadline, I need to get more programming done. One way to achieve this is to stop writing weekly dev blogs and switch to a monthly format. It's ironic that writing fewer blogs makes it look like less progress is being made, but it's the exact opposite! I hope to gain back 10 hours a week by moving to a monthly format. I'll still keep updating the Facebook page regularly. Because, well, it's addictive. :-) So along the lines of Life Happens, it is about to happen to me. Again. We were so impressed with Child 1.0 we decided to make another. Baby Avery is scheduled to come by C-section one week from today. How does this affect my January 23rd deadline? Well, a lot.
    • Will baby be healthy?
    • Will mom have complications?
    • How will a newborn disrupt the disposition or sleeping schedule of a two-year-old?
    These are all things I just don't know. I'm at the front end of the cone of uncertainty again. :-) SDG

    Links:

    Agile Game Development with Scrum - great book on hows and whys of Scrum for game dev. Only about the first half is applicable to small indies. Axosoft SCRUM tool - Free for single developers; contact support to get a free account (it's not advertised) You can follow the game I'm working on, Archmage Rises, by joining the newsletter and Facebook page. You can tweet me @LordYabo

    Recipes:

    Indie Game Developer's Butternut Squash Soup (about 50 minutes; approximately 130 calories per 250ml/cup serving)
    soup.jpg Dammit Jim I'm a programmer not a food photographer!
    I created this recipe as part of a challenge to my wife that I could make a better squash soup than the one she ordered in the restaurant. She agrees, this is better! It is my mashup of three recipes I found on the internet.
    • 2 butternut squash (about 3.5 pounds), seeded and quartered
    • 4 cups chicken or vegetable broth
    • 1 tablespoon minced fresh ginger (about 50g)
    • 1/4 teaspoon nutmeg
    • 1 yellow onion diced
    • Half a red pepper diced (or whole if you like more kick to your soup)
    • 1 tablespoon kosher salt
    • 1 teaspoon black pepper
    • 1/3 cup honey
    • 1 cup whipping cream
    • 1 cup milk
    Peel squash, seed, and cut into small cubes. Put in a large pot with broth on a low boil for about 30 minutes. Add red pepper, onion, honey, ginger, nutmeg, salt, pepper. Place over medium heat and bring to a simmer for approximately 6 minutes. Using a stick blender, puree the mixture until smooth. Stir in whipping cream and milk. Simmer 5 more minutes. Serve with a dollop of sour cream in the middle and sprinkling of sourdough croutons.



      Report Article
    Sign in to follow this  


    User Feedback


    As a senior business dev with a fiance, I can relate to this 100%. Although I don't have the stones to swap over to game development.

    Share this comment


    Link to comment
    Share on other sites

    So... quick question regarding prototypes and scrum:
    With scrum, you're supposed to build something "shippable" and each task needs to be 100% complete, yet a prototype or "vertical slice" is just a rough sketch of what needs to be built, so how do you use scrum to build a rough draft version to test out a particular game mechanic / game system?

     

    In my project, I've been writing about 85% complete code and focusing entirely on "just get it done", which causes some refactoring when my initial architectural implementation was incompatible. The intent is to build the game prototype to be an accurate representation of how the final product should work / behave, and when it comes time to build the final product, it's mostly a matter of porting most of the established systems over to a commercial game engine. Should I be aiming for 100% complete code? How do I know when its 100% complete if the next task may require it to change?

    Share this comment


    Link to comment
    Share on other sites

    I have to say you are quite lucky to have friends who are game devs. My main problem with going forward with any project is that, at some point, i just lose momentum :(

     

    Best of luck with both your game and Child 2.0 ;)

    Share this comment


    Link to comment
    Share on other sites

    This Article.

    ...though I don't agree with your opinion on 'technical debt';

    in my experience leaving chunks of sorta-broken, hard-coded, badly implemented functionality can help you fail faster.

    If i had a dollar for every "system" I worked to perfection, only to have it "cut" later, I could afford an artist ;)

    Given the cone of uncertainty you ideally want an inverse cone of 'gilding the lilly'.

    So you are spending the most critical time, on the most defenite stuff.

    ...another key here is using technology/methods that allow you to develop in this haphazard modular manner; some examples being:
     

    • dependency injection
    • obeying Law of Demeter
    • using 'soft' serialization/data formats: human readable, hand editable, non-sequental
    • anonymous objects, implicit interfaces (duck typing)

    Share this comment


    Link to comment
    Share on other sites

    I was just chatting with EDI, saying tech debt is a major problem in linux, php, wordpress, web browsers. Then I read the article. Gotta agree with him in this context. You can evaluate mechanics (and mood to some extent) without a full vertical slice. If it's going to be fun with polished graphics and everything, it WILL be fun with blocky graphics, borrowed music, and sketchy code.

     

    As for estimating, I think of it as an arbitrary constraint to keep cost and scope in check. Pick a number, double it, adjust features/quality/deadlines if you still can't make it. If you don't have tech debt you can't compromise on features or quality. I've never seen that on a business project but perfectionism kills a lot of 'labor of love' projects.

    Share this comment


    Link to comment
    Share on other sites

    Great article. I'm so glad you've mentioned MVP and Vertical Slice (now I don't have anything to say!)

    Share this comment


    Link to comment
    Share on other sites

    Very nice article sir. It's nice to see real wisdom spelled out every so often, and I'm truly happy for you.  I'm blessed enough to be in a similar situation with a supportive wife and a decent chunk of time to dedicate towards game development. 

     

    Congratulations on the progress you've made so far. I can't wait to get to that point where my collection of parts starts coming together.

     

    I wish you the best with Child 2.0's health, balancing being a good father/husband, and still somehow making progress on your game with a newborn in the house.

    Share this comment


    Link to comment
    Share on other sites

    Thank you for this great article.

     

    Your thoughts on technical debt pretty much reflect the lousy situation that i'm experiencing right now.

    The project itself has deadlines from hell. This is because the executives want to satisfy the customer

    with no regard for anything. In such situations you are always working on the limit especially if the team

    isn't that large. So you are making compromises on tasks that will lead to shippable software (hopefully)

    with a total mess under the hood.

     

    So here is the bad news:

    You know that the software is badly written at several points but the next features need to get implemented

    to satisfy the customer "one more time". Hence you can't do anything about the critical state of the software.

    Instead you're building something on top of an unstable construct - what could go wrong :-/

    After several iterations of this process you will come to a point where you can't implement anything without

    breaking the whole thing at another part you weren't aware of.

     

    The amount of time that is needed to "repair" this huge clusterfuck your project has become could be

    pretty huge. In some situations you are better off hitting the delete button and throw it all directly into the

    trash bin. 

    But if one decides to tackle the task and do a massive refactoring you are loosing time. For sure the customer won't understand why you are not able to put all his requested features into the next version anymore.

    Consequently there is a chance you are loosing the customer in the worst case.

     

     

    Conclusion (based on my personal experience):

    Never let the technical debt exceed a specific limit (depends on the size of the project, team size and several

    other factors). Otherwise you will pay the price - and it will be expensive!

     

     

    I would love to read more articles from you :)

    Until then i wish you all the best with your project and your family.

    Share this comment


    Link to comment
    Share on other sites

    "And this is important, because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that."

     

    I can get behind that...

    Share this comment


    Link to comment
    Share on other sites

    Just wanted to chip in with a compliment, this is one of the best article I've read this whole year, both from a conceptual standpoint AND a technical one.

     

    Very Good.

     

    Also:

    "And this is important, because to be a crappy dad and have a great game just doesn't look like success to me. To be a great dad with a crappy game? Ya, I'm more than pleased with that."

     

    Best Quote ever, wish you the BEST for all your endeavours.

    Share this comment


    Link to comment
    Share on other sites

    Great article!

     

    I can relate to everything you've said there (Also being a 38 year old developer, who has been writing games (Although only as a hobby) for about 24 years). 

     

    I wish you all the luck in the world. I also wish I had the balls to do what you've done.

     

    Ben

    Share this comment


    Link to comment
    Share on other sites

    Great article! I'm just leaving my job to start working at my own developing games. Probably similiar situation but in smaller scale, because in fact I don't have much experience and this will be small experiment. And of course rest from crappy, dull and boring work at corporation. My wife will be working and I'll be "housewife" so I'll probably check this recipe. Thanks!

    Share this comment


    Link to comment
    Share on other sites

    Thank you for this article. I would like to eventually quit my full time job to pursue indie game dev. I have a plan and a due date. I need to definitely bring my wife on board as I am the sole bread winner at the moment. It is encouraging to hear your approach on this. I agree with family first though I pine often to make "making games" my job.

     

    Thanks again!

    Share this comment


    Link to comment
    Share on other sites


    Create an account or sign in to comment

    You need to be a member in order to leave a comment

    Create an account

    Sign up for a new account in our community. It's easy!

    Register a new account

    Sign in

    Already have an account? Sign in here.

    Sign In Now

  • Advertisement
  • Advertisement
  • What is your GameDev Story?

    In 2019 we are celebrating 20 years of GameDev.net! Share your GameDev Story with us.

    (You must login to your GameDev.net account.)

  • Latest Featured Articles

  • Featured Blogs

  • Advertisement
  • Popular Now

  • Similar Content

    • By assboot
      I've recently implemented runtime lua scripting in my game engine, and am currently just polishing it. During the polishing I noticed that when I do this one specific thing in lua, the stack gets overflown. I'm doing the memory management my self for the lua stack, and I'll code dump it at the bottom of this post in case it has any relevance.
      To give some context, I'm using the __index and __newindex metamethods for reading and writing fields in the user data "LuaEntity", which is basically just a wrapper for the Entity class in my engine. This is somewhat what the __index and __newindex functions look like in C++
      static int32 __index(lua_State *ls) { string _index = lua_tostring(ls, -1); if (lua_isuserdata(ls, -2) && !lua_isnil(ls, -2)) { auto _entity = (LuaEntity*)lua_touserdata(ls, -2); if (SceneManagement::GetEntity(_entity->id)) { _entity->UpdateProps(); if (_index == "x") { lua_pushnumber(ls, _entity->x); } else if (_index == "some_field") { lua_pushnumber(ls, _entity->some_field); } else if (_index == "some_other_field") { lua_pushnumber(ls, _entity->some_other_field); } else /* if reading a non-default field */ { lua_getuservalue(ls, -2); WZ_ASSERT(!lua_isnil(ls, -1), "Tried reading unitialized field '" + _index + "' in '" + _entity->name + "'"); lua_pushvalue(ls, -2); lua_gettable(ls, -2); lua_remove(ls, -2); } return 1; } } else { lua_pushnil(ls); } return 1; } static int32 __newindex(lua_State *ls) { string _index = lua_tostring(ls, -2); if (lua_isuserdata(ls, -3) && !lua_isnil(ls, -3)) { auto _entity = (LuaEntity*)lua_touserdata(ls, -3); if (SceneManagement::GetEntity(_entity->id)) { if (_index == "x") { WZ_ASSERT(lua_isnumber(ls, -1), "Expected number value"); // .. Set "x" to the value top on stack } else if (_index == "some_field") { WZ_ASSERT(lua_isnumber(ls, -1), "Expected number value"); // .. Set "some_field" to the value top on stack } else if (_index == "some_other_field") { WZ_ASSERT(lua_isnumber(ls, -1), "Expected number value"); // .. Set "some_other_field" to the value top on stack } else /* if writing a non-default field */ { lua_getuservalue(ls, -3); lua_pushvalue(ls, -3); lua_pushvalue(ls, -3); lua_settable(ls, -3); lua_remove(ls, -1); } _entity->UpdateProps(); } } return 0; } }; This all works fine as in I can read and write both the default but also user-made fields in the entity table without a problem like this:
      local function update() -- A callback function that's invoked each frame from C++ local entity = entity_get("some_entity") local old_x = entity.x local old_y = entity.y -- .. do stuff if (old_x ~= entity.x or old_y ~= entity.y) then -- .. entity moved end end This keeps the memory steady with no problems, however, If I were to do the same thing but instead of storing entity position in old_x and old_y I would store it in a table called old_pos like this:
      local function update() -- A callback function that's invoked each frame from C++ local entity = entity_get("some_entity") local old_pos = { x = entity.x, y = entity.y } -- return values 'x' and 'y', pushed to the stack in C++, doesn't get garbage collected - memory fills up -- .. do stuff if (old_pos.x ~= entity.x or old_pos.y ~= entity.y) then -- .. entity moved end end then the values x and y, each pushed to the stack in __index as a return value, seems to not get garbage collected by lua which quickly fills up my stack budget and causes the stack to overflow.
      Here is how I've told lua to handle stack memory:
      struct LuaMemPool { const void *head; const void *tail; const ubyte *headByte; ubyte *current; LuaMemPool(void *head, void *tail) : head(head), tail(tail), current((ubyte*)head), headByte((ubyte*)head) { } void Free(void */*ptr*/) { } void *Allocate(size_t sizeBytes) { void *_ptr = current; current += sizeBytes; WZ_ASSERT(current <= tail, "Memory usage overflow"); return _ptr; } void *Realloc(void *ptr, size_t oldSize, size_t newSize) { void *_newPtr = Allocate(newSize); memcpy(_newPtr, ptr, oldSize); Free(ptr); return _newPtr; } int32 Allocated() { return (int32)(current - headByte); } static void *Alloc(void *ud, void *ptr, size_t osize, size_t nsize) { LuaMemPool& _pool = *((LuaMemPool*)ud); if (nsize == 0) { if (ptr != nullptr) { _pool.Free(ptr); } return NULL; } else { if (ptr == nullptr) { return _pool.Allocate(nsize); } return _pool.Realloc(ptr, osize, nsize); } } }; I am aware that I'm not freeing memory.
    • By muttsang
      Hello everyone,
      I am a Games Tech and Design student in my second year and I have made a game on the side for mobile. I want to publish the game in the Play Store for Android and I do not want to make money out of it. I just want to have a free game on the play store because I want to experience publishing games on platforms accessible to majority of people and enjoy what I have done. The problem is i do not know anything about copyright laws and legal stuff and I have used some assets from the internet where they have said the asset can only be used for personal use.
      I want to know if I could get in trouble for using those stuff for a free game (no monetization). and if i have to refer the original creator, how would I do it? 
      Sorry if it is a common and silly question but I have no idea whatsoever on the legal stuff. I looked it up on the internet and have found out that if the game does not make money i can publish it and some said that i could get into legal trouble if i am not careful about it. 
       
      Thanks,
      muttsang
    • By GameDev.net
      Note: This article was originally posted to GameDev.net in 2003, and although the "shareware" terminology is now dated, the advice remains relevant and meaningful.
       
      Why is it that some shareware developers seem to be hugely successful in financial terms, growing their sales from scratch to generate tens of thousands of dollars in income, while the vast majority struggle to generate even a handful of sales? The answer can be found by exploring the difference in mindsets between both groups. For convenience, we'll label them as the professional and the amateur.
      First, let's examine the...
       
      Product Development Cycle
      Amateur
      Get inspired by an idea for a product. Create the product, regardless of whether there's a market for it. Release the product. Promote the product sporadically until bored with marketing. Note dismal results. Ask disempowering questions like, "Why do my sales suck?" Sulk for a while. Network mostly with others who are also getting dismal results, taking comfort in the fact that you aren't alone. Make a few sporadic changes to product or web site (maybe). Abandon the product (aside from continuing to process orders and handle support), and move on to the next product with step 1. Professional
      Do basic market research to determine the best opportunities for new products. Design a product that inspires you and that can exploit the market opportunities you identified. Create the product along with the system for selling the product and the marketing plan. Release the product. Promote the product systematically according to the marketing plan. Measure results and gather feedback. Study and learn from the top industry performers (companies and products). Ask empowering questions like, "How can I increase sales by 20% or more?" Update the product, the sales system, and the marketing plan based on lessons learned. Repeat from step 5.  
      After the first pass through this cycle, the initial results for the amateur and the professional may be virtually identical. But whereas the amateur typically stops after the first pass, the professional understands that this is just the beginning. Let's say they each release products that initially generate $100 per month in sales. The amateur will often conclude that the product is a failure, perhaps make a few minor revisions that don't help much, and then move onto the next product. But the professional says, "How can I get to $200 per month?" By iterating through this cycle of refinement and re-release many times (often more than ten times over a period of several years), the professional may ultimately end up with a hit that generates thousands of dollars in monthly income. To the amateur that initial $100 per month is seen as a flop. To the professional, however, it is seen as a seed. The professional understands that the initial launch is only the first step in a long stream of future updates and refinements, not just to the product but also to the sales system and the marketing plan. Here's why this works:
      In order to make a single shareware sale, there are an enormous number of factors that must all come together synergistically. The chance of getting all these factors correct on the initial release is slim to none. Let's say there are only ten critical factors in making a shareware sale (the quality of the product, the market demand for the product, the effectiveness of your registration incentives, the effectiveness of your ordering system, the file size of your shareware demo, and so on). And let's say that for each factor there is a range of effectiveness from 0% to 100%. Understand this: these factors don't add -- they multiply! If all of your critical factors are at 100%, but just one is at 0%, that means you could be getting zero sales, even though you did most things perfectly. For instance, you could have a truly brilliant product, but if people don't feel secure using your order form, that single flaw could cost you most of your potential sales.
      What if each of these 10 factors was at 60% effectiveness? Do you realize that this means you're only getting 0.610 = 0.6% of the sales you could be getting? Even if each factor is at 90% effectiveness, that's still only 35% of optimal. Obviously, this model is oversimplified. My goal is to dispel the prevailing myth that if each part of your ordering pathway is "good but not great," that your final sales will be good too -- the reality is that lots of good factors multiply together to create "utterly dismal." Here's the formula: (Good but not great)N = Utterly dismal (for a sufficiently large N). If everything about your product is just good (say 60% of optimal), this doesn't mean you'll be getting 60% of the potential sales. It means you're more likely getting less than 1% of the sales you could be getting. Refining the critical success factors and making each part of your product, your sales system, and your marketing just a little bit better with each consecutive release is how you grow your sales massively over time. It isn't out of the question that you can double or triple your sales in a day by doing this. See this article for some ideas on that.
      Now the truth of the matter is that most initial releases are nowhere near averaging 60% effectiveness for all critical success factors. Especially for first-time developers, there are probably many factors that are at 10% or less. The headline on your product web page, for instance, may be nonexistent or poorly written. Your product may have bugs or compatibility problems that prevent many people from running it. Your web site may look unprofessional and scare potential customers away. You may not have even scratched the surface of all the marketing you should be doing. Perhaps you only have one product and aren't experiencing the benefits of cross-selling other products. It's entirely possible that when all these factors come together, you may be generating something like 0.01% of the potential results that your product is capable of if you continued to nurture its development.
      Selling software through shareware channels is very different than selling software at retail. With try-before-you-buy, there are a huge number of steps each potential customer can go through before buying, any one of which can kill the sale. Just one suboptimal factor can cost you most of your potential sales, and when combined, multiple suboptimal factors may be tossing out potential customers left and right. Picture a ball rolling down a pipe with ten holes. If the ball passes all the way through the pipe without falling through any holes, you make a sale. But if the ball falls through even one of those ten holes, the sale is lost. The way you get your product from dismal sales to outstanding sales is by systematically identifying and plugging those holes.
      Having been in this industry for many years, I've seen this cycle repeat itself again and again. You would be absolutely amazed at how many of the greatest shareware hits experienced dismal sales after their initial release... sometimes even no sales at all in the entire first year. But the developers turned them into hits by continuously improving those critical success factors over a period of years.
      So which is the better approach? To release five products in five years, each at 0.01% effectiveness, or to raise a single product from 0.01% to 2%? If 0.01% makes you an average of $100 per month, the first scenario will get you to $500 per month, and this is exactly what amateur developers do. But the second scenario will get you to $20,000 per month with just one product, and it requires less work too.
      There are three good reasons why experienced professional shareware developers are often able to release more consistent hits than less experienced amateurs. First, the pros have already plugged many of the holes in their system that are shared by all products, such as optimizing their web sites to sell, refining the ordering process, implementing a money-back guarantee, crafting a solid marketing plan, gaining excellent search engine placement, etc. So when a new product is released, it inherits the benefits of prior system-wide optimization work. Secondly, the pros can apply the wisdom gained from refining each previous product to any new release, so when they release a new product, they've already eliminated all the obvious sale-killers that still plague amateur developers. And thirdly, the pros have already internalized the attitude that the first release is just the beginning; thus, they expect to continue to refine the product and immediately start listening to user feedback to help them locate new holes that need to be plugged.
      It is rare in the extreme that a developer's initial release will be anywhere near its full potential, even if the developer has vast experience. If you release a new shareware product, I guarantee it's going to be riddled with flaws, and it's probably earning less than 1% of its potential. If you raise each of ten critical success factors by just 5%, you'll increase your sales by 60%. And if you do this over and over again, you'll see your monthly sales gradually climb: $100... $160... $250... $400... $650... $1000... $1700... $2700... $4300... $6900... $11,000... $18,000... and so on. Note that you don't even reach $1000 per month until the 5th iteration!!!
      In order to improve these critical success factors, you have to confront the brutal, objective facts. Invite others to evaluate your product, your web site, and your ordering system. This requires putting your ego aside and being as open-minded as possible. Find out how others are marketing their products. Listen to what others have to say; don't delude yourself by trying to persuade them you're right and they're wrong. Don't worry about trying to make everything perfect all at once. But see if you can increase several critical success factors by a small amount with each successive release. For instance, you might try to make your product page just 20% more effective, your registration incentives 10% more enticing, your product interface 30% more intuitive, and so on.
      As a personal example, shortly after I released Dweep in mid-1999, I began getting requests for an expansion pack of more levels. So I released an expansion pack. Players also complained that Dweep moved too slow and needed a speed control. So I added a speed control. Then players wanted another expansion pack, so I released that. Then players wanted a level editor, so I added that. Then players wanted to be able to post their own levels, so I added a free levels archive. That turned out to be too much work to maintain, so I eventually took it down and replaced it with a forum where players can post their own levels, which has been working out wonderfully. During this time I also made major revisions to the web site, the marketing process, the ordering system, cross-promotions with others games, and the price (raising it from $9.95 to $24.95 while increasing the number of levels from 30 to 152). Most of Dweep's sales were a result of these later refinements, not the initial release.
      The amateur mindset leaves most of the potential rewards forever untapped, wallowing below 1% of the true potential. But professionals keep going... treating that shareware product as a tree that must be patiently watered before it bears a full harvest of fruit. I suppose you could say that the amateur sees the glass as 99.99% empty, while the professional sees it at 0.01% full.
      Now let's explore the differences between shareware amateurs and professionals in terms of...
       
      Personal Development
      Amateur
      Myopically focus personal development efforts on the areas you enjoy most (such as design or programming) as opposed to the areas where improvement would yield the greatest results (such as marketing or self-discipline). Gain knowledge sporadically through just one or two primary sources (i.e. reading books and articles, but not live seminars or audio programs). Apply your new knowledge to make your strengths even stronger (i.e. product development), while falling further behind in your weakest areas (i.e. marketing and sales). Guard the best of what you've learned as a treasured secret. Maintain a competitive scarcity mentality. Repeat from step 1.  
      Professional
      Take personal inventory of strengths as well as weaknesses that specifically detract from those strengths (ex. poor goal-setting habits result in unfocused marketing plan). Identify key knowledge/skills that must be mastered (marketing, selling, programming, etc) as well as key character traits that need improvement (organization, self-discipline, focus, motivation, etc). Identify multiple sources where above knowledge/skills/traits can be improved (mentors, business associates, books to read, organizations to join, conferences/seminars to attend). Take action by diving into these sources. Read the books, join and become active in the organizations, attend the conferences/seminars, and learn from the key individuals. Patiently apply the new knowledge to your business and life, realizing that even small gains will compound exponentially as you continue running this cycle year after year. Pass on your new wisdom to others by sharing advice, writing, volunteering, mentoring others, etc. Maintain a noncompetitive abundance mentality. Repeat from step 1.  
      The amateur sees personal development in narrow, monodimensional terms -- i.e. becoming a better developer. Efforts are focused on acquiring more knowledge within this limited field. A shareware amateur's bookshelf will be dominated by books within a narrow field, such as software development, virtually ignoring other crucial parts of the business like marketing and sales.
      By contrast, the professional takes a holistic approach. The professional understands that all areas of one's life are intertwined and that a weakness in one area (such as financial management) can detract from strengths in other areas (such as programming). The professional's bookshelf will likely be filled with a varied mix of books on topics such as business, marketing, sales, finance, technology, psychology, philosophy, health, and relationships. The professional keeps an open mind to acquiring knowledge through a variety of media, perhaps reading a book on software development, having a discussion with peers about marketing, listening to an audio program on time management, and attending a seminar on sales techniques. The professional seeks to advance on multiple fronts, understanding that a 10% improvement in five different areas will yield better results than a 50% improvement in just one.
      The amateur guards knowledge as a scarce resource... a competitive edge. Thus, the amateur rarely becomes known in professional circles, thus missing out on scores of lucrative opportunities that professionals frequently share with each other. This attitude constricts the flow of new knowledge back to the amateur, and the result is that the amateur is cut-off and isolated from the "inner circle" of the highly successful within his/her industry. Few bother to help the amateur directly because the amateur has never done anything for them and is relatively unknown. The amateur is stuck in a downward spiral of scarcity where growing the business feels like climbing a mountain.
      Conversely, the professional understands the importance of information flow and that passing on knowledge to others only deepens his/her own understanding. This sharing of knowledge plants seeds of abundance that benefit the professional for years to come. By giving openly and generously, the professional develops a positive reputation that attracts other professionals. An abundance of new opportunities flow to the professional through this network, seemingly without effort. This creates an upward spiral where the professional is able to leverage this network to grow his/her business with relative ease.
      Finally, let's dive into the...
       
      Psychological Factors
      Amateur
      Nonexistent or foggy goals ("Make more money") Sporadic motivation coming from irregular outside influences (inspiring book/movie, great conversation, flash of insight, etc) Focus on making money and getting customers to buy Seeks to blame poor results on outside factors (poor economy, competition, lack of luck, unfairness, shortfallings of shareware model, etc) Expends effort on the most enjoyable actions Scarcity mentality based on zero-sum thinking ("I'm not going to give anything away unless I get something in return") Short-range time perspective used in planning, often limited to the timeline of a single product cycle Sees problems as obstacles Persistent self-doubt ("Success is elusive") Unbalanced approach improving major strengths while letting other areas slide Believes that success comes from doing (work), then having (results), then being (successful) "Once I achieve this (foggy) goal, then I'll be successful" Weak commitment ("I'll try this and see what happens") Avoids facing brutal facts, stays within comfort zone ("I don't enjoy/understand marketing, so I'll just keep programming for now") Believes that risk-taking and luck are necessary for big breakthroughs ("Releasing a new product is like betting on a spin of the roulette wheel") Success stories from others increase feelings of anxiety, inadequacy, or resentment Associates most frequently with other amateurs who are equally confused, having less frequent contact with professionals (group griping and pity parties outweigh true learning experiences) Negative attitude rips many new ideas to shreds before they pass the incubation stage Negative associations to building business (customers are headaches, too many responsibilities, being overextended, burning out, a risky gamble, can't make money and do what I love)  
      Professional
      Crystal-clear goals, committed to writing ("Increase sales by 20% within 3 months") Deliberate cultivation of burning desire Focus on filling customer needs and providing value Accepts responsibility for poor results, seeks to understand causes and learn from them (registration incentives need improvement, product descriptions need rewriting, etc) Seeks to understand causes of poor results and learn from them Expends efforts on the most important actions (in terms of achieving goals) and finds ways to enjoy the process Abundance mentality based on law of sowing and reaping ("Givers get") Long-range time perspective used in planning, often thinking 5+ years ahead Sees problems as opportunities Persistent confidence and faith ("Success is inevitable") Balanced approach to improving multiple weak areas that detract from strengths Understands that success comes from first being (sucessful in one's thoughts), then doing (actions consistent with those thoughts), then having (results consistent with those actions) "Once I believe I'm successful, the external results will naturally follow" Strong commitment ("I will find a way or make one") Confronts brutal facts head-on ("Marketing is crucial to my business, so I must become a master marketer") Avoids unnecessary risks and bets on opportunities with the strongest chance of success while seeking to minimize the potential downside ("Releasing a new product isn't a gamble; I'll just keep refining it over time until it ultimately becomes a hit") Success stories from others are mined for new ideas and insights Networks with focused and successful professionals, learning by osmosis Associates most frequently with other focused and successful professionals, less frequent contact with amateurs (continuous flow of knowledge and ideas) Positive attitude lets new ideas incubate in imagination before putting them to the test in the real world Positive associations to building business (financial abundance, good life for family, early retirement, freedom, making people happy, fulfilling one's dreams, giving to charity, creating jobs) When results are weak, the amateur seeks security, comfort, and consolation. Amateurs want to know they aren't alone, so they find safety in numbers by holding group griping sessions in forums that attract other amateurs. Their inner insecurity makes it very hard for them to accept failure, so they're looking to put the blame elsewhere... on the failure of the shareware system, on the economy, etc. Amateurs look for validation of their position, seeking out "experts" who agree that success in their field is hopeless and that only the really lucky can succeed. When hearing of dismal sales from others, they feel more secure. Success stories are unnerving to the amateur, often making them feel anxious, envious, or resentful.
      The professional, on the other hand, is emotionally secure. The professional seeks understanding and knowledge. The professional accepts personal responsibility for his/her results and is always looking to improve. When the professional suffers a setback, s/he wants to understand the causes, assuming that the reason for failure was a lack of understanding or skill that led to mistakes. The professional will suffer failures at least as big as the amateur, if not bigger, but the professional will learn from each experience and move forward with an even stronger plan.
      You can't tell an early professional from an amateur purely by looking at a one-time snapshot of their results. The key differences are internal. Professionals and amateurs who start from scratch may begin on the same footing. After the first year their initial results may appear similar. But fast forward ten years.... Most likely the amateur will have given up and left the business or is still barely eeking out a living. Meanwhile the professional has become an established leader with a strong, sustainable income.
      So what is the essential difference between the shareware amateur and the shareware professional? It can be summarized in just one word: fear. The amateur feels vulnerable, believing that certain things might happen which s/he will be unable to handle. The amateur doesn't want to deal with products that aren't selling well, avoids facing his/her deepest inadequacies, and seeks to manage fear by clinging to the familiar and the comfortable. Instead of pursuing the greatest opportunities, the amateur pursues the safest and most comfortable paths. For instance, an amateur who feels more comfortable programming than marketing will heavily favor programming projects, whether or not that's what the business needs most. The amateur ties much of his/her sense of self-worth to external factors, and when those factors are threatened, the amateur feels a strong urge to return to the safety of the comfort zone.
      The professional, on the other hand, has internalized thoughts of security and abundance. The professional believes that no matter what happens, s/he'll be able to handle it. The professional doesn't cling to a comfort zone. When faced with change, s/he embraces it, seeks out the hidden opportunities, and charges boldly ahead. This isn't to say that professionals never feel fear; they do. The difference is that professionals turn and face their fears instead of shrinking from them.
      Amateurs will normally not be consciously aware of their fears. Such fears will be hidden behind rationalizations such as, "I simply don't like marketing," "I'm genetically disadvantaged when it comes to planning," or "I feel like a scam artist when I write sales copy." Thinking about such tasks and projects will typically make the amateur feel a sense of discomfort, anxiety, or even dread, but they often won't consciously know why. When confronted about these shortcomings, the amateur will often become emotional, sarcastic, and defensive. But whereas the amateur addresses this problem by getting defensive and shrinking back into the comfort zone, the professional lets go of his/her ego and strives to become consciously aware of his/her fears, driving them into the open where they readily dissolve. A professional says, "I probably feel uncomfortable marketing right now because of my lack of experience, but I know other people who happen to love marketing. I'll talk to them to see what they like about it, get some book recommendations, and within a few years, I'll be outstanding at marketing as well." Alternatively, a professional might hire or partner with someone else who has the skills s/he lacks, but the decision will be made out of awareness of this deficiency, not from fear and denial.
      These models of the amateur and the professional are abstractions of course. Between them lies a continuum where real people can be found. Hopefully you'll find the contrasts between these two poles helpful in continuing your own professional development.
       
      Steve Pavlina is the CEO and founder of Dexterity Software and writes and speaks on software and computer gaming industry topics regularly. This article is Copyright © 2002 by Steve Pavlina.
    • By Dyonisian
      Note: This article was originally published on LinkedIn.  If you enjoy my article, please click through and consider connecting with me.
       
      Can programmers art? How far can creativity and programming take you?
      I have summarized what I learned in several months into 7 key techniques to improve the visual quality of your game.
       
      "Programmer art" is something of a running joke. For those unfamiliar with the term, it refers to the "placeholder" or "throw-together" art that programmers tend to use while developing games.
      Some of us don't have the necessary artistic skills, however, sometimes we just can't be bothered to put in the effort. We're concerned about the technical side of things working - art can come later.
      Here's what this usually means -

       
      I worked on a game jam with some new people a few months ago. I just wanted to make sure that my gameplay and AI code was doing what it was supposed to do. This would have to interface with code from other teammates as well, so it was important to test and check for bugs. This was the result.
      That's not what I'm going to talk about today though.
       
      I'm going to take a different angle on "programmer art" - not the joke art that programmers often use, but the fact that there's a LOT that a programmer can do to improve the visual appeal of a game. I believe some of this falls under "technical art" as well.
       
      My current job kind of forced me to think in this capacity.
      I was tasked with visualizing some scientific data. Though this data was the result of years of hard work on the part of scientists, the result was unimpressive to the untrained eye - a heap of excel files with some words and numbers.
      There are very few people in the world who can get excited by seeing a few excel files.
      My job? To make this data exciting to everyone else.
      My task was to visualize connectome data for a famous worm known as C. Elegans, made available by the wonderful people working on the OpenWorm project.
      Part of the data parsing to read and display the data as a worm's body with neurons on it was done by my teammate. My main task was to improve the visuals and the overall graphical quality.

       
      The first thing that comes to mind is using HD textures, PBR materials and high-poly models. Add in a 3D terrain using a height map, some post-processing and HDR lighting, and BOOM! Gorgeous 3D scene. I'm sure you've all seen loads of those by now.
      Except, almost none of that would really help me.
      The idea was very abstract - neurons and connections visible in a zoomed-in, x-ray-like view of a worm. I don't think rolling hills would have helped me much.
      I had no 3D modelling skills or access to an artist - even if I did, I'm not sure what kind of 3D models would have helped.
       
      As a result, what I've made isn't a gorgeous 3D environment with foliage and god-rays and lens flares. So it's not applicable in every case or the perfect example of how a programmer can make a gorgeous game.
      But, it does provide a distinct viewpoint and result. The special sets of constraints in the problem I had to solve led to this.
      So here's what I actually did:
       
      The 7 things I did to improve the visuals of my Unity game
      1. Conceptualizing the look
      This could be considered a pre-production step for art or any visual project. Ideally, what should it look like? What's the goal? What are your references?
      In this case, the viewer had a hologram-like feel to it (also there were plans to port it to a HoloLens eventually). I liked the idea of a futuristic hologram. And the metaphor of "AI bringing us towards a better future".
      So what were my references? Sci-fi of course!
      My first pick was one of my favourite franchises - Star Wars. I love how the holo-comms look in the movies.

       
      Holograms became a key component of my design.
      This is a HUD design from Prometheus that I found on Google -

       
      In this case, the colours appealed to me more than the design itself. I ended up basing the UI design on this concept.
       
      Key takeaway - Your imagination is the very first tool that helps you create impressive art. Use references! It's not cheating - it's inspiration. Your references will guide you as you create the look that you want.
       
      2. Shaders can help you achieve that look 
      I had some shader programming experience from University - D3D11 and HLSL. But that work had been about building a basic graphics engine with features like lighting, shadows, and some light post-processing. I had done some light Shader programming in Unity before as well.
      What I really needed now was impressive visual effects, not basic lighting and shadows.
      I was really lucky that this was about the time Unity made Shader Graph available, which made everything much easier. I can write Shader code, but being able to see in real time what each node (Which can be considered a line of code) does makes it so much easier to produce the effects you want.
      I familiarized myself with all the samples Unity had included with this new tool. That wouldn't have been enough though. Thankfully due to my previous experience with Shaders, I was able to make some adjustments and improvements to make them suit my needs.
      Some tweaking with speed, scaling, colours, and textures led to a nice hologram effect for the UI panels.

       
      I wanted the viewer to feel good to interact with as well, and some work implementing a glow effect (alongside the dissolve effects) led to this -
       
      Key takeaway - Shaders are an extremely powerful tool in a Game Programmer's repertoire. Tools like Unity's Shader Graph, the old Shader Forge asset, and Unreal's material editor make Shaders more accessible and easier to tune to get the exact look you want.
      PS - Step 5 below is also really important for getting a nice glow effect.
       
      3. Visual Effects and Animations using Shaders
      I was able to extend the dissolve and hologram shaders to fake some animation-like visual effects.
      And a combination of some timed Sine curves let me create an animation using the dissolve effect -
       
      The work here was to move the animation smoothly across individual neuron objects. The animation makes it look like they're a single connected object, but they're actually individual Sphere meshes with the Shader applied to them. This is made possible by applying the dissolve texture in World Space instead of Object Space.
      A single shader graph for the neurons had functionality for colour blending, glow, and dissolve animation.
      All of this made the graphs really large and difficult to work with though. Unity was constantly updating the Shader Graph tools, and the new updates include sub-graphs which make it much easier to manage.
      Key takeaway - There is more to shaders than meets the eye. As you gain familiarity with them, there are very few limits to the effects you can create. You can create animations and visual effects using Shaders too.
       
      4. Particle systems - more than just trails and sparks
      I have no idea why I put off working with the particle systems for so long!
      The "neurons" in the viewer were just spheres, which was pretty boring.
      Once I started to understand the basics of the particle system, I could see how powerful it was. I worked on some samples from great YouTube tutorials - I'm sharing a great one by Gabriel Aguiar in the comments below.
      After that, I opened up Photoshop and experimented with different brushes to create Particle textures.
      Once again, I referred to my sources of what neurons should look like. I wanted a similar look of "hair-like" connections coming out of the neurons, and the core being bright and dense.
      This is what it looked like finished, and the particle system even let me create a nice pulsating effect.
       
      Part of my work was also parsing a ton of "playback data" of neurons firing. I wanted this to look like bright beams of light, travelling from neuron to neuron. This involved some pathfinding and multi-threading work as well.
       
      Lastly, I decided to add a sort of feedback effect of neurons firing. This way, you can see where a signal is originating and where it's ending.
       
      Key takeaway - Particle systems can be used in many ways, not just for sparks and trails. Here, I used them to represent a rather abstract object, a neuron. They can be applied wherever a visual effect or a form of visual "feedback" seems relevant.
       
      5. Post-processing to tie the graphics and art together
      Post-processing makes a HUGE difference in the look of a game scene. It's not just about colours and tone, there's much more to it than that. You can easily adjust colours, brightness, contrast, and add effects such as bloom, motion blur, vignette, and screen-space reflections.
      First of all, Linear colour space with HDR enabled makes a huge difference - make sure you try this out.
      Next, Unity's new post-processing stack makes a lot of options available without impacting performance much.
      The glow around the edges of the sphere only appears with an HDR colour selected for the shader, HDR enabled, and Linear colour space. Post-processing helps bump this up too - bloom is one of the most important settings for this.
      Colour grading can be used to provide a warm or cool look to your entire scene. It's like applying a filter on top of the scene, as you would to an image in Photoshop. You can completely override the colours, desaturate to black and white, bump up the contrast, or apply a single colour to the whole scene.

       
      There is a great tutorial from Unity for getting that HD look in your scenes - if you want a visible glow you normally associate with beautiful games, you need to check this out.
       
      Key takeaway - Post processing ties everything together, and helps certain effects like glows stand out.
       
      6. Timing and animation curves for better "feel" 
      This is a core concept of animation. I have some training in graphic design and animation, which is where I picked this up. I'm not sure about the proper term for it - timing, animation curves, tween, etc.
      Basically, if you're animating something, it's rarely best to do it with linear timing. Instead, you want curves like this -

       
      Or more crazy ones for more "bouncy" or cartoon-ish effects.
      I applied this to the glow effects on the neurons, as I showed earlier.
      And you can use this sparingly when working with particle systems as well - for speed, size, and similar effects. I used this for the effect of neurons firing, which is like a green "explosion" outwards. The particles move outwards fast and then slow down.
      Unity has Animation Curve components you can attach to objects. You can set the curve using a GUI and then query it in your C# scripts. Definitely worth learning about.
      Key takeaway - Curves or tweens are an animation concept that is easy to pick up and apply. It can be a key differentiator for whether your animations and overall game look polished or not.
       
      7. Colour Palettes and Colour Theory - Often overlooked
      Colour is something that I tend to experiment with and work with based on my instincts. I like being creative, however, I really underestimated the benefits of applying colour theory and using palettes.
      Here's the before -
       
      Here are some of the afters -
       
      I implemented multiple themes because they all looked so good.
      I used a tool from Adobe for palettes, called Adobe Colour - link in the comments.
      I basically messed around with different types of "Colour harmony" - Monochrome, triad, complementary, and more. I also borrowed some colours from my references and built around that.
      Key takeaway - Don't underestimate the importance of colour and colour theory. Keep your initial concept and references in mind when choosing colours. This adds to that final, polished look you want.
       
      Bonus - consider procedural art
      Procedural Generation is just an amazing technique. I didn't apply it on this project, but I learned the basics of it such as generating Value and Perlin noise, generating and using Height maps for terrains, and generating mazes.

       
      Procedural art is definitely something I want to explore more.
      A couple of interesting things (Links in the "extra resources" section below) -
      Google deepdream has been used to generate art. There's an open-source AI project that can colour lineart. Kate Compton has a lot of interesting projects and resources about PCG and generative art. I hope this leads to tools that can be directly applied to Game Development. To support the creation of art for games. I hope I get the opportunity to create something like that myself too.
      Conclusion
      These 7 techniques were at the core of what I did to improve the visual quality of my project.
      This was mostly the result of the unique set of constraints that I had. But I'm pretty sure some famous person said: "true creativity is born of constraints". Or something along those lines. It basically means that constraints and problems help channel your creativity.
      I'm sure there is more that I could have done, but I was happy with the stark difference between the "before" and "after" states of my project.
      I've also realized that this project has made me more of an artist. If you work on visual quality even as a programmer, you practice and sharpen your artistic abilities, and end up becoming something of an artist yourself. 
       
      Thanks for reading! Please like, share, and comment if you enjoyed this article.
      Did I miss something obvious? Let me know in the comments!
       
       
       
       
       
      Extra Resources
      OpenWorm project
      Great tutorial by Gabriel Aguiar
      Unity breaks down how to improve the look of a game using Post processing
      Another resource on post-processing by Dilmer Valecillos
      Brackey's tutorial on post-processing
      Adobe Colour wheel, great for colour theory and palettes
      An open-source AI project that can colour lineart
      A demo of generative art by Kate Compton
       
      Note: This article was originally published on LinkedIn. If you like it, please click through, get in contact, and consider connecting.
    • By JoAndRoPo
      Hi! 
      I hope this is the right area in the forum to post this question? 🤔 
      There are games with clear data and restore purchases in the settings page. 
      Question#1: What all does get cleared when clicking on clear data? Does this only clear player statistics & player experience? What about things that the player has purchased with in-game currencies (Can this be an option placed from the developers end? Question#2: What does get restored when clicking on restore purchases? Will it restore everything that the player has purchased with real currency?   I have a basic idea on what these 2 features do but would also like to know of all the possibilities available?
      Thanks!
       
       
×

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!