• Advertisement

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

  • GameDev Unboxed

Categories

  • Game Dev Loadout

Categories

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

Forums

  • Audio
    • Music and Sound FX
  • Business
    • Games Career Development
    • Production and Management
    • Games Business and Law
  • Game Design
    • Game Design and Theory
    • Writing for Games
  • Programming
    • Artificial Intelligence
    • Engines and Middleware
    • General and Gameplay Programming
    • Graphics and GPU Programming
    • Math and Physics
    • Networking and Multiplayer
  • Visual Arts
    • 2D and 3D Art
    • 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

Developers


Group


About Me


Website


Industry Role


Twitter


Github


Twitch


Steam

Found 24 results

  1. Hey guys, does anyone have any recommendations please for companies offering Community Management/Marketing services? I'm quite price conscious, so if you know which ones are cheaper/expensive/how much they charge, for a small/medium sized developer? Thanks
  2. I am animator by hand, and i am doing game animation for at least 8 years so far. During the last 2 years, i came with a idea for game and maybe some day, i want to start indie game company. As i am thinking to start game company, i am also thinking what kind of value i can give to the company. For example, am experience in animation,sales(I was selling web development services, before i jumped to gaming), bit of rigging- just not for production, i am learning on the side as well. The rest of the gaming production, like modeling, concept art, texturing, i am total noob or to say better, i am no near interest to do modeling for example, don't have such a patience to do it. But before characters and things are made for animating, what the hell i am would do? Also, what is the ideal size of the founding team of a game company? Positions to be filled mostly are, Concept artist, Modeler/Texture artist, programmer, animator-rigger. And later would need more people to join, like more animators, programmers, sound, fx,etc. And lastly, do i need to have something,like a prototype, to show people and get them interest, or should i ask someone i know, for skill that i lack, for example, Modeling would be great, texturing and rigging, and to start all together from scratch?
  3. Contract Work

    I need to make money to fund the further development of my game. So, I've been doing paid contract work in VR. Most of the work is pretty easy for me and consists of producing VR applications which run 360 videos with some interactive GUI elements embedded into it. I also have been helping other game developers produce their games. Initially, I charged $50/hour for my early VR programming work. I believed that I needed to figure out the development process and it would take a bit longer because it was new to me, so I felt bad charging a higher rate. I got it figured out now, so I raised my rates to $75/hour. I... think I made a mistake. The way I came up with $75/hour is pretty straight forward. I took my previous annual salary and divided it by the number of hours in a full working year, and that gave me a rough ballpark on my hourly rate. The flaw in this approach is that I was assuming that the amount of work I have would be constant, that I would be working a full 40 hours a week with billable hours. The reality is that I have huge gaps between projects, so that means I have huge gaps between billable hours. So, the general intuition would be to increase my hourly rate, right? I think that's also a mistake. The problem is that I've gotten too fast. It used to take me something like 10 hours to produce a 360 VR video app. That's because I built it from scratch. Now, I have a code base and template I reuse. It takes me about 2 hours to produce a simple video app. With an hourly fee structure, it's more profitable for me to work slow so I can charge higher bills. But I can't do that, I'm an honest man and my integrity is priceless to me. I'm also a lazy engineer which causes me to strive for efficiency so I don't have to do tedious, wasteful work. Spending 10 hours on a 2 hour project would feel like a waste of time and an antithesis to common sense. So, I'm tentatively thinking that the correct fee structure is to charge a per project cost. If I quote someone for $5000 to complete a project, that's what I'll charge regardless of how long it takes. If I can finish the project in 5 hours, congrats, I just made $1000/hour. If it takes me 50 hours, then I made $100/hour. Now, I'm properly incentivized to work fast and efficiently. The faster I work, the more rewarding it is. This comes with some risks as well. What if I estimate that a project will take 15 hours, bid accordingly, but it really takes me 30 hours to complete? I'm making another mistake here... I'm not taking profit into account. If I step outside of myself for a moment and pretend that I'm an employee to myself, and employees are paid an hourly rate (let's say $75/hour) and I'm bidding on the cost of a project based off of just my raw production costs, then I make $0 in profit. All of the income goes directly into paying for the employee salaries, leaving nothing for the company, meaning growth is impossible and I lose money over time due to overhead costs. Instead, I should be taking the employee salary ($75/hour) and multiplying it by a factor of at least 2.5x. If I replace myself with a hired employee and keep the same fee structure in place, then the company is equally profitable because I am interchangeable with other workers. If I add more workers to the team, then of course my bid estimates will change. So, the total bid = sum of all wages * 2.5x; For clients, this could be a pretty good system as well. Instead of having runaway costs inflate a project budget, there is a fixed cost of production. My biggest challenge will be to accurately estimate the scope of work and bid accordingly. If I underestimate the scope, then I eat the cost difference. If I overestimate the scope, more profit, more reward! But then, I also come full circle to the original problem I had: If I originally took 10 hours to finish a project and bid accordingly based off of that time estimate, but through experience, innovation and increases in efficiency I now reduce that same work to 2 hours and bid accordingly, I would still be losing the hourly difference. So, do I bid as if I'm starting everything from scratch because my competitors would be in the same position? Or do I look at the requirements of a project and use that as an input parameter into a piece-wise defined function to assess estimated cost? Or, do I just pick high numbers in a random ballpark and hope to get lucky? Obviously, if requirements change, then the cost should change proportionately as well. If I charged a flat $10,000 for a project given its requirements / feature spec, and then a few weeks later the client decides to add/subtract a requirement, how would I figure out how to proportionately adjust the pricing to reflect the change in scope? I... don't... know... One other thing I'm finding annoyance at is that some clients aren't good clients to take on. Indies and startups are bad because they often don't have money, no matter their good intentions and promises. If it's going to break the bank for them to have me work for them, it's likely they'll be unable to pay me or that it will take 6+ months for me to get paid. I owe people money, I can't keep them waiting because I'm waiting to get paid. If they're sweating over my up front fee of $150, I shouldn't take them on as clients. My policy should be, "If I think they can't afford me, they can't afford me.". It may be better to risk leaving money on the table than taking on bad clients. Maybe I should increase my fee to weed them out? Another factor I hadn't considered are the non-billable hours I put into project efforts: Responding to emails and answering phone calls. On some projects, I've put more hours into phone calls, conversations and emails than actual, billable hours. Now, I want to be a nice person and to be easily accessible to my clients, but every hour I spend on email or phone calls is an hour I'm not spending making money. Every hour I'm not making money is also an hour I'm not working on Spellbound. I'm tempted to charge for my time here, but I don't want to start a stopwatch every time my phone rings or I get an email requiring a response. Maybe I should just pad my estimated hours to account for time spent communicating? Or maybe I should measure the average amount of time I spend doing administrative stuff on behalf of a project, and adjust my multiplier accordingly? Instead of a 2.5x hourly rate, maybe 3.5x? The last few factors I also hadn't been considering is that I'm a freelancer, with talent and experience, ready to hit the ground running, today. I'm not an employee, so I don't get "company benefits". No medical. No dental. No vision. No retirement fund matching. No overhead costs (HR, managers, office space, parking, cafeterias, admin staff, etc). When the project is complete, I am done and go away -- an employee would still incur costs afterwards. No employee liability. Don't like me or my work? Fire me, no mess, no HR hassle, no legal wrangling. That means I have to pay for all of that stuff out of my own pocket, so I need to charge more as a contractor. My girlfriend has taken ample opportunities to remind me that I'm not charging enough. She told me that based on my skill set, I would be equivalent to a "technical editor" in the Hollywood film industry, and they charge something like $175/hour. Based on my background and experience, and how niche my industry is, she believes I should be charging at least $300/hour. That... makes me a bit pale to consider as an hourly rate. I have a hard time believing I'm worth it. But hey, if I can complete a project in hours which would take other people 5-10x longer, if not more, than maybe I am worth it. I recently went and visited a motion capture studio near my office to figure out how I can use them and what their rates are. They charge $3750 for 4 hours, or $8000 for 8 hours. That's a lot of money for a poor indie like me, but... really, it's not a lot of money at all when you think about it. I should be charging roughly in that ball park, right? Deep down inside, I think I feel afraid to charge a lot of money for what I do. But I think I need to reframe the way I think about this. People aren't hiring *me*, they're hiring *my production company*, and for now, I just happen to be the sole employee. If I staff up in the future, I wouldn't feel bad charging high rates to cover my costs. But staffing up would also mean I have to dedicate a significant chunk of time towards staff training, and I'm capable of training staff, so... that means I'm pretty good, right? I guess I just see the work that I do as "easy" and "enjoyable" and I shouldn't be getting paid for this. But, the work is only easy for me because I've got 18 years of experience and the projects I take on are 10x easier than writing my own game engine from scratch, or building enterprise systems for the military. Truly, the biggest risk for me is that the work is such a cakewalk for me that I am bored by it. I was realizing this afternoon that I'm most incentivized to work on other peoples' projects when I'm getting paid really well for them. $75 per hour is not enough money to motivate me to overcome my boredom, but $150/hour is. My girlfriend also tells me that I'm terrible at business, that I don't really have the head for it. I half believe her because she's a lot more experienced than I am, and she's bringing in a lot more money than I am. I've been thinking carefully about what I'm currently doing, how it's not profitable, and what I need to do in order to make my work profitable and worth my time. With my current flow of contract work and my billing rates, I don't make enough money. Honestly, it's just barely enough to pay my cheap office rent. I'm practically treading water, getting nowhere even though I'm working hard. For the last few weeks, I've been thinking that I need to get more proactive about getting money. I need to get out of my chair, put on a nice dress suit, take my VR goggles, and go door to door at every company and show them what I can do for them and how it can help their business. I need to figure out my sales pitch, refine it, and go get myself some big work. I believe in VR, I think its the future, I am bullish on its prospects, and I can sell. I have proven to myself that I have the personality and capability to sell, I can build what I sell, so... I should just get up and go do it. I'm optimistic that I could do well, but I'm sort of holding myself back somehow. The dream is that I do well enough at bootstrapping that I can work myself out of every job and become more of a CEO/producer type, hiring people to replace me. Programmer? Hire that out. Sales guy? Hire that out. Film guy? Hire that out. Hire people for everything -- delegate -- don't get my hands dirty, don't get into the weeds. If I do, I'm still doing it wrong. While I'm fully capable of writing code and producing everything myself, I can't scale. I would be just one guy, taking on projects with a scope of what only one guy can complete. Big projects = big money. I also sort of think that I should split my time 50/50 between providing services to clients and creating my own software applications and releasing them online. The problem with exclusively doing work for clients is that it fixes my scalability to whatever workload my production company can handle. My throughput is fixed, and thus my income is limited by my throughput. It would be a trap which limits my growth potential. However, if I build and release my own apps at the same time, my growth potential is limited only by my marketing and sales capabilities. Once an app is completed, I can make an infinite number of copies in an instant and sell them. If I diversify and make several apps in several different market categories, a few of them are bound to succeed. I have been particularly infected by an idea which could potentially establish a new market category for content in the VR market (I'll share details after I execute). If I can produce it, market it, and sell it, and it thrives, then I could scale it out and go big. I'm planning on creating a working prototype this spring and releasing it to the market to see how it fares. Anyways, the point is that it would be easier to make $1m by scaling out a successful app than by scaling out client services, but a successful app could also be an additional service category offered to clients. However I do it, I will fund the production of Spellbound and I will have a well funded team working on it...eventually. Anyways, I did something cool the other day. I integrated Leap Motion with 360 videos, so you can use your own hands to pan the camera around. I'm also going to add in finger taps for pressing buttons, so people can feel sort of like Tom Cruise in Minority Report. The placeholder video was shot a month ago at a Dell factory in China as a part of their effort to be transparent about their production pipeline. Check it out:
  4. I've attempted to build a game engine in the past and eventually realized that was a lot more work than I would ever have time to finish. Went to college and started working fulltime as a software developer which ate up all my time. I eventually had some money saved up and just decided I would quit my job and focus on building a game in Unity3D. I managed to make a significant amount of progress and almost have a playable game, however, I ran out of money and had to start working again... SInce then I haven't had time or the drive to start working on the game again and it's just sitting there in its partially complete state collecting dust. Has anyone been able to build a successful game while working a full-time job? If so, how did you do it?
  5. Crunch Isn't Cool

    I've always loved video games. As a child, I spent hours playing on my Atari 2600, on our home PC, or at a friend's house on his Nintendo and Super Nintendo. As time went on, I discovered QBasic and started to learn to make simple programs. It clicked - this is how the creators of the games were doing it! From there, I became very interested in learning about the creation process. I experimented, read articles in magazines, and as the World Wide Web took off I ventured online to learn more. Games got bigger and fancier, and some of them in special editions with documentaries about the creation, and I loved all of it. Well funded teams of hundreds of people were now working to create fantastic games with hours of gameplay and breathtaking visuals. I read articles and watched "making of" documentaries which described how developers would work long hours, forgoing days off, working late nights, and sometimes even sleeping in the office to meet deadlines. I was so impressed with the effort and dedication they put in. How much must you love a product to give up your nights and weekends, and spend time away from your family to finish it off? This was how great games were made, and I was in awe of the industry and the process. This was what I idolized. This was what I aspired to. I was wrong. The process I have described above is not necessary, and it is not cool. Developers do not need to sacrifice their free time, their sleep, and their health to create great games. The science is in. Numerous studies have shown that well-rested people are more productive and less prone to mistakes. The stress of this schedule and lack of sleep is profoundly damaging to people's health, causes burnout, and drives talented developers away from our industry. Just think about a cool feature that you loved in a AAA game. If the team went through a period of crunch, the developer who created that feature may have burned out and left the industry - they might not be creating awesome things for gamers anymore. We should not idolize a process that is harmful to developers. When we hear about crunch, the overwhelming reaction should be that this is not ok. Crunch is not cool, and developers still using this process should work towards a better way. Happier, healthier developers will produce better work, and in the long run, they will produce it more efficiently. Happier, healthier developers are more likely to stay in our industry rather than seeking greener pastures, resulting in more people with extensive experience who can then work on more advanced tasks and ideas, and push the industry forward. Thankfully, a growing number of developers have moved on or are moving on from this toxic culture of overtime and crunch, and a growing number of people are willing to speak up. Unfortunately, it's far from everyone, and there are many developers still exploiting workers. I'm putting my foot forward to say that I do not support a culture of overtime and crunch. We can do better, and we need to do better. I'm not the first person to share these sentiments, and I'm not an influential person, but I hope I won't be the last, and if I can convince even one more developer to stand up for better treatment of workers, then hopefully I've made some small difference. If you agree with me, next time you hear someone discussing crunch as if it's just a normal part of the process, let them know that there's a better way and that you don't support crunch and overtime. Let them know that crunch isn't cool.
  6. As a member of an indie team I'm interested in knowledge on how to organize the team and improve work efficiency. Can you guys recommend any good learning sources (books/articles/lectures)? Ones covering how to distribute tasks, group the development team into smaller working units and gather data to improve the performance of individuals. Thanks in advance!
  7. Hello everyone! I hope you’re all feeling the spirit of Christmas. And Happy Hanukkah if that’s the case. Today I wanted to give you an update on what we’ve been up to. Lately we have been trying to make our team grow. We’ve been needing help on the artist side of the game, since it was falling a bit behind. And I think we’ve succeeded! So, who is part of FAXIME now? You already know me (Teresa) and Gil. And of course, you know Midday Mayhem, the artist who has done most of the current concept art and 3D models of SpaceVille. We now have a new 3D artist; his name is Lidar Thomas. He’s the one who made the bunny’s 3D model we’ve shared already on our social media! He also does smartwatch faces. You can check them out here. Two new people are also helping us with the UI and UX. They’re Oscar and John! They’ve started doing UI icons for the tools. Spoiler alert: They looks great! Maybe they will be out for the next version of the alpha? Now on a different art aspect, MUSIC yes!! We have a new member just focused on SpaceVille’s music. He is our youngest member (laughs) with only 15 years old! He’s a great composer! And soon we will have a new concept artist to help Midday! Meanwhile we also have an intern, Miguel, and he did this awesome promo image for us! Sorry for the long post! Anyway... I guess that’s all for today. If you’re Portuguese I hope to see you this week at Comic Con Portugal! Happy Holidays! 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
  8. Hello all, I have been working on a game and brought a few others in on it to develop it and make content. The team is currently unpaid (will be compensated after release/funding) In this setting, what do you think are some good practices to follow to make the project a success and a good development environment? The project is still early in development and I would consider this to be my first leading role in something like this Managing vs Leading: As I am pretty directly involved in the development of things, from story to design to actual coding, I have tried to steer clear of 'managing', or over-managing as its a small team and nobody is seeing the $$$ to put up with much BS. I think I have mostly done this with some success, but it has made it difficult for me at times. I have tried taking less of the front seat and letting everyone pedal as well, but I found that people didn't really have much drive to contribute anything unless it was adding to something that I created or was already there. So far I have created a wiki, a forum, a Google drive, and set up some other tools for the team, as well as a Facebook page and have managed the security of our information (like making everything non-public) Legal stuff - NDA/other agreements: When is the best time to do the formalities and write up things like NDA's and other agreements to protect the project? Gauging my team as it is, I think they would not be keen on signing things like this - it seems to be a big turn-off when I start talking about rules and organization. I can understand the reticence as it is unpaid, but it also seems very risky in thinking of the future. I have already had a developer leave the project, and I have yet to see if problems are going to arise from this. I know these types of things are very standard for larger projects with funding, but it seems difficult to implement in this setting. I have read many stories of failed games due to petty internal conflicts, developers retracting their contributions, misappropriated funding, and dissatisfied developers that probably could have been prevented if everyone had some type of written, formal agreement adhering to some rules of conduct. I dont see agreements and NDA's as an attempt to disadvantage people or deprive them of freedom, but as something to protect the project as a whole - which is bigger than any one person and affects everyone. Is it a good idea to put write something up and get some signatures? If so, when is a good time and what would be the best approach (as far as selling it to the team)? Should any agreement be very light and plain, or well written and very detailed?
  9. Hello all, I recently had started making a game and invited some others to join the team as well to create content and write some of the story. The group is small, and there is no funding currently. The problem I am having is that I have a vision in mind for the game, but have some difficulty getting others to follow it - it follows certain themes and there are certain things about the world that cannot be changed without it being out of place or disrupting the 'feel' of the game. I have so far been running things fairly casually as it is still a small unpaid team, but there are some things I feel that can't be compromised on. Don't get me wrong, I don't want to stifle my developers' creativity and I welcome new ideas/changes (we have had several good brainstorms in the past) but I think there needs to be a line somewhere so the game stays close to this vision. In this example, the game is going to be dark fantasy, and have a rather serious environment, but I have a developer who wanted to add silly easter eggs in as 'comic relief'. When I asked for an example or something similar, he talked about how Saint's Row has some sort of dildo bat that you can use as a weapon in-game. This is very much something I did not want in the game and I had to draw a very firm line there, telling him we are not going to have anything like that (for the reasons above). He said something along the lines of "Well, I am going to put whatever I want in my level". Following that, I had a conversation with him where I told him that while he is in charge of that level, if it is out of place from the theme/doesnt fit in to the 'feel' of the game, that I won't allow it in the game. The developer then told me I am taking things too seriously, I am thinking too far ahead, and it is not fun to develop the game anymore - he decided to leave the project. I definitely do like to have fun working on this game, and value the input of all my team, but I think there are times when I need to 'get serious' I am very compromising with a lot of the story and design aspects, as the team is small and unpaid, but do not want to see this game run wild and turned into a joke. I am close to the design and story myself, and consider myself to fulfill the roles of a creative director and project manager - along with a bit of everything else. In the past, when the game was basically a blank slate, I tried to gather people around to come up with new ideas, but there was little contribution and I am seeing much more involvement after I went ahead and created a foundation of the story myself. I do my best to avoid coming off as 'managing' but it has been unavoidable in cases like this. If you have read thus far, thanks for staying with me! My question for you all - What is your opinion on this, what are some suggestions you have to avoid this in the future? I have some people with great Ideas and conflict is inevitable. Do I need to be more picky with/vet developers better? Is there something dysfunctional in how I am approaching the matter? How do you work with your content authors/designers/developers to resolve creative conflict, and where do you draw the line? Note: Usually I let a lot of stuff go that doesn't completely 'fit the vision', and adapt to it, in order to keep morale up and not stifle others' creativity, but knowing the guy personally, I suspect he had wanted to have a lot more control over the project and I had a feeling that something like this would develop down the road which is why I wanted to nip the problem early on.
  10. 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
  11. 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!
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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!)
  18. 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.
  19. 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?
  20. 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:
  21. 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.
  22. 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?
  23. 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.
  24. 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
  • Advertisement