Jump to content
  • Advertisement

Search the Community

Showing results for tags 'Management'.

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


More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

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

Categories

  • Audio
  • Visual Arts
  • Programming
  • Writing

Categories

  • Game Dev Loadout
  • Game Dev Unchained

Categories

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

Forums

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

Calendars

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

Blogs

There are no results to display.

There are no results to display.

Product Groups

  • Advertisements
  • GameDev Gear

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


About Me


Website


Role


Twitter


Github


Twitch


Steam

Found 63 results

  1. Unlock Audio

    Bad People are Trying to Be Good

    No one's actually trying to be the "bad guy" Sometimes in the games industry, we're confronted with people and situations that make us immediately fume. We can't possibly imagine how someone could think in a certain way. Don't they have common sense? Are they that unaware? That selfish? What an incredibly evil, terrible person! While all those things may be true to us, this way of thinking only propagates more blame towards that person. It makes us frame them as someone who is intentionally hurting us or others for the sake of being terrible. They relish wrong and love being evil! Our brains have a habit of filling in knowledge voids with negative hypotheticals. Unfortunately, it's then very easy to treat these hypotheticals as factual explanations. This is especially true when it's a challenging relationship or situation which often occurs in a high-stress environment such as games development. Some people even use this for their own gain - politics these days... *Tough pill to swallow warning* Ultimately, no one is trying to be a "bad guy." After an exchange of ideas or opinions, especially with a passionate or heated debate, we may hear people publicly declare that someone is a bad person. “They don’t listen” or are “too stupid to understand” but there is always an underlying attempt at being "good" behind all of it. It’s a matter of perspective. Yes, this is even true (sometimes) for politicians! This guy literally joined the Dark Side. But as episodes 2 & 3 show, it's a lot more complicated than just deciding to be evil. If you're not sure who he really is deep down, check out episode 6. Maybe it's not about hurting you or making your life harder. It may be about protecting their business commitments, or their employees and by connection, their families. Perhaps there's a vehement belief that the ends justify some despicable means. They may see a valuable experience or lesson by having you take the hard path, or maybe they're just not aware of how their actions are affecting you. Ultimately, they're trying to do what's right, or what they think is right. This is true for even the most difficult and frustrating people and relationships we have. Someone may be blunt or dismissive to you because they have been through similar hardships before and are trying to avoid their perceived pain points again - to protect themselves. They may be cold or unenthused because of a personal problem they're struggling with outside of the office and they're coping with it the best way they know how. They may be pushing you away because of how they view themselves and this is their attempt to help protect you from them. This way of thinking may not be the most digestible - especially with certain ***holes! But it can be incredibly valuable in business as well as our personal relationships to try and be empathic during conversations. You may with some effort uncover deeper underlying reasons for their judgments which allow you to convince them of a certain course of action. If nothing else, it will help us to be a bit more understanding, forgiving, and patient, so we can place our attention where it's most valuable. Be sure to check out Unlock Audio and grab some free stuff. Want to reach out? hello@unlockaudio.com Elliot Callighan is a composer and sound designer, and the owner of Unlock Audio. He also teaches in the film and game programs at DePaul University and is an Officer in the Army National Guard.
  2. Hey all, we are currently discussing about different data formats to serialize a visual data structure similar to Unreal Blueprint and I wanted to get more input from other people to get a better decision. We are currently refactoring our build-tool to provide a more flexible way of defining configurable pipelines or pipeline pieces and decided for a visual node based approach. Our nodes are of different type performing different actions and have their desired input/ output pins like in this example Some pins (including output) are optional, most of the input pins have to be connected. Those processors are used in the build-tool only for now, there will be other pipelines in the future we want to configure in the same way, and are connected automatically at runtime by an Actor Approach System that scans the in- and output pins of every pre-defined processor to connect them to a task graph. This way we will keep the flexibility we currently have but gain much more control over edge cases. Because we aren't set to a single programming language, there will be some kind of compiler that is intended to process the result of our configuration and either create source code for a specific language (like C# for the tooling or C++ for the engine) or straight compile it into a plugin assembly that can be loaded from the build-tool. From this reason and because we want to keep the possibility to write those files without graphical tools, we need a grammar that is capable of handling the complexity of those node graphs but is at the same time as simple (and not binary) enougth to be editted on disk using a text editor. I already looked at the most common formats like JSON seems to be getting very complex and the minified form our code produces isn't very readble XML has been removed from the list because I think that it's grammar is too old-school and parsing is more complex than JSON YAML, TOML and AXOM seems to be an alternative because it is slim and simple but parsing it is a nightmare and I don't realy like the strict whitespace handling So long story short, does anyone of you know of an already existing "language" that would fit our needs or do you have any idea for a slim but powerfull grammar? Thanks in advance!
  3. Hello, I would like to start a new company with three people. But we have a situation in which we need a tip from you. Following the starting situation: Person A: Designer & Artist who has already invested a lot of work (two years of work) in three projects (design, documentation, advanced prototypes) Person B: Producer who has been actively involved in the projects for a year and is driving the development of the company forward. Has invested money in addition to his work. Person C Is a private investor who wants to finance the founding of the company and wants to be equally involved in the projects. GOAL: We want to hand over all project values to the company. The company belongs to all three of us. This should fairly distribute the values among us. Thus, the exploitation and use rights to the products of the company. We want the investor to have 1/3 of all legal rights on the projects - no doubt. PROBLEM: The investor wants us to name him next to us as the author of the game so that everything goes fast and easy. But I am looking for the normal procedure for this kind of situation. But the authorship is not transferable in Germany, in contrast to rights of use and exploitation. By the way, authorship is an important asset for the designer as it is part of his reputation. Should a game take off, then he can not refer to it by 100% - he can only say he was partly involved, even though everything is from his pen. TL;DR: We don't want to start with a lie about the authorship just because it makes something easier. QUESTION: HOW MUST THE PROJECTS BE TRANSFERRED TO THE NEW COMPANY SO THAT EACH PARTY IS PARTIZED IN SAME WAY? Thank you for your time. Greetings!
  4. Dear developer colleagues, The hobby game dev Indie Team leomidestreet Group is searching for new members. We develop in our free time and work on our own costs. We don't have donations yet or game income. We don't have any game released yet. We are currently working on a Pong relaunch. We cannot afford to pay anyone money for their work (but a part of the participated game dev income is guaranteed in a fair amount determind by the work done) Currently we are looking for: Programmers in C++ Model Designers Graphical Designers (Artwork, Textures, Materials, etc) Composer Sound Artists Effects Designers Animation Designers We are working currently with the Unreal Engine Version 20 for our project Pong+ A future project after Pong+ is already planned but still secret because of its never before seen story elements. We are a singleplayer Story and RPG Game Dev Team. The Pong Project is just to start with something easy to make a name and possibly get a little money with that we can push the team. We also take rookies (as long as they have at least enough skills for a simple game like Pong) Contact about the mail: leomidestreet@gmail.com Please attach examples of your work and which position you are looking for in the mail. with biggest hopes your leomidestreet Group Team
  5. Hello everyone, Tldr: please skip to questions I would like to start creating my own game. I used the Squad Mod kit (ue4) , Maya and substance painter/ Designer and a little bit of b2m for some time now. I also took a look into blender and unity. I did this for about a year on and off when ever I had the time. I followed payed and free Tutorials to get a very basic understanding in game development. I still feel like my workflow is messy and not very "professional" There are many answers out there, I feel like iam stuck in reading Blogs and forum posts, searching for a definite answer where maybe there isnt one. "Questions" I need a setup that can do "everything" *please leave your thoughts/answer/tips if you have any. *when possible please link a Tutorial or learning Material to a topic Thank you 1) Hardware Running a "gaming" PC. The one complaint I have is that loading for example the squad kit takes *ages*. 8700k, 32gb ram@3600, 2080ti, cheapo nvme Kingston A1000, some tb wd hdds. I would like to put my 8700k in a new pc that I would use as home "Server". And get a i9 9900k for my Main rig. Server: cheapo z370, wd reds, maybe optane? Small nvme/ssd Monitors: two 32 inch 100% sRGB wqhd, one vertical 1080p, one 4k TV for reference and Media consumption. I dont know if every Software is good to use with 4k monitors today that's why ive choosen wqhd. 2) Backup, file Organisation and Management My worst nightmare is to loose Progress because I f'ed up. File Backups on offline and online Server (like one drive) with automatic sync Software? Version control with git? What's the best way to organize your files local? 3) Software to learn I am pretty sure I like ue4, Maya and the substance suite. I also use PS and illustrator. There is Software like 3d Coat or zbrush I might consider. Vfx is still confusing me. 4) workflow / Pipelines What is the difference between a Pipeline and s workflow. Isnt a Pipeline a workflow in a bigger picture? There are many different informations in the www about this topic. I am still kinda confused. Should I leave my project/files iam working with on the kan Server or work on my Main machine. Is it possible to use the second PC as a helper for, rendering, bakeing Light etc? If youre still reading, thank you very much youre a hero. Maybe you can leave me a reply Best regards
  6. I'm mostly following AGILE, but it's the only software development methodology I know. Do we know what methodologies are used by the AAA guys like EA and Ubisoft? Which ones are popular among indie devs?
  7. Hi fellas, We’d like to share the story of a game anticipated to become somewhat a hit, but a series of ill-favored circumstances we’re gonna show below ruined all our expectations. 1.5 programmers and 1 lead game designer had worked on the project, plus 1-2 artists had been engaged in the development on a part-time basis. The rest of us had been focused on other projects. It all started after we successfully released our second free-to-play title Ninja Dude vs Zombies back in June 2016 exclusively on the App Store: the game was warmly welcomed by the gamers’ community and featured by the store several times throughout summer and early autumn. It was our first self-released mobile title to put our project management and publishing skills to the test. We had updates plan for 3 months ahead — we had been prepared to support the project further. Elated with its success we’d been really looking forward to releasing its Android version along with some major features like bosses, new characters, super weapons, and some others. Ninja Dude vs Zombies early Zombie Boss prototype Ninja Dude vs Zombies early PvP prototype Lesson 1. Have a plan B In late autumn we had developed first prototypes of PvP mode. Shortly after we realized that this feature would require more burden-hours that we originally planned in terms of balancing and server side. As Ninja Dude was not the only project we’d been working on, we had to prioritize to keep the studio afloat between this and other titles needed maintenance and support (released under publishing agreements; imposing certain obligations). What’s more, we grasped that our UA and promotional resources had been limited. In other words, we couldn’t afford user acquisition and promotion campaigns both in terms of funding and burden-hours to help us boost the major update and especially the Android version. That being said, we started looking for a publishing partner to help us roll out the Android version, for starters. It was the beginning of 2017. This idea didn’t seem irrational at the time, but we wish we’d known how it’d turn out for us. After about a couple of months spent of pitching the game to various publishers and negotiating the terms we entered into the contract with really great guys: they had awesome games in the portfolio with the plethora of installs and Ninja Dude vs Zombies gameplay mechanics matched their portfolio perfectly well. The main thing we agreed upon while signing the contract was that it’ll be a full-fledged sequel of the game, not the update. It’d be easier to get a chance of being featured that way. The publisher relied heavily on the platforms’ featuring in its promotional and UA efforts in addition to cross-promotion within its already released titles. The development flared up again with renewed vigor. This time it was not only about gameplay features, but a complete overhaul in its visual style to make the game really feel like a sequel. Ninja Dude vs Zombies 2 core gameplay screenshots In December 2017 the key programmer of the project was hunted down by another bigger game development company (damn you, LinkedIn!) — we had nothing to do with that: our team member was offered higher salary and working conditions in a city bigger than ours. It all happened really fast, and of course, we didn’t find the substitution soon enough to keep up with the development pipeline. So it stalled for quite a while as it was really hard (as it turned out) to find a skillful Unity programmer in our region. After losing the programmer the coding was divided between the other 2 team members. But they could only spend about 1-2 hours a day on this project. You wouldn’t believe it, but the game was still in development when it's lead designer left our team. It was the final nail in the coffin. It was in October 2018. Throughout all those months we’d been in contact with our publisher sending them intermediate builds showing how we’re progressing on a monthly basis. They evaluated and provided feedback being quite supportive. Until the early spring of 2019. We received a letter from them where they informed us that they can no longer live up their promises under our contract: situation on the game market had changed, UA costs had increased, and it had become more difficult to get featured by the platforms. They offered us 2 options: Either terminate the contract and publish the game on our own; Or soft launch the game on our own and if the metrics are prominent keep working with them. Frankly speaking, we agreed with them and it was mostly our fault that we had been developing the game for almost 2 years. We had no plan B, so we just decided to finish the game and release it out to the wild without having any high hopes for Ninja Dude vs Zombies 2. Lesson 2. Start spreading the word about your game as early as possible We thought that our publisher would have started some early talks and sneak peeks about the game. We’d seen similar activity with its other titles on forums like TouchArcade. That time, however, the guys remained silent and no gamer knew about the upcoming sequel of the game. We were so deeply engrossed in the development of the game and working on other projects that we didn’t even announce the upcoming game on our social pages. That’s how assured we’d been that our publisher would start spreading some early news. Another thing here is the contract terms. We got used to believing that we had not been eligible to spread the word about the game prior to our publisher started doing so. It’s like breaching an embargo and releasing an article prior to the due date. If someone from the publishing side is reading this, please share your thoughts on the matter. Maybe if we had some early access or beta test program running, we’d already had feedback on the game and supporters waiting for the game to be released. The more so, because nowadays both stores provide such opportunities. Besides, we might have submitted the beta version to some game development contests out there with a publisher’s permission to gain some extra publicity. Lesson 3. Stay in the closest possible contact with the publisher This seems pretty much obvious, actually. But yeah, we screwed this up too. In fact, prior to entering into a publishing deal, we contacted the devs who had already worked with the publisher. They mentioned that the publisher had not been responding in a timely manner at times. We ourselves were not as proactive as we could. Talking with the publisher over Skype once or twice per month about the ongoing development process is not enough. The same thing goes with emailing them the versions of the build once a month and waiting for their reply for another month. Being proactive when it comes to communications with the publisher would have saved us time if we knew earlier that they’re no longer capable of fulfilling their obligations under our agreement. After their uncheerful letter, we’ve decided to complete the game and release it without any tests and almost without any prior promotional efforts: just a press release, a couple of tweets with gifs, and submissions to various industry-related portals. We just didn’t see the point in managing the project for another month. Nevertheless, the game was featured by Apple in several categories across multiple countries (well, except for the US), but it didn’t actually end up well for the game: its poor balance leads to players churning shortly after the first boss; its untested store creatives lead to faulty conversion rates. Faulty conversion rates in the App Store Zombie waves data the released sequel. Only 11% of players make it to the 2nd wave. Players breakdown by skill levels. Almost all the players stopped at level 1.
  8. Terry Nagy of Apogee Software discusses lessons learned in operations, legal, business development.
  9. Free tickets are available to The Business of Indie Games Virtual Summit happening next month from July 24-27, 2018. There will be 30+ well respected indie devs, producers, and industry veterans speaking about strategy, finance, and marketing of indie games. You can easily sign up on the website at https://businessofindiegames.com/info.
  10. KrisWolfe

    Setting up core mechanics

    This week was a little tougher than the last. Specifically, I wanted to create a skill tree, but I didn't have an idea of what exactly I wanted in the skilltree. I had some general ideas of what I wanted to happen, but nothing specific. What I want to do is have a scheduler that you choose which active skills you have available, and the more you use a skill, it will unlock others. At the same time, as you progress in a day, the skill will "do stuff". This week I tried Scriptable Objects, but I did not want my skilltree to be persistent. I decided I would use JSON to load my skilltree eventually. For now I have some test skills hardcoded into my skilltree class. My scheduler was tricky, because I couldn't use prefabs. Each skill would be different, and my attempts at injecting the skill into the prefab failed. Eventually I decided to recreate a gameobject completely from scratch. This was a huge pain, because there are so many components it needs. Especially Text, which has all kinds of toggles and enums to sort through to get it right. But today I got it working. I have a grid on the right that spawns "spawners" on the right for each active skill in the skill tree, and these spawners will create 1 object I can drag around. When I drag that object, it will create another object, so I can have multiple objects. My scheduler has 16 hours that will attach the draggable object to itself, so that my day schedule can count how many of each skill are in the scheduler. It works. It might be horrible code, but it works. This week: Get a visual skill tree up that shows what skills unlock, and have the skills actually do something when we're in the schedule. So to recap, what I currently have working: Purchase Orders work, with a 2 day delay, recreating an aspect of "The Beer Game". Customers vary depending on the day. All calculations for storage and inventory works, and if you have too much it gets rid of it, and if you don't have enough to sell to customers, it won't sell. Small economy is working, allowing us to hold inventory and cash and deduct and add as you sell. A scheduler that counts how many skills are in it. A skilltree that has unlocked and locked skills, and the ability to unlock skills and make them active. Pretty happy with what's done in a week. Here's some crappy photos of my game so far with free art assets I found off the store. Lots to polish when the game mechanics are in place.
  11. Rule 1: Don’t bite off more than you can chew. If you’re new to the industry and want to get your foot in the door with your own ambitious project, it might worth taking a step back and considering your scope. While the games industry is full of lots of wonderful projects and games successfully making their way to steam and many other platforms, it took skilled and experienced individuals to get them there, many of them can tell you about their portfolio projects or their failed team projects of the past, but almost every one of them will tell you how worthwhile the experience was and how it helped mould the skills they have today. Show you know where the project’s going. If you want to succeed and get awesome people to come help you with your project, you need to show them it’s worth the time and worth the effort, demonstrate you know your project in and out and let them know that their opinions are also valued. When you first put pen to paper, make sure you know what you are making, a good way to start is to pick a fundamental mechanic that you enjoyed in another game, or even something you have come up with yourself, use that mechanic as the basis for your game idea, and try to mould the game world around it. Try to gather as much information as you can to showcase your game. This is particularly helpful when you’re trying to get new members or contributors to your project, at the end of the day, the best functioning projects are when everyone is on the same page and understands the project to work towards the same goal. Put yourself in the shoes of your teammates. Remember that in a team project, they need to trust you, and you need to trust them, you need to demonstrate that you are willing to spend the time on the project as much as they are. To coincide with this it is also important to demonstrate an understanding of artistic integrity, everyone has their thoughts and opinions and it is only right to be willing to hear out your team members to help build that trust and teamwork! View the full article
  12. Revenue share models (often shortened to rev-share and synonymous with profit sharing models) are a way for businesses and startups to pay the members of their teams. In this article we’ll explore what exactly is a rev-share model and how one might be used with collaborative game development on a small budget. What is a revenue and profit sharing model? Imagine you have a business or a startup with no product. You decide that you and a team are going to build it together. Rather than make them your employees you decide to treat them as investors. The benefit of this is that you no longer have to take out a loan or find finance to pay employees, and better yet, you can get in as many team members as you need. Because they’re considered investors, however, their remuneration comes once the business starts making a profit and for their investment (for instance, of time) they get a proportional share of the profit, normally operating profit. This is essentially a rev-share or profit sharing agreement. There are many takes on such models, but the crux of it is that you treat the people who contribute to your product as investors and thus give them a representative share of the profits. Contributors receive a share of the profits proportionate to, and in return for their time investment How to create a collaborative game development environment With this in mind, you might be wondering how it’s possible to turn a rev-share model into a viable model for developing a game. Well, wonder no more! Here are some points to get you going. 1) Find the right platform for you The first thing to do is figure out how you’re going to organise the structure of what is essentially a business. This can become a little tricky if you’re going to rev-share. Many rev-share agreements are informal and tough to enforce, so you’re best going to a specific platform such as Crowdsourcer.io to formalise the profit sharing model. If you want to go down the route of splitting equity with contributors, legally, then perhaps look into registering a partnership agreement with your country’s company register. If you decide to do this make sure you’re doing thorough background checks on anyone who you haven’t met and interviewed in person. Want to form a rev-share team and build your game for free? Check out Crowdsourcer.io 2) Get contributors and game devs Next up is to get the right people into your project. Not everyone is going to be up for investing their time for a share of the profits, life can often be too busy for that. Therefore, it can take some time to find people who are both willing to invest their time and believe in your project, but being a part of the right communities can make a massive difference in speeding up this process. For starters, have a look at GameDev.net and TigSource.com, get involved with their communities and see if you can’t get a bite or two. If you want more info on what type of developers you’ll need, see this article. 3) Paying collaborators equitably with a profit share model At last, we come to the crux of it. As with all employees or investors, eventually, they’re required to be paid. If you’re doing an informal rev-share model or are working with people spread out all over the world this can not only be a nuisance but introduce some trust issues. That’s why it’s so important to find the right platform and method for formalising your rev-share agreement. Crowdsourcer.io, for instance, makes life easy by automatically routing sales proportionately to all contributors in a project without anyone having to chase people up or request bank account information. However, if you’ve not gone down this route, it may be necessary to request bank information from all the collaborators and distribute their share of the profit manually. Lastly, if you’ve not formalised the model, i.e. you’re not using a platform that does all the work for you, one of the most important things to do is make all earnings completely transparent to your contributors, so come payday they can tot up the numbers themselves, helping to avoid any disputes. A good way of doing this is to invite contributors into your merchant accounts with any retailers (e.g. Steam), and if possible invite them in as accountants – granting them access only to sales figures whilst preventing them from editing/removing the uploaded binary or store pages. And with that, I hope we’ve made the concepts of rev-share models more digestible and given you an idea of how you might practically implement them to develop a game. Until next time, folks! View the full article
  13. slayemin

    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. T