Search the Community

Showing results for tags 'Management'.



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

  • News

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Audio Jobs
  • Business Jobs
  • Game Design Jobs
  • Programming Jobs
  • Visual Arts Jobs

Categories

  • GameDev Unboxed

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
    • Critique and Feedback
  • Topical
    • Virtual and Augmented Reality
    • News
  • Community
    • GameDev Challenges
    • For Beginners
    • 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
  • Workshops
    • C# Workshop
    • CPP Workshop
    • Freehand Drawing Workshop
    • Hands-On Interactive Game Development
    • SICP Workshop
    • XNA 4.0 Workshop
  • Archive
    • Topical
    • Affiliates
    • Contests
    • Technical

Calendars

  • Community Calendar
  • Games Industry Events
  • Game Jams

Blogs

There are no results to display.

There are no results to display.

Marker Groups

  • Members

Developers


Group


About Me


Website


Industry Role


Twitter


Github


Twitch


Steam

Found 15 results

  1. Hi everyone! It’s been a while… How is everyone doing? We have a lot of news for you but today we are going to talk about Web Summit! As you might already know, last week was the Web Summit 2017 in Lisbon and we were there! Web Summit First of all WOW! Ahah I think I talk for everyone when I say Web Summit was an intense experience. In the first two days we only strolled around...met new people.. attended a few conferences and we even watched a few pitches from other companies. But then day 3 came! [Dramatic music] It was 7:30am when we got to Web Summit. It was soooo early all we wanted was sleep. Around 9am people started to show up and then it’s when things got real. We had to pitch over and over again Project SpaceVille. We must have pitched about 1 thousand times? Ahaha And no I’m not exaggerating. Imagine this: standing up for 10hrs straight and always repeating yourself. Ahah It was somewhat exhausting, I won’t lie, but in the end it was a wonderful experience! We met a large number of interesting people, a lot of interesting startups and even some investors! In the end of day three, our sponsor, Startup League, organized a closing Mixer which was a great way to relax after such a long day. We’d like to thank Startup League for helping us and making us goodies. Alpha We launched a new version of the Insider Program. Unfortunately, some people have told us they have been having trouble with this new version. Screen shaking or a loading bug, might occur. If you're experiencing this, try restarting the game and don't touch anything until the game loads. If the problem sustains, let us know. We will try to solve this problem as soon as possible. Screenshot of André Soares See you soon, The FAXIME Team Follow us and keep updated at: Facebook: https://www.facebook.com/FaximeGames Instagram: https://www.instagram.com/faximegames Twitter: https://twitter.com/FaximeGames Pintrest: https://www.pinterest.pt/faximegames SoundCloud: https://soundcloud.com/faximegames
  2. A big game project contains a lot of runtime data like List of all world objects List of all players Game states Viewport ... I have to pass a lot of these data to most of my classes. So I have a huge list of parameters in every constructor. What's the best practice to avoid this mass of parameters? Is it recommended to summarize all data to one class (something like "GameData") and pass this container to all methods and classes? Is there a common name for this container in game development? I'm a bit worried, because if I pass this class to all classes and methods, I get something like a global variable. Thanks a lot for your advice!
  3. Newbie - How to start?

    Good day dear people I'm completely new here and very nervous to be honest. I started with 3D-Design at my traineeship and can slowly start with my ideas for a survival/rpg game in 3d But since I only used RPG Makers until now I wonder how is the best way to start with a game, and what I would need for that. Have a wonderful day! ^.^)/) Tootooni
  4. COMPANY AND THE PROJECT We are an indie game studio consisted of professional and friendly people. Additionally, we are a team of skilled artists and dedicated indie enthusiasts. Our current project is INT, developed on Unity Engine 5 for platforms Windows, Linux, and Mac. INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War. Please note that all of our current positions are remote work. You will not be required to travel. For more information about us, follow the links listed below. INT Official website Steam Greenlight IndieDB page Also follow social media platforms for the latest news regarding our projects. Facebook Twitter TALENT NEEDED We are looking for a serious and dedicated Community Manager, who will be tasked with providing regular community updates, and grow our fan base in preparation for our funding campaign. Duties and Responsibilities: Promote the INT Project through multiple Social Media outlets (E.G. Reddit, twitter, Facebook). Coordinate and work with our web admin to provide content directly to the website. Create regular updates with team highlights. This update will be shared to the broader community on IndieDB, Steam, and official INT website. Attend developer meetings and interact with the team and Project Lead to obtain highlights and material that can be used in updates. Map and manage social media analytics and report updates at team meetings. Manage and potentially host monthly INT Project podcast known as ‘RogueSpace’ and manage the INT Project’s twitch account. REQUIREMENTS Essential Advanced fluency in written English. Able to structure and create informative and visually attractive articles. Excellent self-management skills. Excellent communications skills, both verbal and written. Preferred Other Indie Game Developer experience. Be an avid gamer. Have played a broad collection of titles; in sync with the latest news in gaming. REVENUE-SHARE This is a great opportunity to get into the game development industry. Being an Indie team we do not have the creative restrictions often imposed by publishers or other third parties. We are extremely conscientious of our work and continuously uphold a high level of quality throughout our project. We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the year 2018. Your understanding is dearly appreciated. TO APPLY Please send your Cover Letter, CV, Portfolio (if applicable), and other relevant documents/information to this email: JohnHR@int-game.net Thank you for your time! We look forward to hearing from you! John Shen HR Lead Starboard Games LLC
  5. Hi all, I had been working on a game by myself over the last few months and decided things may go a bit faster, and I could incorporate more fresh/refined ideas into the game, if I brought a few others on board that I knew from work. Currently, I don't have any type of funding for the project (aside from maybe buying a couple licenses here or there), and have been focusing most on some of the work that can be done without a big investment - mostly story content, or doing some audio/graphics production pieces on the side. To facilitate the story development, and keep things organized, I created a wiki where anyone I give access can add ideas and modify articles (such as locations, NPC's, etc) I have been trying to meet every couple of weeks with everyone over Discord (we had agreed Wednesday night would work for us all) and initially got a lot of energy and productive discussion from the first meeting, but afterwards I haven't been able to get anyone together for a second meet. I understand that they are not obligated to meet every couple of weeks or even contribute, especially as I am not paying an hourly rate/salary at this point (we all agreed we would wait to talk about that until the project was more developed and we received funding), but I want to try to re-capture some of that energy and get people involved again. Myself, I contribute at least one or two articles to the wiki every week. I had also been trying to keep things semi-formal in meetings (I take notes and facilitate casually), but had received some feedback from one of my team members that this all 'seemed too much like a job', which I interpreted as I am asking for too much from them or being too formal (as if it was a job) I want to keep some form of organization for consistency's sake (such as a semi-regular discussion) so everyone is on the same page, and is aware of the way the story is evolving (I have provided a framework people are comfortable with, and am very open to new ideas - being very transparent and forward about this). Does anyone have ideas on how to keep people engaged and interested in the project, enough so to meet virtually every 2-3 weeks, with limited resources? Here are some things I have been trying so far, with little success: Adding content regularly, providing updates on our facebook/discord channels monthly (mixed results, fairly low view count) Following up with a group chat every 2 weeks to make sure everyone is still available for that day (mixed results, some members do not respond/open the chat) Continuing to add content on the wiki regularly (nobody logs in to see the new content) Physically meeting whenever possible (hard to get more than 1 person together, they usually only want to hang out - don't want to talk about new ideas) Pruned members who had no contributions and have not even been in contact for over a month Refrain from calling the meetings meetings (I prefer 'calibrations', as I am mostly talking about new/updated content and talking about it with people) I believe I do not have an issue with general interest in the project - some of the members had a lot to contribute and seemed legitimately interested in the first meeting - and everyone has expressed they are interested in contributing to the story
  6. COMPANY AND THE PROJECT We are an indie game studio consisted of professional and friendly people. Additionally, we are a team of skilled artists and dedicated indie enthusiasts. Our current project is INT, developed on Unity Engine 5 for platforms Windows, Linux, and Mac. INT is a 3D Sci-fi RPG with a strong emphasis on story, role playing, and innovative RPG features such as randomized companions. The focus is on the journey through a war-torn world with fast-paced combat against hordes of enemies. The player must accomplish quests like a traditional RPG, complete objectives, and meet lively crew members who will aid in the player's survival. Throughout the game you can side and complete missions through criminal cartels, and the two major combatants, the UCE and ACP, of the Interstellar Civil War. Please note that all of our current positions are remote work. You will not be required to travel. For more information about us, follow the links listed below. INT Official website Steam Greenlight IndieDB page Also follow social media platforms for the latest news regarding our projects. Facebook Twitter TALENT NEEDED We are looking for a serious and dedicated Public Relations Manager, who will be tasked with providing regular community updates, and grow our fan base in preparation for our funding campaign. Duties and Responsibilities: Promote the INT Project through multiple Social Media outlets (E.G. Reddit, twitter, Facebook). Coordinate and work with our web admin to provide content directly to the website. Create weekly updates with team highlights. This update will be shared to the broader community on IndieDB, Steam, and official INT website. Attend developer meetings and interact with the team and Project Lead to obtain highlights and material that can be used in updates. Map and manage social media analytics and report updates at team meetings. Manage and potentially host monthly INT Project podcast known as ‘RogueSpace’ and manage the INT Project’s twitch account. REQUIREMENTS Essential Requirements: Advanced fluency in written English. Able to structure and create informative and visually attractive articles. Excellent self-management skills. Excellent communication skills, both verbal and written. Preferred Requirements: Be an avid gamer. Have played a broad collection of titles; in sync with the latest news in gaming. Other Indie Game developer experience. REVENUE-SHARE This is a great opportunity to get into the game development industry. Being an Indie team we do not have the creative restrictions often imposed by publishers or other third parties. We are extremely conscientious of our work and continuously uphold a high level of quality throughout our project. We are unable to offer wages or per-item payments at this time. However revenue-sharing from crowd-funding is offered to team members who contribute 15-20 hours per week to company projects, as well as maintain constant communication and adhere to deadlines. Currently the crowd-funding campaign is scheduled for the year 2018. Your understanding is dearly appreciated. TO APPLY Please send your Cover Letter, CV, Portfolio (if applicable), and other relevant documents/information to this email: JohnHR@int-game.net Thank you for your time! We look forward to hearing from you! John Shen HR Lead Starboard Games LLC
  7. World of Shinobi

    Game Concept Doc: https://docs.google.com/document/d/1B5eS_eGMke3gk5xPyMLekZY1T7uE2q1pO4vFdALIOC8/edit We are looking for every position. From Game designer, to marketer, to programmer, to 3D modeler. Any further questions can be discussed through discord DISCORD: Gator#5635
  8. Hello, this is my first post, and originally I wasn't going to even join this community, but I thought it would be a good idea. Especially because the people at Reddit ignored my post completely. Being a Minor (I am about to be a sophomore in high school), I have about three years of coding experience. I also have been composing music, and I have many friends who do many other things that happen to coincide with game development (I will get to this next). Currently, me and two friends are wanting to start a development company. I have had a good amount of experience in Unity, and I am well versed with JavaScript, as well as learning C#. I have a friend who does a lot of art and pixel art, who also is well versed in JavaScript (no experience in anything other than Pocessing.js) and a friend who has the same if not more experience with JavaScript, as well as advanced GameMaker skills. In terms of technology, coding levels, music, art design, and pretty much everything else that actually creates the full game experience, we are set and ready to go. The problem is legal issues. My parents are not too fond of me starting a company now, because they think school is more important (I go to a special program at my school, which is similar to STEM mixed with avid, but includes all classes, which I could easily do this for projects), and legally, none of us are old enough to actually create a company (I have researched into LLC's, DUNS Numbers, Apple Developer, and a lot of the other publishing/marketing stuff we'd need for a company and actually publishing the apps). I know, if we continue, we will probably need legal advice from an actual attourny (especially because laws vary by state so a lot of information might not be correct on the internet), but I was wondering if any of you either have experience starting a company/software development company as a minor, or if any of you know anything that might help us on our endeavor legally so we can have our own business. We already have options of people who are above 18 who will help us with this and will more than likely help us with being the legal organizer of the company, but other than that, we are a little blind. If you have any information that would be helpful, that would help us so much! Illegal Seagulls LLC (Hopefully at least!)
  9. I have written a game client, server, and world designer. I need people that want to help create the world. I am making no money off this yet. It is a top down view Diablo style playing game where the player can also switch to a 3rd person view if they want. The game is done and being played but it needs more content. In order to get people interested in helping, what arrangements do people think are good? I was thinking of keeping track of work done and then paying out once the game starts making money. So someone designs a dungeon and we agree it is worth $300. Then when the game starts making money a % of that is divided between all people or teams that made contributions. Problem: Some people will not spend the time needed for good design work.
  10. Imagine there's a team of 4, consisting of an investor, a coder, a graphics designer, and a sound designer. What percentage of the end profit should each person get? What if there was another guy for 3d modeling? And what if there was multiple guys doing one part of the job, would they collectively get the percentage that that job gets? I mean, imagine there is 1 investor, 1 graphics designer, 1 sound designer but 3 coders. If 1 coder (like in question 1) would get 25%, would this number be divided among all the coders, or will the number rise?
  11. Hi guys, I'm junior engineer and I have one goal in mind: I'd like to beat my current net salary (40-60k)  in the time frame of 24 months, by starting a solo part-time business, which would over time hopefully grow into full-time activity. Let me point out that the business would be primarily profit-oriented, which means that the 1st priority is to generate targeted amount of income, followed by "doing what I like to do". I have thought about game development being one possible business to achieve my goals. And before you jump on me that I'm trying to do something without any experience,  I'm able to tell you, that I'm not entirely unexperienced in the field of game development. In fact, As a hobbyst I have developed handful number of small flash games, covering the art, programming, game design and sound production by myself, so the whole idea - at least from the standpoint of implementation of a small 2D game - might not be that much of wishful thinking. In addition, during my studies I was also developing C# apps in the scope of enterprise solutions, in order to earn some pocket money.  In regards to game development I have done some googling, which suggested, that game development market is business-wise, almost the same as music production market - overly saturated, high entry barrier, high probability to fail, and for most of the producers, a mediocre payment accordingly to requirements. In business terms, this might be labelled under high-risk/low-reward business. Or in other words,in game development I might have as much chanches to earn 40-60k NET a year as I would have in music production. What is your consensus about this? CLIFFS OF THREAD:
  12. Hi all, I'm reaching out to sanity check my decision processes and see if there are any gaps. I've got a game developer creating a VR game for me. While I'll continue my relationship with them, I want to start building the capabilities in-house to create and launch VR games. Team that the supplier has: CTO, creative director, 1x game artist, 2x Unity developers and 1x audio engineer. There is obviously the CEO and their overall PM. I usually deal with CTO and creative director. The question is about the approach I should take to build out a team. I have technology expertise but not game development. Therefore, I think two key hires are creative director and CTO. Both should have launched games and then they build out the team based on the deliverables for the year. Any advice on what the seed team should be? Or perhaps even if I should be asking a different question? Appreciate any help you can offer.
  13. To understand where I'm coming from, let me explain my situation. I have a project in the early works. One of my main features is allowing a player to create his own game world to play in, all the way to atmosphere control (lighting, fog, ambient noise, etc). Iwant to give preset values for these that create "common" atmospheres. For example, "Clear morning," or "evening mist" etc. Being color blind, I don't feel I'm the right person to say "yep, those are the appropriate mixtures of color for that!" God forbid my gray fog actually be pink:-) So,knowing that, I have a few people I've shared my project with that are excited for it, and would be willing to test out the settings to find good preset values... how could I legally accept this sort of volunteer help without being bit in the rear should I be fortunate enough to later profit from the game? I have no problem offering compensation to those who donate substantial help, but this is comparatively minor, and I feel giving them a free copy of the completed product would be sufficient. Is there any standard way to formalize an agreement that either: 1) this work is strictly voluntary and I'm not obligated to pay, or 2) the fact I'm going to give you a free copy of the game on completion IS fulfilling that obligation?
  14. 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": 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] 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 completely 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. 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: 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: 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. 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? 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. :-) 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: They can't see it They can't play it They can't help with it They don't know how games are even made They have no idea if what I am making is good, bad, or both 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. To really dig into the reasons why would be another article, so I'll just jump to the conclusion: Some days, you get stuck making soup. :-) Being at home and dealing with kids ranges from playing ball (short) to trips to the emergency room (long) 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? 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. 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 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) 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.
  15. Getting Games Done

    Get Games Done This article is aimed at hobbyists/indie developers with limited spare time to dedicate to their projects. It seeks to help them increase their motivation (and finish their projects) all the while improving their working environment setup and productivity. From past experiences, I have learned that the single most important factor to get games done lies with the ability of the developer to deliver increments of functionality at a steady pace. Essentially, a project will only get done if an external eye to the project sees consistent progress throughout longer periods of time. The odds of succeeding are also generally tied with the ability to deliver these increments at more or less regular intervals. There are many reasons why a developer that sets out with the best of intentions will end up being unable to deliver functionality over time, and these reasons will end up killing the project. Rather than discussing the symptoms here, I'll explain my way of overcoming them. Implementing a Development Routine (5,1,1 Routine) To establish sustainable development over long stretches of time, a developer needs to have a routine. This mental construct will initially be forced, and eventually become a habit, so that the majority of threats endangering the project will be met with fierce and effortless resistance. Different developers will prefer different routines, of course, so bear in mind this works for me and may not work for you. However, the idea of a Routine remains universal. I call mine the "5,1,1 Routine"... I accidentally created the 5,1,1 Routine during one of my hobby projects, and decided to stick with this method as it allowed me to meet three very important objectives: Remain motivated with the project by working on fun features most of the time. Deliver shippable increments of functionality regularly (sustained velocity). Perform a constant health check of my code with limited effort. What is the 5,1,1 Routine? The 5,1,1 Routine is a representation of the workload in a given week in regards to three axes. 5 Dev Days... (I deliver a new feature or improvement) 1 Refactor Day... (I clean up and optimize the code) 1 Rest Day... (I don't look at the project) What are Dev Days? This methodology assumes that my code base is healthy enough to allow me to develop new aspects of the game five days per week, which is what will keep me motivated to continue my work on the project. During these five days, I will develop new features with the quickest possible route in mind, regardless of how "unclean" it will look. The reason for this is twofold: We're developing an entertainment product (game), and fun is hard to catch. Rarely will the first implementation feel right, therefore it's better to be able to try several messy ways in a single day than to try a single clean way. These dev days are meant to keep my motivation high. The fun comes from seeing new things working in my game, not from clean code. The more new stuff I get to try, the more excited I get about the project as a whole. I don't feel wrong because I know that 90% of the things I'll try will end up being discarded, thus won't harm my code base much at the end of the day. Usually, I'll want to deliver something new EVERY day. To achieve this, I like to keep the JIT / DWYN attitude. JIT (Just-In-Time): While generally employed to relate to inventory, one can correlate this with information flow in regards to decision-making. Essentially, postpone any technical decision until later. Code your new feature quickly and don't have any foresight about how it can be reused (you can always use your refactor days for that anyway). Do what you need (Lean): A good way to prevent over-engineering, this tells you to code exactly what you need and nothing more. When you refactor later or need to build a more complex mechanic that leverages the same logic, you can always revisit, but assuming that you will and over-engineering will result in tremendous amounts of time loss. What is a Refactor Day? If you've been developing for a while, chances are you've quit on many projects solely because they reached a point where it would take too long to implement any new idea. This can be explained as technical debt. Though I spend five days per week adding stuff without caring much about how clean the code is, I discipline myself into adding an extra day per week where I am not allowed to develop anything new, and rather, I seek only to clean up my code base, refactor, etc. In other words, I deal with my technical debt. Note that I use the term discipline to represent that I not only force myself to refactor but that I allow refactoring a very specific amount of time. This allows me to ensure I do enough refactoring so that I can maintain my development velocity, but not too much refactoring, which would pointlessly halt development altogether. This is used as a means to prevent me from falling into either the prototyping mood (which can never amount to shipped large scope projects) or the coder's mood (where the technological thrill outweighs the goal of delivering a game). In the methodology known as Test-Driven Development (TDD), the goal is to reach a functional state as quickly as possible and then refactor. This is usually done within a few minutes. In 5,1,1, this Routine is stretched across a development cycle of a week. The other advantage of having a sixth day dedicated to refactoring is to keep a general understanding of the project. Since I spend five days looking at the new code, I don't want to lose sight of what the rest of the code base looks like, and how I can find ways to optimize/refactor. It also ensures that I'm still familiar with the codebase when I get back to development on the next Dev day the week after. I used to be the kind of developer that tried to get things done through weekend development sprees believing that having longer stretches of time would be more beneficial as my concentration would be easier to muster. It turns out that the amount of concentration required to undergo these sprees is largely due to forgetting a lot about the codebase in-between sprees. As a result, I find a lot more value in spacing that development time across a week and retain a constant understanding of the codebase. For more information on refactoring (and clean code), see ">this video. I went to college with this guy, and he's grown into a very successful indie, so I was amazed to watch this video after completing this article. What if 5,1,1 breaks? It's entirely possible that the 5,1,1 will break, and though this is not desirable per se, it exposes any threat so that it becomes actionable. Determining that the 5,1,1 is broken is fairly simple and can be answered with a very simple question: Did I deliver an increment of functionality on each dev day? The key to 5,1,1 is to understand why the method broke, and how to fix it. One of the most common reasons for the cycle to break will be that a specific class, function or segment of code is currently in a state that makes it impossible to deliver new increments of functionality on each dev day. This could be due to code readability, unnecessary complexity resulting from multiple iterations, or any other logical issue that could be dealt with on a refactor day. When this occurs, I willingly choose to sacrifice one of my dev days and turn it in an extra refactor day (turning that specific week in a 4,2,1), knowing there's a very specific goal to be attained in order to restore my cycle. I generally refrain from using the 7th day (rest day). The rest day should, most of the time, be sacred. It is a day that keeps everything in equilibrium and allows for this routine to last. No matter how asocial one might be, there's always a time when other things need to get done, and having a routine that leaves room for this is essential. It's also a good way to stay clear from burn-outs. Ways to make refactoring fun Some developers refactor too much and over-engineer. If you are one such developer, I recommend reading this article. For the more gameplay-oriented programmers, however, refactoring is often perceived as a pain, a necessary evil, and is often cause for grief. We've already addressed a way to build up momentum and motivation by having five dev days, but unless you come to your refactoring day with a plan in mind, you're still likely to loathe it. There are various ways you can approach this, but the important thing here is to prioritize the work that makes the most sense all the while keeping your sanity above ground. My personal approach is to come with a specific goal in mind. It could be that I have identified throughout the week a very painful bit of code that I need to deal with recurrently that could be refactored into something more intuitive and easier to use. It could also be that I happen to think that I've broken enough encapsulation rules to try and fix this before it becomes spaghetti code. The key here is that your recent development cycle is still fresh in memory, so you know where you've struggled, and what you have stained with poor (new) code. Whatever the problem you may have identified, make sure that it will reduce your development time for new features. That way, you won't feel like you're shooting in the dark. Also, make sure to vary your method and focus from week to week to keep things interesting. It's a good way to make sure it does not feel redundant over longer stretches of time. Ways to make each dev day more efficient Here is a short list of tools and techniques that can help you stay focused and gain velocity. These are software that I have used in various projects. Please note that while I suggest specific software for each category, it may not be the most suitable for you, but it doesn't hurt to know where to start looking. Source Control (SVN / GIT / Perforce) I'm always surprised by developers (generally "lone" wolves) that don't use source versioning. These allow you to do many things at once with relatively little effort: Share your source code with somebody and allow more than one person to work on the project at once. Though you may not plan on having anybody else contributing to the project at this stage, it's not a given that it will never happen. Prevent data loss when your development setup unmistakenly breaks. A simple checkout will restore your project a few minutes away from where you were at. Help you establish a "system." By establishing the rules of "when to commit," you have a more healthy relationship with your development cycle. Also, when looking for free hosting for source versioning, I recommend: Assembla. Task / Bug Tracking (Trello, Assembla) As an indie, it's easy to fall prey to the misconception that it's possible for one person to "know-it-all" because of the scope of the project. Even if it were accurate, it would take such a toll on a person's memory that the impact in everyday life is not desirable. Rather, the use of tools that allow you to track tasks and ideas is preferable. I use Trello for my projects. The key here is that a simple tool allows you to do more. Trello has the advantage of being flexible (create your own workflow/categories, the ability to add checklists, etc.). Furthermore, it works on mobile, making it also good at taking notes in the context of a project (rather than in a standalone app). What I like about Trello is that it allows you to create one item (say, a feature) and break it down in many sub-checklists. This way, you can contain within a single feature the necessary logical components, the assets you might need and other requirements, the polish ideas you have along with any bug or optimization requirements you might have. Thus, your Trello board can be a collection of high-level features that display something along the lines of "Feature name - 10/93 items". Continuous Integration (Jenkins) A bit more recent perhaps than other items listed here, the concept of continuous integration is really something to delve into. It allows you to minimize the amount of time lost "building" the project and makes it simple to screen a build whenever you want. By default, it will build a version after every commit you make. Versioning might prove catastrophic at first, but you'll get the hang of it. I'll admit that I've never looked at alternatives to Jenkins. The gain I've experienced when first using Jenkins was so great that I did not bother to compare, but there may be better ways to do this out there. How to get Games Done You may follow all of the above and still not get games done. That's because while you may understand how to "get there," it's possible that you have no idea where "there" actually is. Say you want to go to Newark's airport, and I tell you it's somewhere along the New Jersey Turnpike, it's quite possible you'll end up god-knows-where along the turnpike because you have no idea what an airport looks like (arguably they've done a pretty good job at putting signs up, and well, there are planes, but without prior knowledge about what planes are it won't help you much). Making games is no exception. If you know your way around development tools and have a development cycle, it's possible you'll miss out on completing a project, despite being highly motivated. If this is your case, here are a few things to bear in mind as you define your overall development "strategy" (something you should think about before starting, and iterate on as time passes by). Have a clear idea of what you want to demonstrate What you should have at this stage is a "game vision." In simple terms, you should be able to describe the end-user experience before the software is built, knowing that some things will need to shift along the way. You should not know everything in finer details, but you need to have this sort of high-level interpretation of how it will all come together. A good way to confirm that you have a clear idea of what you want to demonstrate is to try to explain your game to a friend using as few words as possible, and yet hype them. If your friend starts saying "oh and you should do this and that..." you should probably ignore the specifics, but you'll at least know you've come up with an idea that is fertile ground. Your job then will only be to squeeze out the fun where it really is and exploit the fun-vein to a maximum. How to scope & iterate (MVP) As a game developer and designer, your role is initially to demonstrate fun gameplay. The core of your job should be to build a skeleton of the game you want to build, by focusing on its most important aspects (what makes it unique, fun, etc.). If you're not going for original gameplay, and rather focus on execution, then there should be fewer unknowns in regards to what's fun early on, but timing will still be critical. Don't assume that just because you are doing a final fantasy rip off, the same pace should be used in exploration and combat just because it worked for these games. The next logical step is to build an MVP: Minimum-Viable Product. In essence, the MVP represents the minimum your game can ever be. It's a condensed game that contains very few mechanics. However, each mechanic will be brought to complete fruition. The process to get there is to build the skeleton first. Prog-art, your prototype, check what works, what doesn't. Then iterate until this part makes sense. Then, proceed to the next core gameplay mechanic. Once each CORE gameplay mechanic feels right, hone them. Develop each of these mechanics until you feel like your game is a polished gem, with much untapped potential. Play this build over and over again and ask for feedback. THIS is your MVP. If anything happens tomorrow, you'll have at least achieved that (the minimum your game can ever be to deserve to be called a game). Instead of being a shady prototype halfway through completion of the next uber MMORPG, you'll have achieved a shippable game that may just lack depth. Why is this critical? Because from now on, you can release this game anytime you want, and you know the quality you are delivering. In fact, you knew the quality you were delivering every step of the way, never worried about whether other mechanics would feel right or not. Knowing that you can release anytime alleviates the pressure of the unfinished project and helps you keep a high motivation. It's much easier to think in terms of polishing a final product than to get everything missing for release. While you may spend the same amount of time on the game, you've had a lot more control on overall quality, always working on that which has more value and always judging of new feature's value based on their coherence with what is established. This is a mindset that takes some getting used to, but over time, it's something I've grown incapable of avoiding based on the sheer benefits of this approach. The drawback to this approach is feature-creep. Having an MVP in hand puts you in a state of mind where you need to consider the features you feel you need to add to complete the greater experience. The problem is that you might get excited about way more features than the game would normally support. There's no real rule to determine when you've entered the feature-creep lane, but if you find yourself months beyond your MVP and still have a lengthy list of things you'd like to add, consider releasing first and adding whatever you need based on user reviews instead. If the game allows it, consider metric-driven development if at all relevant. Set Deadlines Let's face it, there are many reasons not to set deadlines. This is likely a hobby project, and the truth is that you might enjoy the indefinite nature of it. I won't argue here as I have plenty of side projects of my own that don't have a set deadline. The key difference is that I did not choose to make these a priority and I did not determine I wanted to get them Done. The premise of this article is that you want to get this game done. If this specific project does not fit this criterion, you are more than welcome resuming work on it without actually applying any system or deadline. Just know that it is likely to fail/fall in an indefinite hiatus at some point. There's nothing wrong with that. As a matter of fact, it's better to toy with many ideas at once and choose to only pursue the most fun. Once you've browsed over your projects and have identified the one you really want to complete, then it's time to trade the safety you had knowing there were no "rules" for a system and actual deadlines. Deadlines shouldn't be daunting. You are not liable for a contract here as you would in the corporate world. Rather, think of deadlines as goals, ways to keep a macro idea of where you are headed. I personally like to think of my own deadlines as extremely lax and vague, but they allow me to place tangible milestones in time and give me an idea of the commitment I need to put towards achieving what I want. For example, your first milestone could be just a prototype, and it may take as many milestones as you want just to get to the MVP. Don't try to be too micro. However, you're only likely to make your milestone definition irrelevant as time passes by. Also, don't put an exact date on a milestone. Depending on the scope, a specific week or month may be enough. I personally use quarters of a year and calendar events as references ("I'll get this done before Christmas, and this somewhere in Q1 2014). You don't have to stick to your milestones if the circumstances change (if a core gameplay element isn't as fun as it should and you've chosen to take the time to fix it or find alternatives) but you should always have a broad plan of where you are headed days, weeks, months from now (task tracking helps, especially in the form of notes for "later"). The mere effort to project your project in time is what matters, not the end result. Pat yourself on the back if you meet a deadline, don't focus on the deadlines you miss and simply keep in check the reasons why you have failed. Are you overthinking things? Are you still working on the MVP? It's possible that you'll find out you've been feature-creeping. If you are, learn to let go, push these ideas through Trello instead, and focus on what needs to be done first. Perhaps you'll discover your game vision has grown blurry? Take a pause, reassess what you think the game should be, how it should feel, then resume work. It's pointless to work on fun bits of the game if they can't become part of the greater whole and feel coherent with the experience. Random Thoughts & Rants Here's a short list of practices you might want to set up. These are mostly aimed at team work environments (2+ people). Weekly Reviews One good practice is to do weekly team review. If you can afford it (even over Skype), this is extremely helpful in setting everybody's expectations straight and keeping the vision clear. It's also a good opportunity to discuss potential features, solutions to some problems, and more importantly, evaluate the level of fun resulting from the current implementation. If using the 5,1,1, you can probably do these every other Rest day. Internal Playtesting If you're working on something on your end while others work on something else, it's always good to send them something partial as you are progressing with minimal information. If possible, seeing them manipulating it is ideal, but comments can also work. It will give you an idea how intuitive what you're doing is and will grant you impressively useful feedbacks. The often forgotten effect of doing this is keeping the motivation across the team. This article does not discuss teamwork much, but it is critical to leverage each other's motivation to keep the boat afloat in larger teams (or risk chain reaction of demotivation). Experiencing what others are doing and receiving a stream of comments on what you are doing keeps the dialogue open. You need to use each other's mind as much as possible to make this the best game it can be. External Playtesting Often discarded... sadly. You need to get out there and let people play your build. Ideally, you want to see them in action (moreso than team members). Be aware of who these players are compared to your target audience (this will let you know which part of the notes you are taking will be truly relevant). There are various ways to do this which doesn't fit within the scope of this article, however. I recommend reading further on the subject of defining your target audience through the big five. Leadership (who owns what) As the team becomes larger, it's important for roles to be clear. By "who owns what," I'm not referring to the final product and legal ownership of the end-result. Rather, I'm discussing about who should have final say on what matters. The best approach I've used this far is to allow everyone to pitch into everything, but give the final say to the one most proficient with that discipline. For example, I do some programming on my projects, but it's not uncommon for my partner to have superior programming skills, and I tend to grant him the final say in everything technical. Likewise, I tend to have a clearer vision of the end product (especially when I'm responsible for initially creating the high-level concept) and like to keep final say in design matters, but not all. To keep other team members motivated on the team, I also break down the design into various features/components. For example, if making a tactical game, though the game may be my original idea, I may end up being teamed with a Tactics Ogre // Final Fantasy Tactics freak. Why not share design ownership? There may be reasons not to share this ownership, though. The important part is to make sure that ownership is clear for everyone to avoid people feeling like they are in control until denied later. Confusion on who owns what can be a real team killer as it turns out, and it's better to gauge team member's assumptions early on (and tell them outright where they might not have authority) than to lead them on until you need to squash their dreams by imposing your vision. *** If you do all of the above, you may not make a great game, but you'll at least complete it, knowing that you've completed something that is as good as you could make it. The difference if you lose hope is that you'll have something to show for instead of nothing. Putting that "decent project that could've been so much more" on your website might draw people to you, either in the form of potential players, or collaborators. Never under-estimate the value of completed projects when gauging for partners. It gives people faith in your ability to get things done, and with the number of indie developers lurking about, this is key to forming bigger teams or relationships. What you'll learn from this experience will also help you on the next project, and the next... until ultimately you release games in the state you want them to be. It can take 4-5+ projects before you get there, but hopefully, this method will make the journey less painful, and leave you with tangible proofs of your efforts. If you have your own system, let me know! I'm always curious about how other minds work, and how people manage to motivate themselves. Though my system allows me to complete games, it's not perfect, and I'm always looking for ways to further improve it. Cheers, - M