"Just Hire More Devs!" | Project Feline Devlog

[@RaymondCripps]

MERCH: store.raymondcripps.com Support me on Patreon: patreon.com/raymondcripps Thanks everyone for being so patient. This episode was by far the most painful to make, but I've learned things I would have never imagined when I started this game. I might prefer solo dev, but the unyielding community encouragement and support has kept me going when I felt like stopping and for that I will always be grateful, even if I may outwardly seem withdrawn. I appear to have caught the attention of some "professionals" with my conclusions, who take offense to the idea that other devs are untrustworthy while at the same time criticising me for being too trusting. But it just goes to show, as the title suggests, it really isn't as simple as "just hiring more devs" when you become aware of the expensive overhead required to manage more devs, yet alone pay them. Such overhead, or awareness of such, isn't a luxury afforded to most indies. Nevertheless, my point is if everyone took personal responsibility for their work and 'washed their bowls', 15-year industry professionals wouldn't need to be micromanaged in the first place. I am disappointed to see developers have become so domesticated that they expect their manager to wash their bowl for them, even after being shown how. I dislike this attitude for it robs developers of their individual autonomy and discourages initiative. I value individual autonomy because, evident by the conclusion, one developer who washes their bowl, even with no training or experience, can outperform a professional. That is why I would not make a great manager, and have so chosen to continue alone. So, my fellow gamers, I hope this gives an insightful look at the technical and interpersonal struggles that transpire during the development of a video game. Could you imagine this scenario with 100 more people? Aspiring solo developers, I hope this devlog gives you the courage to do things your way. Contrary to what the industry says, not everyone is meant to be a team player that everyone just magically gets along with. If you find yourself more comfortable with the torture of doing everything yourself than the torture of dealing with other people, then I encourage you to do it yourself, your way. Wash your bowl. Get the small things right to become the person that could make your project. Working alone is not a badge of shame.

[@nairocamilo]

I think you fundamentally failed at working as a project manager, which is okay, is not for everyone, just like solo gamedev isn't.

[@obsidianflight8065]

When reading the quote about washing a bowl, I definitely felt enlightened like the monk. At a certain point I noted that you felt robotic during the video, but I realized afterwards that it was likely... really painful to speak of. You are probably the first inspiration I've ever had in game dev! As the other people said, you definitely failed as a project manager, but it does make me feel like working alone isn't too bad of a thing. Knowing that I'm the reason something doesn't work is... infinitely better than knowing it wasn't my fault.

[@JesusPlsSaveMe]

@@nairocamilo Where are you going after you die? What happens next? Have you ever thought about that? Repent today and give your life to Jesus Christ to obtain eternal salvation. Tomorrow may be too late my brethen😢. Hebrews 9:27 says "And as it is appointed unto man once to die, but after that the judgement

[@ralphwarom2514]

@@nairocamilo I think integration should not have been done all at once. It needed to be done step by step.

[@DERUSART]

Its ok dude, im doing my game solo too, and stopped so much times, but after all i understand that game dev is peak art and modern gaming industry needs us, indie devs

[@Waffle4569]

Pro-tip, always have contractors merge their work into the main branch before the contract is up. It's on them to make sure that works, and that is usually when most issues are spotted.

[@FirstCrimson]

To be honest, Raymond should've been having them do submits after every work session to at least review the work every week or so, especially considering how long term the contract work was.

[@Waffle4569]

@@FirstCrimson Yeah but I could understand how he didn't feel that was necessary cause the guy had "15 years of experience"

[@morgan0]

smaller commits would be easier to merge, less likely to cause problems, and more likely that like naming and structure decisions could be done better going forward

[@FirstCrimson]

@@Waffle4569 The veteran should've knew they were supposed to do consistent commits, if they really were an authentic '15 year veteran', the models and code says otherwise (albeit an artist would probably have similar code). But again, Raymond should've taken the steps to request frequent submits, it's all lessons at the end of the day but I think the video is learning the *wrong* lesson from all of this.

[@Auroron]

@@Waffle4569 Its not about trust, its about the workflow. You can trust the worlds best developer all you want, but a humongous 1000+ file diff commit will always be an awful experience compared to multiple, smaller, self contained merges.

[@DukeCyrus]

Man, I can't even imagine how frustrating it must have been for the contractor to cut contact like that. Thank you for pressing on despite all the nonsense!

[@RipperRoo92]

Facts 💯 My blood would overflow seeing red 🤬

[@kharijordan6426]

Did they leave in shame?

[@JesusPlsSaveMe]

​@@RipperRoo92 *Revelation 3:20* Behold, I stand at the door, and knock: if any man hear my voice, and open the door, I will come in to him, and will sup with him, and he with me. HEY THERE 🤗 JESUS IS CALLING YOU TODAY. Turn away from your sins, confess, forsake them and live the victorious life. God bless. *Revelation 22:12-14* And, behold, I come quickly; and my reward is with me, to give every man according as his work shall be. I am Alpha and Omega, the beginning and the end, the first and the last. Blessed are they that do his commandments, that they may have right to the tree of life, and may enter in through the gates into the city.

[@multi-milliondollarmike5127]

​​@@kharijordan6426The contractor just ghosted the dev and acted like the work he did was so long ago. It had only been 6 weeks!

[@bigassmf1923]

That's why regulations and standards exist in every field. I think he failed to implement his own belief by doing slow and right. He didn't check or verify his contractor job. So in a way he cut corners himself by not checking if the contractor was doing the proper job. Doing everything on your own is fine. But big projects require teams. I'm sure his game is plausible without extra help. But his video made it seem if you want it right the only way is to work on your own. Which is build on a flaw premise that everyone you will work with will cut corners. And that happens often that's why you have to trust but verify other people work.

[@noiadev]

This is why solodev devlogs are important. to show these parts of the journey. People can shout, light torches, and gnash their teeth when a game fails to meet deadlines. But you put these videos out there demonstrating what solo gamedev is like. I can't imagine the sinking feeling you must have had as you slowly realized what the contractors had done to cut corners and feed your baby a bunch of garbage.

[@RipperRoo92]

Facts 💯. Couldn't agree more.

[@uzzy2522]

Sadly making in depth devlogs can take up alot of time as well .. time that doesn't necessarily improve the game.

[@DxBlack]

Vapid suckupery. More often than not bad solo-devs do this exact process with half the skill and using all of the successes other solo's have had to exploit and scam people into backing off; that torch and pitchfork is justified far more often than Solo-dev success occurs.

[@Reahreic]

Not just contractors, I've got these same "_final_final_final.tga.png" and ngon issues from seasoned professionals. There is no final, or latest or version numbers in my files. That metadata is the domain of my digital asset management solution(s).

[@terriblecontenthere6626]

@dreamyuni I think more then that it lets people who doesnt understand the hardwork can see it and they could see the shadyness and the scumbag stuff others would do that would cause delays I honestly it sucks I feel bad for ray I think the "that was a life time ago" and then they left the discord server

[@Lobstro]

You had me in the first half ngl. I was thinking, "Why does the video title make it sound like hiring more dev is a bad thing? It sounds like this contractor is doing a great job," but then I saw the 2nd half of the video

[@guywithknife]

Hiring more is also very expensive

[@KummoDeveloper]

Same here. Altho before 20 minute mark i just shrugged that this is how YT currently is. A lot of content creators i watch regularly outside of gamedev space have negative title and thumbnail but the content inside is either neutral or sometimes even positive. I would stop watching these guys cuz i hate the manipulation but.... sadly then i wouldn't be watching no one about hema, history, swords, martial arts, music production (altho in this genre its rare to see negative title and positive video - often when creators use negative title you often can guess that either they got scammed and tell their story or they are telling story of another person, often a viewer, sometimes some random on internet - but there are some channels where i like their content but they still use these manipulating titles) and comic book drawing/writing/publishing/stories in the past. It is too close to "x is crazy" type of title sadly in many of these genres :/ And i hope it doesn't reach to gamedev space (and that the trend dies out elsewhere too..... i guess negativity does gain more clicks tho... which is sad to know and see).

[@HaloWolf102]

They had me in the first half...

[@dominiccasts]

They almost had me in the first half, but the pace of work left me feeling like something was very wrong. It seemed too fast to be true.

[@Movman82]

@Lobstro Same here. I was like "What an ass, not even using the name of the guy that helped you so much?"

[@nicosool7169]

This is why code reviews are a standard in software engineering. It can catch bugs and prevent technical debts before a feature is considered done. It also helps to improve, share and enforce good code practices across the team. Even with that, it is said that a new team member takes 6 months to a year to be fully operational/integrated.

[@christophernoneya4635]

The fact the developer didn't reach out to him about code questions was a massive red flag, the developer should constantly be deferring to the lead for important questions like architecture, or if they're designing tools about the ergonomics.

[@dumpworth9473]

I was thinking the exact same thing. It sucks for everyone that a lot of these mistakes went unnoticed for so long because of the lack of review. But it was also kind of strange they went radio silent after the 6 weeks, almost like they knew they were cutting corners and were ready to burn the bridge.

[@michaelgdupreez]

Yeah... I was watching the video and just thinking that DevOps practices was missing, and it can easily happen in the Indie space. Starting a project right is not well documented, and if you don't build a house on a solid foundation, then the cracks start to appear when expanding.

[@kyokaioken5552]

This comment reminds me of Hofstadter's Law.

[@macieksozanski9723]

@@nicosool7169 yes, it's a really bad practice in my opinion that they didn't do more frequent merges, the issues could be addressed and talked through, which is a normal and common thing to do as quite often you work with people with very different experience level. Some of them might have 10 years of experience, but still might need guidance if they didn't work with experienced people in the past that much. From my experience waiting with merge for months has always resulted in something really bad

[@seanss]

I don't think the lesson here is to just "don't trust other people" but more of a lesson in properly managing and overseeing development... Because at the end of the day, there are certain things that you cannot do yourself especially with a project with this kind of scope and with this kind of artstyle. The fact that development has taken this long and the game still hasn't had a real level yet (and with each level taking like only minutes to complete) should be an indicator of how long other levels would take to complete on your own, especially when you have to make a lot of them. Couple that with the fact that there aren't any proper NPCs yet, you still have to make models for the main characters of your game, for the enemies of your game and also have to animate them adhering to the limited animation style you're going for, and you can see why I'm a little skeptical about the development timeline of this game lol. Its fine to take your time with your game, especially since this is something special to you (cue miyamoto quote here), but you also have to consider what really are your goals for the game, and what you want the future of the game to look like, because without proper direction on what you want your game to actually be, this will be a one way ticket for you to be stuck in development hell. There's nothing wrong with doing everything yourself, but with the quality of game you're expecting to release at the end, there will be a lot that you would need to sacrifice (time, quality, sanity, etc.)... Bringing on more people can help you alleviate that sacrifice, but you'd just have to learn to oversee other people's work better. As what other people said before, code reviews are a great way to catch some of these issue early, especially with the amount of money you've spent on manpower. You really should have at least checked what he was working on yourself instead of just checking in on everything at the end of his contract, but that'll just be a learning experience for next time. I know the tone of this comment might come off as quite harsh or very critical but these are just the concerns of somebody who really wants this project to see the light of day. But at the end of the day, it's your game and your project, and you should do whatever you feel like is best for you...

[@RedzeeTV]

Personally I still struggle to see a concrete end vision of the game. If I were to tell someone what this game is about, I couldn't. Maybe a time trial game? An action RPG with NPCs about doing parkour related missions? Something similar to Mirrors Edge? Idk. But that is a crucial foundation missing from the game, and adding features without any overarching goal to what the game will be is the pattern im observing, which I think attributes to the long development timeline, and as you said, will lead to development hell. (Yandere Dev)

[@Shura86]

@@RedzeeTV hes kept the story and plans of the game pretty hidden from the audience, we mostly get to see the progress and what comes next. This is NOTHING like yandere dev where he didn't know proper programming with 50 if statements and took 3 months to implement something that would take 2 days, watching a few of his devlogs its pretty clear how much time and effort Raymond actually puts into this and why each devlog takes so long to upload. For now we know its a level based high speed parkour game with story on the side in an anime style, I dont think there's anything wrong with and I definitely don't think he has a lack of vision

[@RedzeeTV]

​@@Shura86 I hope I stand corrected then. The comparison I made to Yandere Dev was not technical, but simply the lack of vision as a foundation for their game.

[@サリエリ-q5g]

this game will have main characters? I thought it's about running forward with minimal story

[@Shura86]

@@サリエリ-q5g Gabi is the main character, Calder and Felix are side characters from what we know so far. Also yeah it seems it will have minimal story doesn't mean it won't have main characters lol

[@Auroron]

What is the purpose of using a VCS if you're not doing any kind of code review or continuous merging into main branch? These mistakes should have been caught super early during some kind of pull request or code review. The deliverables agreed upon were perfect candidates for a pull request and would have uncovered a lot of the problems.

[@Auroron]

I also think you have the wrong takeaway from this experience. YOur takeaway shouldnt be that "I need to do this solo", but "Working with more developers requires a stricter and more organized workflow". I think a lot of smaller startups and teams have burnt themselves here, so its invaluable experience to take with you into the future! Good luck with the project, its very impressive

[@myortv_]

It's really strange there was no continuous merges. Like, amount of conflict can be here after half a year of development can take weeks to resolve. Maybe gamedev where you have more separated parts of project, this problem is lesser, but still.

[@janikarkkainen3904]

Yeah I totally agree. I there should've been semi-regular code reviews and merges. Also deliverable reviews should've been "once merged to main, I'll review the technical part, and try it it in a build". I couldn't have gone 9 months without a single merge and proper review of deliverables, heck I'd be jittery at the 1 month mark. And I think if there would have been merge parties and deliverable reviews, there's like 85% chance the contractor would have fixed the issues from the get go with just a simple "oh this doesn't work, can you fix it?" or "can you change the folder structure and file naming a bit" or "these modular meshes need to be merged and extra outside faces need to be removed, or this whole things needs to be a bsp, actually".

[@rasyasejati]

this

[@JefryU]

Mann hearing about the way the contractor handled those tasks sounds seriously scary. Though HOLY COW what is up with those animations on the new gabi model its so cleann!!

[@citizen1791]

he is the animator afaik

[@Sgt_Turkigreyvi]

She's the main character makes sense for a lot of effort to be put into animations.

[@ReubMann]

Just hit the half way mark. Does this man mean to tell me he worked side by side for 9 months and never looked at their code ONCE???

[@Akronsus]

yes and then continues trashing the contractor for not beeing mindfull enough, because the little things matter, you know, like code review

[@Cyliandre441]

Yeah, he seems to have pretty severely failed at project management here.

[@johnderat2652]

You shouldn't have to babysit an industry veteran. Not to mention Raymond gave him many detailed guidelines on how to proceed.

[@LoliconSamalik]

@@johnderat2652 Some veterans drift in the industry. Others rely on director orders. So that's why you have to check as the boss regardless. Either way, he learned a hard lesson

[@catcactus1234]

@@johnderat2652No one mentioned anything about babysitting. Regular PR reviews are standard practice. Not reviewing someone’s work for 9 months is like commissioning a statue from a sculptor and never actually seeing it once until it’s done. Usually you’d at least have a couple check-ins on the work itself, otherwise you’re just screwing yourself over by trusting thousands of dollars to someone based on their word alone.

[@e-ee-ee-e]

Maybe I missed something but the final conclusion to work alone feels off. Washing the bowl covers everything, including managing the contractors. Assuming they will do their job feels similar to assuming the bowl will get washed

[@e-ee-ee-e]

You consistently went over the fact that slow and steady is better, but say if you want to do it right you’ve got to do it yourself. Having a team takes longer in the short term, but does boost the quality of a game when done right.

[@noahlederer8587]

@@e-ee-ee-e i agree with what you.. I feel like the narrative is a bit forced here. Maybe what he wants to say is: Managing people is not really my thing and since I don't want to spend the effort of managing them, I'd rather develop solo. Which I think is a good call for him, but the way he generalizes it is kinda weird imo. for me the video was very insightful and important tho, I am also struggling between solo and team right now.

[@johnderat2652]

Personally I totally get where he's coming from. Time and time again I am disappointed by the people around me, but instead of taking my anger out on them, I take it out on me. I'm the one who should've known better. If you want something to be done, do it yourself; so when when something ultimately goes wrong, there's only yourself to get mad at.

[@e-ee-ee-e]

@@johnderat2652 That's a fine mindset to have, but this could have been easily avoid if he just did a bit a due diligence. Contract work isn't really meant for setting the internal infrastructure of a project. Having a contract worker isn't the same as having actual team members who work on a project for it's entire duration, so it feels disheartening to see his final result be "teamwork bad".

[@este_marco]

@@e-ee-ee-e everything is easily avoidable if you already have the knowledge on how to do it perfectly.

[@Tesl8n]

I'm a senior dev at my job, and one of the major responsibilities that's come from that is mentorship. Having a team of other devs that I'm responsible for helping to build effective code, and being the one to know the standards and teach what they are & hold everyone else to them. I've had 6 junior devs over the years, all of varying amounts of experience. Some who have worked in industry longer than I have, some who were fresh out of college, or even still *in* college. One of the things I've learned is that, no matter how long they've been working or how skilled they are, everyone still has things to learn, and has to acclimate to the standards of a new place. Until they do, 100% of people will cut corners, will rush things out, just because trying to both finish something and to learn a codebase and to learn standards all at the same time is too much. And, that learning is such a thought intensive process, often moreso than just writing some slop that works, that the dev also has to be willing to learn it for any of that to take. I think I've only successfully mentored 1 person to be able to code up to the same standards I hold my own code. To have someone who has developed to at least my skill level, and then specialized to fill holes missing in my skillset. It took that person around 3 years to get there. It probably took my mentor 3-4 years to get me up to his standards (and every time we talk, it still feels like I'm not there lol). All this to say, the mythical man month hits hard, and if you want to work with a team, you have to work with a *team*. Random short term contractors can be nice, can be useful, but to actually get that time investment back, you have to put in a lot of time to get on the same page for how to work together. I sympathise with the difficulties here, and kudos to the confidence in your own ability to work & build a quality code base & game solo

[@SkylerFoxx-GameDev]

I think that last bit in particular about the problems with contract work are key to why games carried on the backs of contract workers tend to have glaring development issues. Halo Infinite infamously paid the price for this by over-contracting their work, so by the time the contractors got accustomed to the processes and the in-house engine, their contract was up and that knowledge was lost. With the recent push for Halo to now be in Unreal Engine, I do worry that it was with the mindset of "Hey, the problem was contractors had to learn Slipspace, so let's use Unreal since most people we can contract out will have experience with it" rather than learning the more important lesson of "Hey, maybe the majority of our developers/artists should be full time staff and not temporary contract workers?"

[@Firestar-rm8df]

While it's true that you often need to mentor developers, the work contributed should at least still be usable. With this contractor supposedly having 15 years of experience you can't tell me that the developer shouldn't have known that clipping and overlapping geometry is likely to cause the game to bug out. In addition to all the other issues mentioned in the video. Though I will agree that, unfortunately, with how law and contracts work, it's on the person hiring to create deliverable requirement, and to verify and sign off on them periodically. Sadly it sounds like Raymond was just far to trusting, something I really relate to when I was working with a small time art team and art director in the past on an indie project. I assumed that they were telling me the truth about the state and progress of the work and training. They weren't. And ultimately that is on me. I've learned from it though and have managed every project better since.

[@Tesl8n]

@@Firestar-rm8df Agreed in principle that these shouldn't have been issues from an experienced developer, but I've consistently been surprised at how often extremely basic development practices like "don't use globals" get ignored by devs of all skill levels who absolutely should know better, esp when they start looking at a new code base. I think we're having an is/ought disagreement here - it definitely ought to be that you can trust someone with a lot of industry experience, but unfort, as you & I have both experienced, that's not usually the case.

[@Firestar-rm8df]

@@Tesl8n ...unfortunately yeah. Makes you wonder how people like that have been in the industry so long though.

[@asafesseidonsapphire]

@@Firestar-rm8df the same way a student in a federal highschool somehow was able to use ChatGPT to get an answer in a test. By doing it so much he learned how to mask it really well.

[@Cyliandre441]

Why didn't you check the contractors work a single time in all these months? Being hands of is fine, but not to the point where you don't even know what exactly the contractor did in all that time. The naming convention thing would have been so easy to catch early on, and at least some of these issues could have been avoided by just checking and communicating what your standards are?

[@thenamessteve567]

They're an independent contractor not employee

[@Cyliandre441]

@@thenamessteve567 That doesn't really change any of my points though?

[@iontech6668]

@@Cyliandre441 It's likely they asked, but received only partial information. Most commissioners only work for the money, only demoing what looks good, leading to a less cohesive product at the end when work's due.

[@Cyliandre441]

@@iontech6668 Ok, but he still could have just looked at the files at least once.

[@w花b]

​@@iontech6668 He barely checked his actual work(not what the other wanted to show him but the actual result, the files). He was too naive. On tip of that, working on a different "branch" (I'm using git terms) for 9 months without merging at least once is insane. 9 months of conflicts... Good lesson learned, wrong conclusion.

[@DecoyZ]

28:00 "Players will know" Also Undertale having 500 if statements for one room and no one knowing for 9 years:

[@z0bi_]

On the other side is Yandere-Dev putting a 5k polygon toothbrush in their game lagging it to hell in back.

[@repingers9777]

​@@z0bi_the tooth brush doesnt actually lag anything. Lol its the logic of all the npcs running everyframe

[@Mikasey]

It is still a 5k polygon toothbrush that could be made in like 24 quads, and lets be real, there are more stupidly big models (at least was, not sure what is current state of this "project") And 500 if statements is a lot, but if you work alone, mark them properly to fast find and debug stuff for yourself, and it is basically a finished scene, it is fine i think. Single switch for entire dialog of the game is more hardcore in my opinion... But again, it's not that bad because the game is so simple, and it does not happen every frame. Still a shitty code, but an amazing game, because author cared enough to not make bullshit decisions.

[@LadyDem]

exactly how i felt seeing that, players WILL NOT KNOW..if your game is simple. To be completely, brutally honest undertale is a very simple game carried by its absolutely stellar writing. Sadly not comparable to something that requires this level of effort.

[@NEWGHOST9]

I mean that game is less resource intensive than most tbf

[@YellowKamel]

Labelling a section in the video "The Merge" because it's a huge event and not something you do every week is crazy.

[@Jerms_McErms]

This is why we do code reviews folks XP. Love the update!

[@Vruk11]

Those new animations look so good, I always felt like something was a bit off with them but now it really makes the movement look like it clicks

[@toldfable]

I'm a fan, but I still feel this was a communication issue on your end. There should've been some regular SLA/measurement of performance of both the literal FPS of the game and things like naming/organizing. You can definitely do a lot as a solo dev, but you'll never reach the highest possible heights without synergy. Even if somehow you do, a synergistic team will end up making something better. That's my 2 cents, idk, take it or leave it

[@vector4606]

This is 100% on him. If he took one single second to check on the contractors work this wouldn't have happened. He should consider himself lucky that he got any work at all out of the contractor. Basically just burnt Epics grant money.

[@Tenomas]

He should more care about his game not relying on contractor

[@w花b]

​@@Tenomas If you want the game to come out fast then that's impossible

[@nathanfranck5822]

The fact that Ray didnt try merging in the devs work until after he fired him is really telling. There was no critical oversight during, and no knowledge transfer after - obviously not a good working relationship. Bad use of money and human effort.

[@dan20247]

@nathanfranck5822 he didn't fire him, the contract expired. But otherwise agreed. I don't know if this is the first time he was managing someone, but typical growing pains if so.

[@nathanfranck5822]

@dan20247 Definitely - and yes lesson learned I'm sure! His new levels and art are looking great, so slow and steady one-man might be the way to go anyway :)

[@charlesscholton5252]

I do continuous integration and there would have been many many merges happening along the way, with play testing and review. I also would have had the other dev stuff and structure things in a manner to avoid merge conflicts too. Both Ray and this other so called experienced 14 year Dev literally did everything wrong. I personally do not care how many years of experience somebody does or doesn't have, it is all about getting shit done. This is a field of work where it is like going to school every day too. Every new version of UE with new and changing features. Also all kinds of never ending wicked APIs to delve into as needed. Nobody knows everything about all this stuff... It is always an uphill battle, and testing of everything being done along the way is critical in catching mistakes and making improvements as needed. IDK, this is rather interesting following the Dev on this game.

[@ruolbu]

You talk about washing the bowl and I think that is a tip I will keep in mind. It is in my opinion the true take away of this ordeal you went through. NOT that working alone is the better option, or that failure was inevitable. Many many teams out there are clear proof that teams as a concept work, even for small developers. What washing the bowl in this context means is being mindful about your team. The contractor did work, even got done ahead of schedule. And instead of finishing that portion of the contract (i.e check the work, have them walk you through it, teach the tools, explain their reasoning, do the merge etc), you added new tasks to the list. You either could decide to become a better solo dev or a better team manager. Both are valid options. But feeding your anxiety that working in a team is bound to give bad results, is not what you should take away from this

[@Orionhart]

I disagree with some of the conclusions you come to at the end of the video. While I agree with the concept of taking control of what you can control and focusing on mindfulness and doing things right, coming to the conclusion that working with a team is impossible and incorrect is just not the lesson to learn from your contractor experience. As a contractor myself, and as someone who also works with teams, consistent code check ins, branch merges, etc. I would chalk this one up to inexperience in team and contract work rather than an assertion that those things are not useful to you. Not that you're incapable of finishing this yourself, but that those options are still available if you approach it differently.

[@christophernoneya4635]

One piece of criticism, windows in shade should not have the anime streaks as they are there to imply a bright glare. The fact they are impacted by shadows is a little weird visually

[@christophernoneya4635]

And I'm sure its a work in progress, but seeing the same white streak stretch across nearby windows and those in the distance feels a little distracting, its like there's a hidden object behind the screen. Ideally different building's windows would have a different set of streaks

[@Firestar-rm8df]

@@christophernoneya4635 The issue I think is more due to how the light source is directionally aligned to the camera. In anime a lot of the backgrounds are static, so you won't see the sun streaks move around with the camera. I'd actually consider tying it to the nearest most influential light source on the window, and fallback to the direction of Global Illumination and see how that looks? May be a bit less weird and more accurate to(most) anime styles as they only tend to account for the camera moving in reflections when the reflection is the focal point, or in /very/ high detail anime. And honestly, if dynamic lights are out of scope, you could probably just get away with global illumination. I'd be very curios how that would look.

[@chloewebb5526]

something can be in shade and still have the glare of a smaller light source, but I see what you're saying. Glare is a perspective thing though and not a illumination thing

[@christophernoneya4635]

@chloewebb5526 but the window itself would not be dark if it was reflecting enough to make a glare, youd need to make the window emissive

[@ChrisBakare]

I think that a form of source control share could have helped your situation. A more frequent merge after a feature completion from the contractor could have alerted you sooner on these issues and even allowed you to break ties sooner. I agree with the message of washing the bowl. I disagree that a team would not help you with development. It's understandable why you would stay solo after this but realize there is a lot of gamedevs out there including me that would agree with your thought process. Gabi is looking good, hopeful for a wonderful 1.0 release in the future.

[@RealBrianRussell]

Yup, the contractor was obviously bunk, but this is 100% a management problem, not a "working with other people" problem. Of course, there's nothing wrong with choosing to go solo. But if you want something done right, doing it yourself is not the only way. At least the contractor injected a breath of ideation into the project which I think was helpful in the level design, so it wasn't worthless, but prob not worth the amount invested.

[@jmartian6426]

100% agree. Dev only reviewed work via screenshare and did not regularly make the contractor submit to version control so he can check on his own machine if it even works. The idea of merging a month or 2 of work in one go sounds hellish as well.

[@ChrisBakare]

@@jmartian6426 I'm saying they should merge every week to every day depending on Ray's schedule but obviously didn't work that way. or at least have the branch visible so ray could see and make changes.

[@jmartian6426]

@@ChrisBakare In my experience, files should be submitted as soon as you're done working on them for the task. Only submitting all working files once a week and hoping merge goes well is still stressful because there's no way all of it will merge correctly

[@ChrisBakare]

@@jmartian6426 You're right. At that point, there was 3 or 4 separate occasions the contractor should have merged their files over claiming completeness.

[@SadeN_0]

"This one contractor had bad standards, so the takeaway is that all collaboration is worthless"

[@paulindrome]

This is kind of a bad faith take-away but I agree. The "do it yourself" bit at the end is a bit of a quick-draw. Too many people could take this blanket statement to heart and be worse off for it. It's actually a paradigm that can be harmful to one self in the long run.

[@XavierBJohnson]

You inspire me Raymond, keep it up!

[@michalzarddev]

hopefully you dont take inspiration from his team management skills

[@crazycakegamer9672]

It's definitely good practice to be vigilant of your collaborators. Adding new people to a project also means you have to take more time to keep an eye on them, the larger the team the harder the team is to manage. This is a good learning experience for any dev, so thank you very much for sharing it as I'm sure it will help indie devs both new and experienced. My advice to anyone concerned about bringing in new members to a project is to look at every commit, have a designated project manager (it can be you) and to do test builds regularly, especially when major additions are added. Good luck everyone!

[@souptaels]

Glad I'm not alone in saying that I hate this recent YT gamedev trend of "making a game in a short time". They are not reflective of a real game environment experience and they encourage bad gamedev practices just to get out a quick video for views. So many of those "le funni" channels aren't the best influence when it comes to getting real gamedev experiences. I can just smell the amount of tech debt these "funny" gamedevs could accumulate that wouldn't be there if they just took things a bit more seriously. Not saying you can't have fun making a game, but I'm sure the process would be even more fun when you're focused on adding new mechanics, and not making more boilerplate code and refactoring old code due to laziness. I like videos like these cause they show the actual process of game development, even if it's heavily clipped down for a YT video.

[@shijikori]

while keeping in mind that it's important to be considerate of the resources you have at your disposal, I would believe that going for a contractor was the mistake. I don't have many years of experience but what I hear about at my current job (I work in the IT department of a manufacturing multi-national) is that contractors will do the job their way. They don't care about your requirements and your workflows. They will tick the boxes they can but the priority is getting the result done by the deadline. From their perspective, they are not paid to do it right. They are paid for a result that fits in the parameters of the contract. That is a stark difference to onboarding someone to work along with you, teaching them your workflows and standards, giving them all that training so they can contribute long term to your project. I can't say I would be able to tell if your project is perfect for a solo dev or not, what I feel like is that "solo dev is the only way" is probably the wrong conclusion from this experience.

[@ShinSpiegel]

You know what, I’ve another anecdote for ya… “a monk asked the master, where is the moon, and the master pointed to the sky… the monk for ever on believe that the moon is on the tip of the master’s finger”… the same way you should “clean the bowl”… you need to learn how to “learn”… people have different opinions and what they meant and what you understood will differ. Wish ya the best, hope to see the next devlog

[@barrybach]

Nice video, though I'm not quite sure the "lessons learned" here should be turned into mantras to follow. Disappointing results from contractors sucks 100%, but at least from what the video describes (and a few others here that I've watched), there are underlying issues of scope + time that can contribute a lot to that. Having the same contractor do multiple things (especially contributing to overall architecture, and bringing on external tools to supplement that architecture) is instantly a no-go imo, at least not without a middle-man "manager/scrum master" type to enforce things like code reviews w/ periodic pull requests. I understand budget and your own time is a concern, but you just can't expect a non-employee to put on multiple hats and work on a project with the same fervor you do and without error. That doesn't excuse things like missing naming conventions and things that are spelled out in the contract, but definitely things like overall implementation simply can't be amazing quality without having a dedicated employee or someone to manage your contractors. It's a roll of the dice otherwise. I sympathize with the issues you mentioned here; small budgets and large scopes are tricky to manage. But I think encouraging hyper-individualism rather than encouraging sustainable project management is the wrong lesson to take. Just one developer's opinion, though, and Solo Dev still is a great route for many others to take!

[@Nightwinger5100]

Very well said

[@alvin_row]

Couldn't have said it better myself. I feel like the "lessons" taught here are to never trust anyone, and that micromanagement is good, which aren't very good takeaways. Working with someone who also cares about the project can help a lot. It brings new perspectives and ideas to the table. I gives you the feeling that progress is always being done, and it can help cover up your weak spots. I've found working with other people to be extremely fulfilling. Besides, there are things that a single person just can't do realistically. What's important here is that if you're gonna work with someone else, you need someone who also cares about the game, and who is skilled enough to do the job they're expected to do. Short term contractors wearing every hat aren't a good recipe for success.

[@khairiharris921]

This was the comment I was looking for. Communication on projects like these are key. Everyone works differently so that initial onboarding and catching workflow errors like this early so we can correct them is so important I feel like. I don’t think the issue is bringing on more devs, the issue is figuring out how to work cohesively and effectively together. Like OP said in the beginning of the video, it’s a test of interpersonal skills and team management.

[@yimwav]

Exactly my thoughts. very well said

[@Acceleration50]

Agreed, I couldn't have said it better.

[@jesustyronechrist2330]

I dunno why but this video comes across as oddlly... Gaslighting? Like you tried to paint this narrative that the contractor scammed you by doing a poor job, but as you went over the contract in the pan, it seemed VERY much focused on the artistic side rather than any of the technical side that you then had all the issues with. Did you have a performance metric? Did you have an SLA for FPS or polygon count, etc? Did you outline any standards of folder structures, naming conventions, coding style? And then the kicker: You mention at several points you didn't know what you wanted and asked the contractor to just... do it. You did not check up on them or correct them or communicate. So to me it seems like the failure of the contractor is by in large your own fault for having a loose contract. If there are no performance metrics or standards communicated, then how is the contractor supposed to know? Just read the code and figure it out? The only part where you take responsibility is this weird "I didn't think I'd need to communicate to my contractor and tell them what to do. I expected them to read my mind and do what I wanted because it's just so obvious to me." I get that it's your first contract, but the way you threw the contractor under the bus like that while painting a narrative the accoutability rested on their shoulders alone, does feel pretty shitty.

[@RuneKatashima]

I think coming out of this with the mindset of, "Other people suck, I'll just do it myself." Is a sad outcome. You know as well as I do that many hands make light work. You're taking the inspirational "wash the bowl" line and not applying it to everything. You could have washed the bowl with the dev. They didn't, and you admit as much that you weren't doing your due diligence as well. This is also why any employer sorts things out with their employees beforehand to make sure they are compatible with the vision of the company or project being worked on. I think you could have simply taken this on as something to learn from instead of "Never again." Get someone else, and do better working with them. Maybe I am biased though. As I was watching this video I was like, "Hey, I specialize in level design, maybe I could offer... Oh, no they got someone already. -watching- Ah, okay. Well, I could probably offer to help write a story or dialogue for NPCs. I'm very good at that." Then you basically say how you're swearing off any help. I cannot commend this. It's... the wrong way to approach the problem.

[@mow_cat]

I agree, but I think he's extrapolating when he comes to the conclusion that he can't trust anyone else, and I can definitely see where he's coming from if he can't trust someone with 15 years of experience to ALREADY KNOW how to properly make a level, does he really have the time to teach them? at that point then he's paying them AND doing their work

[@GoshdarnCat]

So sad to hear you had a bad experience working with others. Hope you can recover from this setback, wish you all the best! I’ll wait as long as it’s needed, because your vision seems so rad! Good luck and stay strong!

[@Shura86]

As someone whos also super organized (or tries to be) this was a massive headache just to watch. Props to you for fixing everything and pushing on, I would probably procrastinate for a few days before throwing everything from the contractor out of the window and doing it myself and eventually quitting the whole thing. Eagerly waiting for the final game, wish I could support through patreon or something but this comment and like is all I can do for now

[@Elemental227]

The new Gabi model and animations reveal blew my mind, such a crazy leap in quality, well done man

[@chockie]

thank you for sharing your absolute nightmare story working with this contractor, and i'm sorry you had to deal with this... but i feel like you ultimately took away the wrong lesson from the experience. "they say you need a team but i say if you want it done right you've gotta do it yourself"- this quote gave me nam flashbacks because i've said these exact words multiple times and every time i do it myself becomes a perfect recipe for burning out, crashing, and dying. hard. and hilariously enough my work ends up suffering for it anyway. learning to delegate and actually manage people (aka communicating, doing proper check ins, making sure everything is up to code/specs and works) is a whole skill of its own that is so valuable the bigger you want to scale your projects. trying to do everything yourself because you're the only one you can trust is not the way

[@Floppyz]

This video genuinely changed how i do my day to day things. You made it very clear how important it is to do things carefully and with intent. I plan on washing my bowl from now on.

[@SamaelBunn]

VRoid's models was likely the cause of the massive frame drop. It sounds obvious after experiencing it, but each model usually has upwards of 20k tris, as well as excessive use of alpha channels rendering over other alpha layers, shapekeys and if not atlased material slots. Having crowds of these models is just a surefire way to lead to frame drops. Invidivually it would be fine but when you're got even 10 in one area that's already 200k (on a low estimate), as well as likely countless dynamic bones for the hairs. Whilst the tool the contractor used may not have been a great choice the ideas at least weren't terrible. Having a base mesh to work off of and then prefabbed hair or clothing that is random-gen would save a lot on individually modelling each possible NPC and, even further, keeping the total file size down.

[@wasteurtime5677]

VRoid is built for VR avatars, not video game characters.

[@FirstCrimson]

I would bet to wager it probably wasn't the tricount but more the shader cost and bones, and additionally I wouldn't doubt these characters were made with the Character pawn which use the CMC (Character Movement Component), and that bad boy of a component can easily cause huge frame drops.

[@EzKay_PX]

@@SamaelBunn yeah- the moment VRoid was mentioned I got both impressed, cuz honestly it is a clever way to get around modeling and character design and would have never thought of that. But also moments later remembered how much of a mess they are to optimize in stuff like VR Chat and braced for the framedrops Honestly, I am impressed that it ONLY dropped to 20 dps, LMAO

[@Firestar-rm8df]

@@wasteurtime5677 And it causes problems there too. I wish people would use stuff that was better optimized.

[@lanata64]

just want to point out that the geometry really isnt part of the issue. it could be 10x the amount of tris and that would still probably not be a bottleneck.

[@Y0uWinY]

I can imagine how frustrating this situation must be, and how it might make you question the idea of working in a team environment altogether. Finding the right team member is a lot like finding the right partner in life-it’s transformative when you find someone who complements you, but staying single is better than being with a toxic person. When it comes to working in a team environment, outsourcing isn’t the best standard to set. In my experience, apart from specific areas like artwork, often comes with challenges that can disrupt progress. That’s why I generally prefer to avoid it. That being said, finding the right team member can do wonders for your productivity, creativity, and motivation. A good teammate isn’t just an extra set of hands-they’re an extra brain to bounce ideas off, someone who can challenge and push you to do your best. No matter how skilled or experienced you are, two minds working in sync are always more powerful than one. Smaller teams often have stricter screening processes for this very reason-they know how much is at stake. I’m sharing this based on my own experiences, both as part of a team and as someone building one. I hope this experience doesn’t discourage you from finding a real team to work with. The right team can make all the difference. Even if it is just one extra person.

[@azzytheangel5494]

As far as npcs and crowds are concerned, I would absolutely not recommended using vroid studio models for anything more than key npcs. Besides the fact that they are very inefficiënt (lots of faces, because this isn't what they're meant for) I think it's a worse look for the game overall. I'd much rather see a sort of stylized blank slate sort of crowd design like the aperture science bendy for example. In this case it would fit the anime look, not draw too much attention away from key visuals, and have a greater and more thoughtful stylized effect.

[@Nightwinger5100]

This is likely a big fear of other solo developers as well. I hope this doesn't completely deter you from taking on new hands onto the project, but instead, ask more questions and dive a bit deeper into the results being produced. Well done

[@hellsgate700]

"I don't know man, give the contractor some slack. Maybe it was just..." _Outdated2_

[@thenamessteve567]

Crazy the amount of people defending this as normal. 15 years in the industry and this is the best they got?

[@raphaelguitarx5931]

Raymond another Solo Dev here, I feel you bro when you are talking about the level desing, keep going as smooth as you can, perseverance is the key

[@ryo_pf]

I'm glad to know that the project is going forward. I respect your dedication on paying attention to the small details and sharing your thoughts on these matters as you keep developing the project. These devlogs are a good source of learning and watching this encourages me to keep working hard on my own projects. All the best for you and thanks for sharing this amazing content.

[@bar0s4]

I had a similar experience with contractors before too. Finding competent people to work with is really hard. I see you're doing great on your own, though, so take your time and we'll be here to see the finished game!

[@LadyDem]

Just like Swen Vincke warns everyone about, its NOT easy to find the right people. big companies end up firing their best people then wonder why everything goes to shit. hold onto those people you find that do a good job, they're one in a million.

[@BuilderTB10]

Amazing work and resilience. I love your work and i can proudly say i CAN wait! So take however much time you need. Happy programing! YOU CAN DO IT!!!

[@mathijsfrank9268]

As a programmer that does not work in the game dev industry, making things with a bad foundation is not just a game dev problem. I am very abstract focussed and am always thinking about the "best way" of doing things. However when I work together with other people it is surprisingly rare to find people with the same mentality. The vast majority in my experience are satisfied as long as an exact problem fixed, without thinking of how to prevent future problems from occuring. This kind of mentality works for quickly making demos, not for production level products.

[@CaiusNelson]

Man, you have no idea how cathartic it is for me to hear a bigger channel talk about this. No disrespect to them, but it does bug me when I hear bigger game devs tout the mantra of "just finish your game" like its an absolute rule, when adhearing too closely to that can compound your problems. I've spent five years building a gameplay framework just to avoid the kind of tech-debt you're talking about. But the trade-off has been that my team has been able to produce higher quality projects in a shorter dev-time each year, because our workflow and tools are optimized. Sometimes spending all day just debugging a spline actor properly rather than doing a quick fix can save you insane amounts of time later on.

[@RaymondCripps]

I've seen that advice as well. Hell, you'll likely see them in this comments section touting "JUST SHIP NOW!!". But when you've been around to witness a bad launch, you learn fast that just 'shipping' isn't good enough. Anyone with $100 can ship, and 50% won't make that back. Around the time this happened, the contractor shipped their own 4-year title. They had everything, funding, staff, a trailer, press coverage, but the game still flopped. Why? They didn't wash the bowl. The game shipped half-baked to low sales and mixed reviews. Nobody on the team had cultivated the requisite discipline that would have endowed them with confidence in the idea. The few customers they got noticed the lack of care. So yes, they "shipped", but at what cost?

[@Me__Myself__and__I]

​@@RaymondCrippsThe majority of "pros" don't take code quality and project organization seriously. Which is why most software has piles of tech debt. The attitude and perspective of this sole dev is the exception, not the norm. That said, you do have to be careful not to be too much of a perfectionist. This can cause people to spend way too much time on what are actually small issues instead of delivering a working solution. The correct answer is somewhere in the middle where the concerns balance out.

[@michaelperrigo]

​@@RaymondCrippsDay jobs are for money. Game Dev is for reputation and legacy...and hopefully one day for money ...

[@HeraChimera]

The game looks great! Sorry to hear about your experience with that other person. Hiring contractors can be very rewarding, but it heavily relies on both the specificity of the contract and reviewing the quality of work at every milestone, not just at the end of the contract. Glad to see you were able to bounce back, despite the setback. Looking forward to seeing more progress on the game!

[@ajyauchler7678]

This is a great example of why programming/development principles like modularity and DRY are so insanely important, especially in large-scale projects!

[@michaelperrigo]

Wait, what does DRY stand for in this context?

[@michalzarddev]

@@michaelperrigo Dont.Repeat.Yourself

[@michaelperrigo]

@@michalzarddev very good, very good. 😅...😬

[@kashyapp23]

in a way this so inspiring to see you keep going, many people would crumble here. All the best for future , you have got this!

[@taoboyce6412]

I really appreciate your attention to detail, and I know the feeling of looking away from what other people are doing for what feels like a short time and then looking back and seeing they made a massive mess.

[@davidsaucier1463]

This was an amazing devlog. Dont let the hurdles drag you down. Your progress looks great.

[@Illumas]

As long as the game takes, I'm really excited for it. It looks amazing, and the attention to detail and quality is what makes a game good and fun to play.

[@chimklee]

This… I’ve been watching since the beginning… I couldn’t imagine how far it would go. Congratulations, both on Project Feline’s development and your own personal development! I’m glad to have followed this journey of yours and have learned a lot myself, thanks! You are a huge inspiration to me, I’ll be cheering you on from the sidelines!

[@quriz4609]

What a crazy story. I can't imagine how doomed and deceived you must have felt when you started going through his mess. Glad to see you got over it and can now carry on your work better than ever!

[@ThiccMaiki]

Hey Raymond, I just wanted to say that you are an actual legend, and congratulations on your progress! I've watched these devlogs for a couple of years (four or so), and it amazes me how, after all this time, effort, and hardships, you keep persevering and making headway with Project Feline. Your tenacity is astounding, and I wish you all the best with the project. I hope you stay sane and healthy and your game becomes a success.

[@JoshMannon]

I really appreciate you taking on this topic because, you're right, these kinds of things don't get talked about and I don't know how much that has to do with click baity title hunting as it does with the culture of "only single programmer projects are really indie" that pervades indie culture in general. A team could be putting out significantly more and higher quality content while spreading audience awareness to their separate channels which would be more likely to be monotized all while really talking about the struggles that are game design and development. Overall I think the fact that we haven't seen a rise in that kind of thing with as many incredible creators we have involved in game creation is this vision of artourship.

[@mightyobstaclestudios]

I can definitely relate to this video both as the contractor and the contracted. It can be really hard to work together with others when you're not transparent about what needs to be done, but it really depends person to person. I've found great success with contractors in past projects, easily by keeping them on a leash and explaining how the systems I already have work for what they're doing. Keep on the grind though! Can't wait for the next demo!

[@CrabQueen]

Man, you just can't catch a break. really rough man

[@killernick01]

I feel you Ray. I've been on the other end of a coding nightmare from previous developers not properly coding/commenting/Integrating their code properly and spent months fixing and remaking those same systems. It takes time and experience to get that knowledge, but not everyone has to deal with those issues to gain that appreciation for well managed code. No matter what though, you know better now. So if you choose to work with someone in the future you'll know what to look out for. Good luck with future dev and can't wait to see what comes next!

[@Eggbaby7777]

just a quick headsup! thr vroid plugin won't let you pack out, and an average vroid character can run up to 100k polys, we optimize them before import them into unity or ue, they also look fugly so you better hire a 3D artist to create lowpoly npcs with baked details (for anime npcs)

[@Plexi.T]

This video is a masterpiece man. I've been saying for a while that "faster doesn't always mean better" and the amount of people that are impressed that people are able to get so much done in such little time is an easy trap to fall into. But slow and steady always wins the race. Definitely looking forward to this game in the future man. You're insane 🔥

[@deadbysix]

This is the equivalent of ordering from the drive-thru, not looking in the bag until you get home, and being upset they got your order wrong even though you could have confronted them about it an hour ago in the drive-thru.

[@fantomas1770]

that's why it's pure comedy

[@BrawlDevRBLX]

The storytelling of these devlogs are truly inspiring! The perspective on KZbin game development content promoting rushed games was something I had never thought of and “washing the bowl” is what I’ll consider for my future projects moving forward.

[@bondi_69]

Your main takeaway from all this should be that you must check on your employees lol

[@_3ther_636]

i am so thankfull someone from the game dev scene made vid taht project structure matters, and hey! i hope your project will rize it looks awesome

[@nairocamilo]

"Just Hire a Project Manager!" I yell, at the top of my lungs.

[@NeoHCgbz]

18:45 excellent choice of background sound, perfectly captured that sinking stomach feeling

[@codernunk]

It totally sucks that so much time and money was spent on something you couldn't ultimately use, but I'm glad you were able to reflect and learn so much from the experience. I like to believe that everything happens for a reason - at the end of all the trouble, we'll come out of them stronger, wiser, and more motivated than ever. I'm a senior software dev myself, and communication with others is BY FAR the hardest part of the job. That's why there's so much overhead around managing a team - hiring project managers, team managers, and following an agile/scrum process are there. Plus, conflicting opinions on coding standards and implementations of the systems can get really tiring. So, I completely understand keeping the project solo is what's best for you. One thing I will say - you don't have to stick to your decision forever. It's okay to change your mind, it's okay to realize there's other paths forward in the future based on the evidence you run into in your travels. If you ever decide to seek outside help again, you can rest easier knowing that you've learned what to look for and how you can proceed in more confidence. But keeping the project solo is also perfectly fine too!

[@XcutAngel]

the new animations are SO GOOD. Very happy to see her moving in more frames. You're a real game dev's game dev.

[@ViewportPlaythrough]

this is what you should expect with working with "cost-effective" freelancers. not to piss on all freelancers ofcourse(i work as one from time to time), but like that, keep the cost-speed-quality triangle in check; if something is done cheap and fast, its probably crap. shortcuts need to be made to get that fast. quality-first freelancers might be more expensive to hire, but they cost more for a reason also, be warry with copying untrusted files to your master branch. its rather more safe to get those untrusted files into a different side project then copy the verified working files slowly to your main project. theres also the level of stuffs that can be off-loaded to external work, but up to that point, if you want something done right, do it yourself freelancers are best for products that you would simply use as the final products. as close to it to being a set-and-forget product, the more its suited to be outsource. else, the further it is to that point, the more you have to expect that you would get something messy. ie music is easier to get freelancers for since the end product would literally just be played. same as voice acting. concept art's end product could simply just be seen. story writing can be off-loaded as long as you know you would re-write some of the stuffs. if you would just use 3d models in a video or something like that then its fine to off load them. the more technical the end product is, the more you would want to just do it yourself or someone that you know would work with you till the end of the project's life span. never, as in never, expect the same "passion" you place into your work from external workers. it would just never be possible no matter how you trust that external worker. there are also big game studio examples of this. happened to squareenix multiple times now where they trusted the initial grunt work to external studios then they had to redo years worth of work from scratch since what the external studio did was crap. to re-iterate. there are freelancers that are worth their cost. please dont generalize. there are people who earn honest living by freelancing. side note: the more painful thing about his experience was he had past experience working with the contractor before so he trusted that past experience only to get this sh.... so its not just a simple "not meeting my expectation" but also a betrayal of trust...

[@tacospin_]

These are the most important kind of devlogs, they show the numerous hardships of solodev, and the nuance of things people thinks are simple like simply hiring more devs. I can just imagine how frustrating this whole experience was. I'm glad you have thick skin and can overcome such insane setbacks. thank you thank you thank you for your hard work.

[@danielchavez9367]

Someone might have already posted this. I worked in construction, and how you pay your contactors matters. I noticed that if you pay someone by contact, they will work as fast as they can. Often cutting corners. If you pay someone by the hour, they take their time. The problem with this is they will work extremely slow. The solution to both problems is you have to be able to monitor them working.

[@SoloSpartan1906]

DONT EVER QUIT!!! Even if it takes you another TEN years!!! Your doing masterful work and experiencing master level growth. I as well am a solo dev and have worked with others, had my own studio and the lack of focus and self-discipline to do the work and do it at a high level is REAL. About 99.9% of the population don't have the mental fortitude required to do it and do it RIGHT. I would rather do it myself so it can be done right. AMEN!!! Keep up the great work!

[@user-sl6gn1ss8p]

"Smooth is fast" Never merges

[@MegaFrog]

This game has been such a journey to watch. From such humble beginnings and through such hardships and setbacks, the journey alone is worth following this game. You've had my support for years past, and you'll have it for years to come. Raise a glass for project feline! 🍻

[@ChrisCarlos64]

The red flags when watching this: 1. I was told I'm pedantic and ... 2. I watched the changes via screenshare 3. I didn't merge anything in yet. It was getting worse and worse every minute in. First and foremost, I'm sorry of course you had to deal with this. I'm not speaking with any ill intent. Just remember this is YOUR project. YOUR business essentially and YOUR money. Be "pedantic" if that's what people think you are. Be rude, blunt, etc. It's business. Not friendship. You're not going to please every employee, but you'll weed out the bad ones if you maintain a strict professionalism. People aren't here to work for you for fun, they are doing it for money. Fun comes from the culture and their own accord, not yours. Next, you should never take the employee for their word, especially one you didn't know well. Next time make sure you not only follow up, but have a rigid structure. Do not let them decide, you decide when the meetings are, when the milestones are due, and have consistency. You can be hands off to some degree, but they also should earn that approach, not be given it. This is again, your money and time. Lastly, always merge. Stay with the tools you know too. Do consider the workflow of others and their needs, but stand by what works best in your timeline. If they cannot get up to speed or use the tools, then you need to consider talent elsewhere or review the tools being proposed. I'd say a major technical shift like this maybe wasn't too intrusive to your business, but it is indeed costly to jump tech stacks in the middle next time for no reason other than "they like this." Have not finished the rest of the video, but I do hope things turn around. This sounds like a big learning experience, and I hope all goes well. I felt personally some of this stuff should have been programmed and not blueprinted, but I know that's kind of what many people do in UE. I'm just more a classic programmer by trade I guess. If you want someone with C++ skills, well we're around lol.

[@Anomen77]

If you are buried in work hiring more devs helps a ton ...if they are competent. The take away shouldn't be "don't hire people" or "do it yourself", it's "be careful with who you hire and review their work often".

[@AlexLusth]

Im so sorry this happened to you. There are good organized devs working in teams out there. Don't let this discourage you from ever working with someone again.

[@kelbym3710]

Hey I just wanted to say I love checking these out. I kinda surprised how long you’ve been making these dev logs for and I even told my friend and he asked how the game has been going. This made me realize that this has been a kind of journey that is so fun to think about and actually really helps with productivity. Wherever you are in your process of making project feline id love to see it.

[@Bananenbauer123]

This video is honestly gold. I built a game once in unreal 4 (yea quite a few years ago) and I did hit a point where I had to give all enemies in the game additional behaviour, but because of how my enemy classes (blueprints) were organized I realized that I essentially had to rip out everything and redo it, otherwise stuff was going to turn into massive cable spagetti. I was smarter about an enemy spawning system as it was reusable and customizable per level, but man, that modularity is something that only hits you once you are a couple months into a project and you usually don't get to that point with a small prototype. Also, those new animations at the end look siick!

[@lightning_11]

This video does a great job of explaining why the "Just Hire More Devs!" mentality from managers is so frustrating. A larger dev team means more overhead, and just doubling the people on the project won't half the production time!

[@fantomas1770]

nah he's just horrible at project management bruh

[@fiftydashfour]

I'd say to take this as a lesson on how to contract work. Which of course will be rough if its your first time like all things first time. While going solo is fine, it's also worth thinking how you'd do things differently if you had to contract out work again. Ex: If you do contract out again and end with content that doesn't package. That'd be on you more than anything. Nice work though! Looks fun and unique. Keep at it.

[@jorrdan.]

Thank you for making these videos Raymond! I’ve been working on my biggest solo project and I always leave your videos feeling more assured that I’ll be able to finish it

[@zentoa]

that actually sucks with the contractor. I'm glad you are pushing on and hope you are well! :D

[@thebigr3dfox]

This is giving me Sunset Overdrive vibes, I freaking love that game btw. Honestly, I can already see this becoming one of my new favorites right after it drops. It’s so damn cool seeing this mix of anime aesthetics, Persona-style UI, and those Sunset Overdrive/Jet Set Radio gameplay. Also, it’s so inspiring to watch these solo dev-vlogs. It’s awesome seeing what it’s like to build and nurture a game, grow a community around it, and the most impressive: doing it all on your own. That’s hella amazing and it fuels that itty-bitty part of my brain that dreams about starting a game of my own someday. You, dear developer, deserve a medal. Keep up the amazing, slow, and steady work on your game.

[@tophatgeo]

Others have put most of my thoughts really well in the comments. I 100% agree that environments like game-jams or "I built [x] game in 2 days" aren't good for developing the process and work ethic of larger, more intensive projects, I agree that the contracter cutting contact like that was rough. Your discussion surrounding how a slow, but careful method can be more valuable than a quick and easy solution was really eye opening to how to maintain quality control. Same with file structure, I think the way you discussed this helped me learn a lot. But like others have said, I don't know if you've come to the healthiest conclusion here. It's fine to be a solo dev, and its valuable to have cases where developers develop a game entirely solo. But this was your first time having a contractor and I don't think you should come out of it thinking you can't rely on others when it comes to your game. Humans make mistakes and I think this and the "clean the bowl" analogy goes both ways. The contractor has a responsibility to do their due diligence in their modelling and file naming, and you have to be the one to check this work and hold it to account. This sounds like the issue could have been minimised if you caught the issue early. Collaberation can be valuable and even in this video, its clear there were some creative solutions even if the way to get to the solution was ultimately detrimental. Either way you go, I'm hoping the best on the project! It's cool to check out your videos!

[@michaelperrigo]

I've literally gone through all of the comments of this video two or three times. I'm really grateful that you put this video out and I know I commented a bunch already but dang I needed this right now

[@Youssef-mj3cb]

Contractor issues aside.. the new model and animations look CRISP

[@TBMVD]

This video was so informative! Even if the end result was a programming hell, it did made for a good lesson for what to do and what not. I'm studying software development and want to become a game dev, and this was very interesting to watch. I hope I can try to apply what I saw here myself to get better.

[@yogeshj7240]

u better not quit , u hear me ? im way too invested in this game by this time , no pressure lad do this your way

[@Cyrus_T_Laserpunch]

I like the way the animation looks. The character's lower FPS can allow your animations to look very dynamic. I wish you the best, sound like you're going through quite the process to make this work.

[@kidpitch]

Always code review anything submitted to your codebase. Before the contract is over/put it in the contract. If you want the contractor to meet your standards then you have to force them to. Oh and merge early & often. A good git flow/branching strategy is very important.

[@lievenpetersen]

Thank you so much for making this video! The contrast was really strong between the first half (the dream contractor) and the second half (big OUUUFF). I wish you all the best for the future of the project

[@CushionSapp]

Wow, what a nightmare

[@wofkwengel]

32:02 Holy heck, I've criticized your animation before, but this is on a whole different level! The low framerate choice finally makes sense when you lean THIS hard into the smeary anime style

[@omeganappie]

I think the art direction in your updated level looks far better than the one created by the contracted dev. I can feel more of your artistic vision bleed into the levels. Also, don't underestimate how patient people can be while waiting for something they're excited for! This game's number one on my Steam wishlist, but I have plenty of things to tide me over until then. It'll probably be all that I play whenever it is released, but I'm just happy a dev is putting this much love and care into their project. "Washing the bowl," as you put it.

[@Firestar-rm8df]

I agree. The other one was higher res, but you could tell it all still had a very stock feeling to it. I much prefer Raymond's level. While a bit rougher in terms of resolution and the 'technical' quality, the textures feel far more cohesive and have a lot more intent in them. I really appreciate the clear thought and consideration that he obviously put into these new levels.

[@sylvialandon9522]

this is incredible, i'm so excited to see what future development brings

[@rodrigodh1]

Thats why all the big techs use agile frameworks, you can't trust the average human to make decent work. If you want to boost your small project you should look for people that you trust and make sure that trustfulness is real through code reviews. After that you can follow as you intended by just throwing the guide lines and letting people work.