Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

How long have you been working on your game (2nd poll)?

Discussion in 'General Discussion' started by unitedone3D, Oct 19, 2020.

?

How long have you been working on your game (2nd poll)?

Poll closed Nov 19, 2020.
  1. 1 day-1 month

    2.6%
  2. 1 month-6 months

    7.7%
  3. 6 months-18 months

    12.8%
  4. 2 years-3 years

    33.3%
  5. 4-5 years

    20.5%
  6. 6-7 years

    10.3%
  7. 8-10years or more

    7.7%
  8. I intend to continue a few weeks

    0 vote(s)
    0.0%
  9. I intend to continue a few months

    2.6%
  10. I intend to continue a few years

    7.7%
Multiple votes are allowed.
  1. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Hey there! Making games goes from 24 hours (jam) to 24 months (non-jam) to make game. How long yours? Disclaimer: just wondering.
     
  2. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    PS: 'Food for thought'...Special favor/request 2nd question, for people who click '8-10years or more', what made the game take this long to be made - was it because it was made 'part-time' with long 'hiatus' periods interespersed (throught out the years) where there not much progress; it is because it is Immense Scope...or you feel you failed/restarted/failed/restaterd/...on and on. Is it because it is a part-time hobby giving very little hours to it (spread over 10 years).

    If your game were to be finished - tomorrow - and was released/done...and the game did not find success as you hoped (if you did this as a 'business'/with the intent of it being 'commercial (game) product' to sell and hopefully make a return out of it, not a hobby for 10 years and expecting no financial return whatsoever)...would you start another game and be in the long 'haul in' for another 10 years? Or say that you will never do this again (or only maybe much later) because 10 years was a 1st-try and there is not going to be another game that takes (another) 10 years - again (because, life short). Spending a decade of human life to make a software product can be very rewarding (it's incredible that the game ends up made, 10 years later), not necessarily financially, but on the financial matter, a decade is ultra risky because things change so much over such a long time. It brings much more uncertainty despite the quality of the game over such long time. So the question that begs, is would you do it all over again (10 years) (whether you became rich and all/or found some success to live off of it comfortably or found no success). It would more than obvious/understandable why one would not start all over again if they found no success (and seeked that) after such long time. A devastation (but something/a risk one took upon themselves, that they must assume (no one but us - make the game, so we must take responsiblity to it if it takes a decade or more). But what if you do find success/fame/what you want, will you start another game that takes a human decade or decide you will shorten the dev lengthspan a lot this time.

    PPS: I understand that people make games for different reasons, and some people are just making the game because a need to 'create'...being creative and thus a special hobby that they will keep their whole life (so don't care if they work 20 years on their game...it never becomes old and they don't care however long the game may take in tehir life). But, I'm thinking it's either one of 2 things...either people that make games over nearly a decade are taking this really as a hobby nothing more and will stay like that...or they reallly believet hat in 10 years, their game will be the Best Ever game made and they will find success (like building the 'opus/chef d'oeuvre' of their life) and maybe get crazy rich/famous and everything...so that's why/having/seeing stars in teh eyes...for years/a decade. And I'm not trying to stop anyone, it's just I feel I'm amazed that people can tough 10 years on a game and think it's all ok (if one lives 100 years, one can make 10 games in their life, at best scenario/longest life, most people don't reach 100 years old. For some people,10 games seems enough. It's the 'why buy 10 cheap umbrellas that breakdown quick' when you can buy 1 umbrella, a quality one, that lasts (-outlasts the 10 ones); so maybe 10 best games in a lifetime are better than 1000 lesser/cr*p ones). But the measure of things/worth is different from one to the next, so that cheap umbrella could Also be the best thing ever, for some. Everthing is relative/and subjective.
     
    Last edited: Oct 20, 2020
  3. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    I'm about 7 years in it because I do things in the 'right order' (note that it's probably not the best one, and it's most surely not the fastest one...).
    I am used to work on 'standard' software development, with several phases (specification -> design -> tests -> coding -> release) meaning that for every hour of coding there is about 5 hours of thinking.

    I have spent a lot of months on the specification, to know what I want to do (and why).
    Then I spent a few months on the design, and I realized that creating games is far away from any standard software, especially because of the need of overall optimization and mostly because of the modularity (we need to be able to adjust a lot of things in a game, in order to test the gameplay).

    At that point, I've decided to create a framework over Unity, something which I master (because Unity is far too complex to be mastered easily) and with only the features I'm likely to need.
    I create this framework bit by bit, each bit with the full cycle.
    This framework is optimized (no garbage generation at all) so it's very slow to design it.
    The goal of this framework is to be able to use it for several games, it contains a complete main menu and in-game menu, all the code to load the assets (even coming from DLCs or mods), auto-diagnostic tools, localization, sound management, assets integration tools, modding tools, etc.
    I still have to work on the networking and data saving parts and then I'll consider the framework to be finished.
    For now it's about 32 000 lines of code (excluding the assets from the AssetStore and without any duplicated code, I've seen to it) and a lot more comments than code.

    I think I still have about 8-12 months of work to finish that framework (depending on the 'nightmare level' of the networking code...).
    After that I'll be able to work on the game design itself (I already have prototyped a few things in order to have some 'proof of concept').


    I think it also answer your questions about my intentions after this game (whether it works or not).
    With a game-tested framework it will be a lot faster to produce the following games, so I don't intend to stop at only one.
     
  4. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Dear Gladyon, thank you for that. Wow, 7 years, times goes. But, it's great that because you really knew/a specific way to make it/accomplish it, is why it took this long, but the reward is worth it (as you said, that the framework would then quicken things - once done, it is applicable to Whatever next game you make); thus, I am thinking the largest time sinker was the designing of it all/design/concept to make something that is reusable for later games; so that you don,t have to do this all over again; once done. Of course, it took 7 years, but the ROI (return on investment (of your time)) is high because your framework will be highly Re-usable for your next games; from your answer, I am just guessing that you will not spend naother 7 years on your next game/frameworks. That the whole point (of framework/of it all) was to speed up game development - later; so you 'future proofed' things, because you really anticipated to 'Do game devs for the next decades' (in advance); otherwise, I don't think you would gone through all this effort. It was a goal to make game dev faster - later, so you can then pump many more games, much faster (using reusable framework). Wishing lots of luck on your products/future games.

    PS: I think it is so personal what 'matters' to one dev might not to another, like how much their time is worth/vs investments vs risks down the line...as to why one would think 'I soldier on for a decade on my thing - whether I succeed or not, it's my (life) mission now'...as other devs said, the dev decides how much it is worth it or not to spend such long time/effort/money/resources, if they will be making games for decades, etc...the 'is it worth (doing) it all (in the long run)?'. There is a ton of messages on forums warning that game dev could make you become a starving artist/programmer when your game/product does not find any success; that you should just stick to a day job because game dev is very grim/oversaturated game market (so, only if you make a stellar product, do you see any ROI later).
     
  5. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,943
    Hopefully you've been enjoying the process because these two sections of your post left me with the impression that you've achieved a whole lot of nothing.
     
    JoNax97 and MadeFromPolygons like this.
  6. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    @unitedone3D, I think you're thinking in absolutes too much.

    You make it sound like over years of a project, that's all a person is doing. Aside from teams like, say, the Brigador team, what they're actually doing is living. Paying bills, hanging out with friends, enjoying free time, eating, sleeping, showering, falling in love, breaking up, getting promoted, losing a job, losing their house to a fire, losing a loved one to COVID, getting married, getting evicted, buying a house, figuring out how to make ends meet, questioning their life existence, supporting their political views, balancing their financials, spending hours on the Unity forums...

    This is why I HATE the YEARS metric. I wish all dev teams agreed to use DEV-HOURS as their metric, as it's easier to relate to. I've been working on my current game for almost 5 years, but that means nothing to you, as I actually have spent about 1200 dev hours on my game. If I used an average 40-hour work week, that's about 30 weeks, or 7 months of full time work. A far cry from the 5 years that you interpret as wasted blood sweat and tears. All the while, I'm earning a pretty paycheck from the day job, even if I still consider my game for a future commercial release.

    While there are those that are casual about their projects and take whatever time they need, there are those that throw in all the chips and hope to go big. But there are several gradients of in between, "I just want enough to earn a living, so that I don't have to do my current job", or, "I want to release something that I can be proud of, even if it has 10 players".

    There's a lot of value in building the same game over a long period of time, much of which gives the same value as if you did otherwise. Most of the time, the tasks needed to finish a large, hell, ANY size, feature game are small bite-sized challenges, and finishing parts of those features are (should be) rewarding in and of themselves. Especially for programming/engineering, it's very rewarding to build systems such that they can interface together, save you future time, and reuse in future projects. For art, building an object, a texture, a character should feel rewarding. If you have to slog through the work, then, yeah, I understand your thinking. You're not enjoying yourself.

    But on a long project, you are building upon your own shoulders, which means you are making your own self better and better. Even if you completely tear down a project and start it again, there is a reason for it. You have knowledge of why your original choices weren't going to work for you (what not to do), and you can build things faster, and ultimately, you've learned from your past self.

    I think you believe, and you wouldn't be wrong, that most indie developers keep building and building, with no end in sight, not doing constant evaluation, not heeding sunk cost fallacy, not righting the ship, not redirecting course; all of these things are necessary activities for ultimately completing your game. Without the occasional "soul search", you indeed will be lost. It's okay to build a game over a number of years, as long as you are constantly re-evaluating along the way, and not having it consume you.
     
    ClaudiaTheDev, Ryiah, NotaNaN and 2 others like this.
  7. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Dear aer0ace, thank you for that. It's true I might have been a bit too much 'either - or' and not enough inbetween shades of gray. You're right, I agree with you that people are busy living in those years and not Just doing a video game (forgot to add this reason) and that some dev also work on several small projects over all those years; not just one game; so there is lots and lots and lots of things happening in those years.

    The example you gave is great because it shows (in dev hours rather than years as you said) that 'condensed' it was months - rather than truly 'full time 40-60 hours/w -for 5 years' straight. Still, though, the game still took 5 years to be made; you might have made in a 6 months but that would have been grueling and possibly many things you could not have thought of; because game building is a long (organic) process where we discover/learn things over time; cramming it in a few months, not sure the game would be exactly the same; despite equivalent time spread over 6mth vs 5y. As some said, game dev 'in general' is mostly a marathon test of endurance/resilience and not really 'speed run/sprint/get to finish line now'. It's the old rabbit vs turtle fable. Still, I think we should be able in the future to become more like the rabbit and less like the turtle; because 'don'T work harder, work smarter'; if that means faster, it is smarter. Because, as you said, the goal of most devs is to accelerate the next game dev making so their next game is made in 1/10th the time.
    The problem (I thinnk, I have, personally) with 'making a long project' is that you can only make so many of them; so, yes a very long rewarding project, but you will not make 100s of them in your lifetime. Which that I feel is the bad part of making huge projects; you can be more proud of that Single 1 project that took you 30 years to do...but it took 30 years and it's 1 project. (and life short). It's why I am for accelerating the whole process/automatizing (wtithout necessarily 'canning it' by copmuter generation, but 'assisted automation' sort of), where we use the computer as a large helper instead of doing the whole things ourself and it taking an eternity (a bit like that new tool 'Artomatix A.I.' that does art by A.I....it seems counter-intuitive but when you look deepdown, it is not because if someone can make this much art way quicker (by A.I. assisting) and still make a result just as good as any other person doing it from scratch; then that is 'don't work harder, work smarter' (for same/faster result). I think some of the ways game dev is made are too archaic and 'slow push one vertice at a time' and 'code 50 000 lines to do software'...there needs paradigm change/methods changes to speed things (is too slowmo now), dramatically/exponentially. Technology has advanced, a little bit/ok quite a lot, but some techniques lag behind; and despite the CGI graphics we ahve now, lots of game dev stuff is slow as snail or like that turtle. Rabbit is future, not snail/turtle. Thankfully, the Asset Store/Marketplaces have been the largest contributor to game dev acceleration - using the manpower of everyone - for everyone/game dev democratising. Just a 2 c.
     
  8. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    I've finished smaller projects in the middle, but my current big project I restarted in 2017. I see on my dev blog site I need to update the ETA date again.... My excuse is I had a baby in the mean time, and he's now 2 1/2 and learned "daddy" is the fun one. So not much free time to work on it lately.
     
    JamesArndt and Antypodish like this.
  9. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Dear Joe, thank you for that. Congrats on being father. It's more than understandable that this was a huge event that could slow down game dev because of new family (time) commitments/priorities. Wish you lots of luck on your games and being dad (not to sound bad, but name is apt(ly put), it is perilous waters out there with trying to sell it (and not ship sinking)).
     
    Joe-Censored likes this.
  10. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    Dealing with Unity's bullshit.
     
  11. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Dear AcidArrow, thank you for that. I see, I am sorry to hear that. Hope you find what you are looking for (with Unity), one day.
     
  12. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,624
    I wish you didn’t add the “(with Unity)” part, since now I’m compelled to reply again.

    But in order to avoid taking this too far off topic I’ll say the following and then bow out of this thread:

    There’s nothing to find with Unity. If I have any Unity related goals, it is to somehow make enough money to buy Unity and then shut them down which will result in the world becoming a better place.

    Other than that, after we’re done with the next game, either I’ll manage to make a team where we can make our own “engine”, or I’ll quit the games industry altogether.
     
  13. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    @unitedone3D, thanks for your detailed explanation. I think it helps frame your questions a lot better in terms of the time a game developer spends to make a game.

    Your thoughts are essentially the reason why most experienced devs advise inexperienced devs to "start small" and "finish a game". There are a lot of unforeseen activities to finishing a game, that can only be gained through experience, and finishing a small game helps a developer to understand a bigger picture. It's a cliched example, but seriously, you train for a marthon by slowly building up to going longer distances. The principle is the same.

    I think, essentially, your questions are about Project Management. This is a skill learned with experience. With more practice, developers learn what they're capable of, and can more accurately estimate how long systems and assets take to build. They also learn how to set a goal end time, and how to budget that time to reach that goal. This is why kanban boards like Trello and processes like agile help keep the project on track to ultimately be finished.

    But, spoiler alert, we're all human, and even the best developers will estimate poorly, and projects extend, and this is where the sunk cost evaluation comes into play. Is it worth going on? For some developers, there is a point where you've spent so much time on it, that it's better to power through and believe you can finish it, because you've made all the right steps to that point to set yourself up for success. And the flip side of that is that, after years of work, you reflect on it, realize you haven't gained ground (because you've already experienced finishing a small game, right?), and cut your losses, and move on. So, those in the 8+ year dev range are either confident or delusional, or of course, casual as we've already established.

    Experienced developers will tend to double or triple an estimate for how long it takes to build a certain feature for their game. This buffer tends to come into play when you discover work that you didn't expect, or the result of what you built wasn't exactly what you expected it to be. This allows time for rebuilding and improving certain parts of the project. You can also cut features to still complete a project, and this is usually very difficult for developers to do. You weigh out how long a feature would take to implement, and whether the value to the player is worth that amount of time to build.

    This push and pull happens. It just happens. It's part of game development, and it's the part that no experienced developer can fully convey to a beginner, because it's their own path to take. If your project looks like S*** after 3 years, well, are you going to dump it or keep iterating on it to make it better?

    For my project specifically, the way I've handled it, is the first year or so, I spent nailing down the gameplay prototype with simple assets. Then the next couple of years of development has been a lot of building tools such that authoring my levels and assets goes a lot quicker, more fluid, and fully testable, and authoring art assets is as quick and easy as possible.

    I've gone back and forth between building systems and building art assets, because I've been uncertain between showing off or concealing my development for marketing purposes. On one hand, fancy assets look great for marketing, but your gameplay would be mediocre if you don't spend time on it. On the other hand, you can focus on the gameplay, and have crappy graphics. A demo would probably be interesting but wouldn't draw eyes to the game.

    Ultimately, after spending so long on my project, a good gauge as to whether or not to continue is whether I enjoy working on it, and it's still an overwhelming YES. Remember my difference between 5 years and 7 months? Well, in that time I've also worked on and finished smaller projects. It wasn't because I was unmotivated by my main project, but they were gifts for people. I'll still set aside time to do this, knowing that my main project can take long to finish.

    And as for change in general, you bring up a good point. We all change, the industry changes, and finishing a project is a moving target. There are some games that I've started building that I scrapped because a better game came on the market, and I no longer wanted to pursue finishing it, because my vision didn't add anything new, fresh, or different. Some people are lucky and have their stars aligned, such that they finish their 8-year long project once the WWII-zombie-crafting-battle-royale craze is just beginning and strike gold, and others are not so lucky. So, for those 8+ year developers, they're either constantly doing market research, validating the relevancy of their project/product, or they're living under a rock and hoping for the best.

    Holy cow I typed a lot.
     
  14. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Re AcidArrow, after being a decade at it I can only imagine your frustration... hope you stay in the game industry or make the great next engine. Although, I sense your deep disastifaction (from so long), I think we still have to be somewhat reconnaissant of the fact Unity Technologies brought their engine to a lot of people; game dev 20some years ago was almost non-existent for most but only the elite/AAA studio/rich people who could get a license for a game engine then. Same for Unreal. With your engine (if you make one), there would be your engine, Unity, Unreal, Godot, RPG Maker and I'm forgetting few smaller ones; but I think the message is co-existence, there is an engine for everyone. Do you really mean it when you say you want to shut down the whole thing. I feel that you feel that you may have chosen not the one you thought it would be and thus, would go back in time, to change for another engine. What do you feel needs change with the engine/or the company/or both/what happened?

    Re aer0ace, these are really great points, thank you. It's great to have long explanatory answers, sometimes, too.
    Wishing tons of luck on your game!
     
  15. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,816
    First version took 8 years to release. I was just never happy with earlier versions, got the UI re-done many times, and the environment art re-done about 6 times.

    Working on v2 now, which addresses all the shortcomings I learnt from the v1 release.

    The game was made part-time. I didn't have any long hiatus periods, except perhaps earlier this year being addicted to Rocket League for about 4 months and I got nothing done on my game :rolleyes:

    I'm in a good position now to finish, I work 30 hours a week contracting from home, which gives me a solid 3-4 hours each evening to work on my game. Nothing impedes finishing a game like having to work a 9-6 job with daily travel in traffic...
     
    aer0ace likes this.
  16. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    I haven't enjoyed it, creating a framework is from far the most boring.
    But it's a good thing to start with the boring things, and then do the interesting stuff (like when you eat a cookie, you start by the sides and then finish with the center).

    Fortunately, I have mostly achieved what I wanted to achieve, which includes learning how Unity works.
    I also have vastly improved my knowledge in C# optimization, just being able to manipulate strings without garbage has been quite a challenge but well worth it.
    The logging system I have developed can log about 30 times more logs than Unity's logging system, without generating garbage or slowing down the main thread.

    Also, I have seen too many games where modding have been added after the game was seriously advanced.
    The result is usually really messy, same for localization.
    These things are better done first, and can be re-used for lots of games, and Unity doesn't do that very well out of the box (well, maybe the localization is done correctly now, but not when I started a few years ago).


    It's just a matter of what process is used for the whole project.
    My last project was a 13 months (full time) project, where I wrote documentation (specification, design, test documents, reviews, etc.) for about 11 months and a half, then I've coded for one month and then checked for 2 weeks that everything was OK.
    It means that after 11 months of work, I had 0 lines of code written, and yet the project was nearly finished.
    For information, for that project I had been hired for 24 months full-time.
     
  17. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    And THIS is game development. I've redone my UI about 4 times already, still not completely happy. I expect at least another 2 revisions or so. Inexperienced developers will build it once, not be happy and give up.
     
  18. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    Dear Meltdown, thank you for that. I think the polishing/perfectionning of a product is a substantial contributing part of why games can take much longer than thought (the ''90% of the game is made in that last 10% (of which, is polishing)'');
    but it's more than understandable that we would wish a product we feel satisfied with - as long as we have enough time to continue polishing it; until, one day, we say 'ok, done/finished (enough)'...has some said before ''no art piece is ever finished...it is only abandonned'' (I think it was Leonardo Davinci that said that) and sure enough, we could 'polish it forever'...but then the piece itself could even lose some of its elements as its 'mutates/changes' as we continue refining it; I think there comes a time/moment when enough is enough/we need to set a sort of 'self-deadline' (plus, the ever (true) - life, short). We just have to move on one day and 'finish it/finalize it', 'let it out (for it to 'spread its wings' & fly on), a bit like letting your child go/leave, to fend for theirself 'out in the open' (because it's hard to let your 'baby' go, you nurtured it like a mother/father to her/his child, &in your game -'raising it/making it 'be/become' what it is' (like child raising) and now they are leaving after all these years). It's scary to think yet you only the best for them, that they prosper and 'find base/interest in people who wish to play the game you conceived/brought to life'.

    Let us take an instant to think about it....games are monuments, achievements, feats...like novels that stand the test of time...after all these years they still are read, seen, talked of...as works of achievement....games, same thing. In my view, even More, because games are no other media, the most interactive media; books, films, theatrics spectacles are passive, games are active and require your interaction. No other media in the 21st century is as powerful/reaching and deep as games, board games...but, especially, video games. They are the centuries 'books' of older centuries. People had made-up games then too, but never reached the interactivity and feeling that video games procure today.

    Once your made is game, it is made and exists, it is an achievement; now, we know there are 50 million games out there (and the staggering 100,000 mobile games released on Google store floors you) but that happens with all medias, count how many books or films there are...some books are more remembered than others; it's up to us to find the best subject for that book. Just a 2c. Wishing lots of luck on your game.

    Re Gladyon Very nice breakdown, thank you.

    PS: For people who clicked 8 years or more, just one more, did you find success if you released your game/it's finished?
     
  19. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    I cant be the only person here thinking this entire part of your post is really odd. I have never met another developer in my life who would write documentation and test documents and everything else before making the actual thing.
     
    Peter77 likes this.
  20. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Right out of college, I did this, because it was "the right way to do things", right? As I got programming jobs, the more senior engineers never even bothered with documents or paper. It's all in the code. Nowadays, it's more accepted that code is self-documenting, and I'm so glad for this.

    In my current job, we're still stuck on the idea of keeping numerous design documents, which of course are completely out of sync with the code.

    Documents are outdated the minute you write code.

    EDIT:
    I should also mention that documents are great for communicating what you are going to build to non-engineering types, and it does help to hash out more complex designs, but I would never design anything completely on paper first, then start implementing it.
     
    Last edited: Oct 21, 2020
  21. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    My company has a powerful quality assurance department.
    And all our customers do require specification, design, test, manual, and build manual documentation, which is mostly part of the ISO9001 standard.
    That's the bare minimum, some companies ask for more, usually having several levels of test documents.
    Most of the time our customers have other standards, specific to their line of work.

    But my best guess is that it depends on what type of companies are the customers.
    I usually worked with Alstom and Sagem (more precisely trains and planes), who both have high requirements about documentation and quality assurance, and their own assurance quality department on top of the specific standards they must apply.
    Other people on my company worked on medical projects, where the quality requirements are a lot more important.


    But to be honest, it's actually easier to code after having written all the documentation.
    That's because that way you have thought about what you're about to do, why you're doing it, and how you're doing it.
    If you code directly, you'll end up with spaghetti and bugs very fast, and each time you add/remove/modify a feature you add bugs and complexity.
    After some time you have only 2 solutions:
    - live with the bugs
    - start again from scratch

    My goal isn't to create one game, but to create several games.
    I intend to reuse my code for years, if not decades. So it cannot be spaghetti code.
     
  22. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    You're right, most of the time it's the case.
    Which is why we have a process in which if we deviate from the documentation in the code, then we stop coding, work on the documentation, and then start coding again.

    And that makes a lot of sense.
    If you need to deviate from the documentation while coding, it can be because of one of these reasons (most of the time):
    1. a change in the requirements of the client
    2. we haven't considered all the possibilities in some part of the design
    3. we have found out a better way of doing things

    1. In that case we have to adapt the price of the software, so we have to think about what the changes imply and present the customer with the new price.
    So we have already done most of the work required to modify the documentation, so it's not that hard to update it.

    2. It means that we have missed something, it may be very important and have serious consequences on other parts of the software.
    So it's better to take the time to think about it before starting to make some changes which may not be good in the future.

    3. In that case, same as previously, if we don't take the time to think about it, mistakes can be made, and the design could be wrong, requiring more dev to fix the problem.


    It's all a matter of cost.
    A problem found at specification level will cost 1 to fix.
    A problem found at design level will cost 2 to fix.
    A problem found at writing test level will cost 4 to fix.
    A problem found at coding level will cost 8 to fix.
    A problem found at executing test level will cost 16 to fix.
    Obviously the values are wrong, and probably not exponential.
    But it's a certainty that they increase when you're going deeper in the process (and I'm pretty sure they aren't that far from being exponential).

    It's a battle between an early gain (not losing time thinking before acting), and late gain (starting slowly to avoid problems at the end of the project).
    For small projects, it's usually not a good idea to do too much documentation.
    For projects where the customer pay by the day, it's usually a very bad idea to write documentation (because the more time you lose at the end of the project by fixing all the bugs, the more you're paid).
    For large projects where you're paid a fixed sum decided before starting the project, it is a very good idea to write a very good documentation, it will help avoiding spending 50% of the resources on the last 1% of the project.
     
  23. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Now you're talking. There's always a context to consider.

    What about the solo developers? I would imagine that the majority of Unity users are working on their solo personal projects.

    For my personal projects, my documentation revolves around preliminary designs, UI mockups, technical research around the various systems that I'm implementing, and that sort of thing. But never to the degree that I'm shuffling around parameter definitions for a function signature. They're usually large-sweeping architectural design documents. Never an entire document about risk analysis and testing methods. It just seems like the time would be used better on implementing things, implementing unit tests, and letting the code talk for itself.

    As I said before, I started doing this right out of college. I wrote so much documentation for my game, updating documents as I changed code. It was a good exercise, and I like looking through that document whenever I dig it up in my pile of old papers, but now it serves no purpose. The project was dead, and no amount of planning documentation would have helped me to finish it.

    There is certainly a difference between game dev and business software dev, and I would hope that you understand that. This is a great discussion that probably goes beyond this thread though. It's not my place to suggest that documentation practices from business software dev cannot be applied to game dev, but in my 15 years of professionally developing on both sides of the fence, I can attest to the practices being wildly different between the two.

    EDIT: Changed "planning" to "documentation". Let's be real here, everyone should be planning.
     
    Last edited: Oct 21, 2020
    NotaNaN and MadeFromPolygons like this.
  24. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,753
    Writing specification documentation and software rules before actual software, works well in many engineering fields.
    For example writing for PLC and SCADA, or mechanical, electrical designs.
    But then, you have specific hardware target and you can follow strict rules. I know, if I deploy it in one place, it is going most likely work in other place too. And for years / decades to come. There are common restrictions, how often updates and modernization takes place, to prevent potential breaking of the software.

    Communication and networking is often a bigger challenges.
    In such cases, you need test whole software. Can not for example exclude part of the feature, just because didn't have a time to complete it, or don't like it. Think about critical processes. I.e. imagine no chlorination in the water, just because is not fun to play with :).

    Then you test the software, following earlier pre-designed acceptance tests. Certain modifications are often allowed along the way of course.



    Problem with writing frameworks and game engines, is to keeping them up to date with hardware and software changes. In 5 years time, it will get quickly old. Having dedicated team for that is fine, but for solo dev... even AAA studios look constantly for alternatives, rather deving every own solutions.

    I found already few times, that some features I wrote, or was attempting to write, were later incorporated into Unity. Then I was able to replace part of my code, for better.

    On top of that, for someone who is using asset store, tons of assets become obsolete from year to year, as they are not maintained. Sure, can lock project on Unity version. But mobile games can not really do that as an example, if wanting keep them up to date and running. Desktop and console games are more resistant to dramatic changes.

    Another problem is, unless really knowing Specific game engine and having years in game deving., are hardware and software constrains. For example wanting have xyz features. But for some reason they don't want to cooperate with each other. On paper should work, but in practice it may be different story.

    Then question is, is design incorporates fun factor as well? What if deciding that features abc don't play nice, but wanting instead efg.
    Now starting really going astray from initial doc spec, as is nothing like it was, other than main game concept. :)

    Well that is my little take on it.
     
    Ryiah, MadeFromPolygons and aer0ace like this.
  25. aer0ace

    aer0ace

    Joined:
    May 11, 2012
    Posts:
    1,513
    Oh, and I totally butchered that quote. I meant:

    "Software documentation becomes obsolete the minute you start writing it."

    It's obviously meant to be a joke with truth in it.
     
    MadeFromPolygons likes this.
  26. Ryiah

    Ryiah

    Joined:
    Oct 11, 2012
    Posts:
    20,943
    There is a massive difference between coding before you've thought about how to approach the problem (at least I'm assuming that's what you meant by "code directly") and the process you outlined. While I take the time to plan out the way my code will function I prefer to do it in a reasonable time frame. Eight years isn't reasonable to me.
     
  27. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    Someone is salty :p
     
  28. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    That's a good way of course, but when you're learning Unity you don't know enough to do that level planning, and really just need to dive in and figure out how to solve each individual problem you hit.

    Though that could just be what you do in a prototype, then you step back after you've solved much of the knowledge gap and do your planning for the "real" implementation.
     
    adamgolden and EternalAmbiguity like this.
  29. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    3,967
    Well said! That said, 8 years really is a seriously long and probably "too long" amount of time...
     
    Joe-Censored likes this.
  30. Zapan15

    Zapan15

    Joined:
    Apr 11, 2011
    Posts:
    186
    It took 4-5 years (besides shool), we wanted to make a multiplayer game for the pc (LAN only). No coding, gfx, sound experience, and the engine did not support networking... We still like it :rolleyes:
     
    adamgolden likes this.
  31. unitedone3D

    unitedone3D

    Joined:
    Jul 29, 2017
    Posts:
    160
    PPPS: More food for thought (don't know how much it is credible/true but it looks/seems like it, games sold on Steam per genre, for 2020 I guess), interesting and nice complimenting addition to this poll here.
    https://www.reddit.com/r/gamedev/comments/jgbm3g/number_of_games_released_vs_median_earnings_per/



    (From this graphic, it seems we see (the obvious being) that the more complicated the game, the more interest it seems to find; well not 1:1, but complexity in a game surely makes the game unique for its very high level of complexity (this is the 'the game is a AAA' so because it is a AAA/very high budget/complexity... it obtains more interest -and even more, if it's a genre people *really want). a '4X' genre (the last one of the left) is not made often (blue bar) because very hard to make but look at the 'median earning' (red line), it is the highest earner. While Puzzle games are made by thousands, same for platformer genre...the one having the most hard time of all is 'Match 3' genre games, this is not working, at all. Clearly, people understood the message and so very few Match 3 games are made now (blue bar). From these stats, (for success) you want the red line at highest (earning) and blue bar at lowest (no competition). CRPG/RPG even JRPG are faring well overall. It seems (on Steam) 'building' games are very sought. As long your genre is in that range - to Twin stick, you're ok (to make 5000-10000$ min, wage). The instant you hit puzzle and that's it, it's chaos. Just a 2 cents.)

    Dear MadeFromPolygons, thank you for that. I agree too, 8 years is crazy/really stretching it...I don't think it is 'sane-wise' in terms of amount of time on 1 single project. A 'life' project, yes, but life project, I think, should end around the 5 year clock (no matter how big/small they are; just in order to 'limit our time' on a project (over the very long term)); otherwise, what says that people working 8 years won't work up to 10...11...12...etc...it can/may never end. Wishing lots of luck on your game.

    Dear Zapan15, thank you for that. Incredible/nice game, it does not matter if the graphics are styled from long ago, we can definitely feel there is Lots happening (explosion, shooting, flying...) in your old game, thus it had the quality of like a AAA/polish is there (despite old PSX1 graphs, it's even charming in that sense, retro console/PC DOS 3D graphics; it makes me think of 'Descent' shooter game on 1990s), it's clear. Wishing you lots of luck on your new game(s).

    Thank you very much to all for your valuable input and/or for voting on the poll! Thank you!
     
    Last edited: Oct 23, 2020
    adamgolden likes this.
  32. EternalAmbiguity

    EternalAmbiguity

    Joined:
    Dec 27, 2014
    Posts:
    3,144
  33. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Yeah... I have to agree that the Waterfall approach being discussed there strikes me as being especially unsuited to game development, for a reason that @Glaydon already mentioned:
    The Watefall model assumes that you can have perfect knowledge up front to be able to specify and design something in detail with confidence that it won't change. But you can't be confident of that in a game, for two huge reasons. First is that "gameplay testing" is not the same as functional testing et. at, it's a part of a necessarily iterative process. Second is that significant games are predominantly aimed at platforms, OSes and vendors which are constantly changing, so you won't have all the info at the start which you'll need to plan for the end.

    And that's overlooking the fact that in a long project the team involved will get better at what they do. I want to take advantage of that (within reason), not be chained to however we were back at the start.

    I've done projects with a Waterfall model before and they've generally worked well. Despite being a punching bag that model does have its strengths, so I'm not against it in principle... for the right projects. Using it for a multi-year project in a rapidly changing environment seems excessively risky.
     
    NotaNaN, Ryiah and Antypodish like this.
  34. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    You're quite right.
    That's what I realized, unfortunately I have been a project manager for a long time, and I have some trouble modifying the way I make projects.

    As you said, the Waterfall model implies that we have a precise specification of the final product, and that it won't change over time (at least, no big changes).
    That's why I've started by the framework.
    While the game will undoubtedly change a lot over time, in totally unexpected directions, the framework will not.
    Some new features may be needed, but the existing ones are there for good.

    After having done some proof of concept of the systems for my game, I've realized several things:
    1. I will not be able to have a precise specification for the game
    2. I have a lot to learn about Unity
    3. Unity is quite un-optimized in some places (for example, just writing a changing value on the UI will generate garbage if you do it 'the standard way')

    So, I decided to work on these 3 things.
    Point 3 requires to increase the knowledge in Unity and in C#.
    Point 2 requires a lot of work with Unity, and time.
    Point 1 is much more tricky, the idea I had (and still have) is to reduce the quantity of code written to create the gameplay (the reasoning is that if there's less code to write/modify, it's done faster and there are less bugs when doing the modification).
    In order to reduce that code quantity I have 2 targets:
    - Reducing the boilerplate code to an absolute minimum.
    - Having a lot of things which can be done by 'configuration'. In fact, it's externalizing the gameplay in the data (like JSON data, scripts, etc.) in order to avoid having to modify the actual code when I want to change some behaviours.

    That's how I came to start with starting with the framework over Unity.
    It makes me work closely with Unity for a long time and deeply in some occasions.
    As this framework has a 0-garbage goal and overall optimization in mind, it makes me increase my knowledge in advanced C# quite deeply.
    It integrates tools to externalize some data/behaviours, comes up with debug tools, and integrates about everything which is not gameplay (main menu, localization, modding, dev tools, script language, pooling, input management, ECS, string management, etc.).
    And it provides ways to manipulate the data with only minimum code, most of that is only a wrapper to many existing features, but with less parameters (most of the time we use only 2-3 parameters when a function has 8-9 of them).

    When all that is done (soon enough I hope...), then implementing the gameplay should be a lot faster than if done without all these tools.


    Good point.
    In order to try to offset that problem I update Unity twice a year, and I look closely at the new features to check if/when I integrate them.
    Usually I do not integrate the new features.
    For example, I have implemented an inputs management, and I will not use Unity's one.
    The reason is that I only use keyboard and mouse, so I don't need something over-complicated to work with any type of inputs hardware.
    For the localization, I prefer to use mine because it manage the localized texts as any other asset in my game (texture, mesh, shader, etc.), meaning that it's totally integrated, totally moddable, and in addition my localization system is garbage-free (pretty sure the Unity one isn't, but I admit that I haven't checked).

    My main problem is with the ECS.
    I have implemented my own ECS, but Unity's one seem to be a lot more powerful (because of Burst).
    But it has several problems:
    - it has a heavy boilerplate, compared to my ECS at least
    - it is over complicated for my needs (which is perfectly understandable, they haven't implemented it for me, but for everybody)
    - is is not stabilized yet (and probably won't be for a few years)


    Also, I have another goal with that framework.
    That goal is to re-use it for other games, and as I have complete control over it it will absorb a lot of Unity modifications over the years.
    It means that the game will be less impacted by the changes over the years than if I were to access Unity directly from the game itself.
    Well, at least that's the general idea, how it will survive the reality of the projects, I can only guess/hope...


    The reason behind all that is that I have observed that most indie games are often patchworks of bugs, and when you look into them (using ILSpy for the Unity games), it's very often really painful to try to find any logic/pattern in the code.
    I strongly believe that if one want to reduce the number of bugs and make modification easier to implement, one has to have prepared the battlefield in advance.
    So, I'm trying to avoid common errors, by making things differently.
    I will probably ending with with making new types of errors, but at least these will be mine ;)
     
  35. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    611
    And they're also games that are out in the market, making money and being enjoyed by lots of people. Players are not like those train and airplane companies you mentioned. They literally don't care what's behind the curtain.

    As long as they enjoy what they see on the screen, they're good. I'm not saying you shouldn't care for code quality or performance, but it's a balance game.
     
    ClaudiaTheDev likes this.
  36. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    10,753
    @Gladyon, I haven't heard from you for a while. I am glad you are with us. :)

    But have you ever though, you may be over engineering things in regards to Unity?
    Is really easy done, with eng. background. And I think is really a skill, not do it, when building a game. But it comes after some work with Unity. Myself, I love prototyping and checking out, what may work or not :)

    The problem we are discussing is, the time span. Whether is worth and willing to work on something for years, which is not effectively bring any visual results any time soon. And there are some people as well, building nice cool frameworks, spending ages, but not knowing what to do with it later, often getting burned out, before actually building a game. Is just another risk, adding to the equation. Hope won't apply to you :)

    However, own ECS I think this was valid approach, to look into 2 years back and before. Even then, could use existing solutions, i.e. Entitias. I remember while back, you were working on own ECS solution, so I see your point. But now, Unity DOTS and ECS become very approachable. I believe, you shouldn't have an issue, if you sit and spend a week, to learn principles with it, and I am pretty sure, you would like it. What's more important, it offers safe multithreading and is modular. And you can avoid GC as well. So I think it very fits in your goals.

    Regarding new inputs system, I haven't yet dived into it, and still using simple get Key etc. And I like it in its own simplicity. It is also easy to do key mapping. So I see where you coming from. But need to be aware, even for desktop, people do use gamepads and joysticks. So compatibility with these would be nice to have.

    I think most important part of yor framework you may be sticking with, is modding. Indeed, this is challenging to do it righ from very start. There are many ways of doing it. But even so, there are cool assets (sorry i forgot the name of the popular one) which really helps with that part as well. Worth to look at. I am aware, multiple large games use these, as modding solutions. Hence that could give you large kick start.

    Myself I was wanting allow modding in my previous (postponed) project. But I wanted it, withouth needing modifying dlls. Hence just my own approach to the problem. But not focusing on it with my latest project, as I want things keep going and I use it as DOTS learning opportunity.
     
  37. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Note that I know basically nothing of the project or developer(s) involved, so all of the below is just abstract discussion.

    That makes sense, in so far as people tend to resist moving away from things that have worked in the past. I think it's important to push past that, though, and figure out why things did or didn't work and how much of that applies to whatever new situation you're in.

    Be wary of premature optimisation! Yeah, allocation is "bad", but do you know what actual impact it will have on your game?

    I agree that there are parts of Unity which are poorly optimised, but there's no way I'd try to generically fix them in advance to "prepare the battlefield" in advance of starting a project.

    I see where you're going with this. My question is, have you considered bugs and errors that come from sources other than your code? Whether it's an incorrectly written line of code or an incorrect configuration item, a bug is a bug is a bug. Be careful that you're not just moving bugs from one place to another.

    Is it going to be seven years faster?

    You also mentioned that you have a lot to learn about Unity. With that in mind, how do you know what it needs to be faster than? It's like any other kind of optimisation. Do you know how long it currently takes to get key things done in order to know where to put your time saving efforts? Do you know what the results have to be? Do you know what issues need to be avoided?

    Keep in mind that a lot of game developers aren't experienced and/or professional programmers these days, because it's just one of many skills which are required to make games, and most of the actually difficult stuff is already handled by off-the-shelf engines. What you're seeing is quite possibly more a reflection of a particular team's skill in that specific area than anything else. And as others have already pointed out, if they've shipped a game that works they're already "good enough".
     
  38. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    Thanks, nice to read from you too!

    About the ECS, it's one of the things I'm not sure what I'll do about.
    Will I use my own ECS or Unity's one? The question is still open.
    I have postponed making that choice as far as I can, which is about mid/end 2021. At that point I will have to take a decision.
    So, in about a year I'll look at Unity's ECS state and see what I can do with it.


    Absolutely no idea, which is the problem in fact.
    Garbage is accumulating and will (that's a certainty) freeze the game for a small amount of time, but I have no idea when it will be.
    Will it be when the game is mostly idle (so no problem), or will it be just when the player is making an important action (which may 'break' the immersion feeling), it's not possible to say.

    The thing with garbage is that it's not like any other performance problem, it's accumulating, so in the end you always have to face it.
    Sometimes you can force a garbage collection at some points in the gameplay because you know that at that instant it will not disturb the player, like when there's a scen change for example.
    Unfortunately, I do not plan to have any scene change in my game (neither in the 2 following ones in fact).
    So, I have decided to minimize garbage generation in order to minimize garbage collection, and that must be done everywhere garbage is generated, which is at a lot of places in C# and Unity.

    Also, remember that it's a framework.
    So it's a set of tools, I do not know exactly how I will use them.
    If some tools are badly optimized it may cause troubles later, a bit like Microsoft when they made the framework, if some of their instructions are badbly optimized it may cause trouble to use.
    In addition, I know have taken the good habits about garbage generation, when I write code it's mostly garbage-free on the first try.

    Also, for information I worked for a year for a video games dev company about 20 years ago.
    In that company, they had some code already written do the the most basic and common things in a game (such as accessing files), that code was written for all consoles/hardware.
    They also had another layer, just over that one, to do common things which are a bit less basic (such as packing the files in one large file). That layer wasn't dependent on the hardware, but it was highly optimized as they re-used it for every game.
    So, in a way, I'm only reproducing that design. The hardware layer is Unity, and the second layer is a mix of Unity and my framework.


    You're right, it will not be 7 years faster.
    But, there are 2 points to consider:
    - I want good code quality, so it is bound to take more than the 'minimum' time
    - by creating such a framework, I will be able to re-use it for other games, so after a few games I may gain more than 7 years

    About the first point, there's some 'history' about it. About one year after my first professional coding experience, I had the standard annual meeting with the boss, and he told me that I haven't let enough bugs in the softwares I've written.
    The following year I had the same remark, but I was project manager at the time.
    Both times I answered that I would continue to reduce the number of bugs as much as possible because I owed that to my customers.
    So, over the years I have been given more and more projects/things to do simultaneously, and I have been forbidden wo write any code (I used to re-write the code of my devs when their code was too bad...).
    I have a bad memory about the fact that they forced me to reduce the quality of my work.
    So, when I do something as a hobby, it has to have a very high quality level, it's mostly for my own sanity.


    That said, I understand that my way of doing things isn't the most optimal one, far from it.
    But it's a way I like, and a way I believe in.
    That's enough to me.
    And I strongly believe that we must take at least some pleasure in creating games, and I know that if I feel that the code I write is 'too bad', I will not like that at all.
    The thing is, I've started coding about 30 years ago, and after about 10 years of it I stopped finding that interesting.
    I do it when it's necessary, but I take no pleasure in it, while I take pleasure in planning and designing, which is probably why I spend 90% of my time planning and designing, and 10% of it actually coding...
     
    JoNax97 likes this.
  39. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    What you are doing is considered waterfall. It's better to be agile and develop tools and systems as you need them.

    Though I like to see some one that takes their time to develop. Most here think that "good enough" is good enough and then they wonder why their spaghetti code breaks down when new requirements or systems are being incorporated into the game.

    So I partly agree with you, just that I think it should be done more agile.
     
  40. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    Well, I didn't make a statement to be "right". ;) I don't know what you're doing, there is definitely stuff where good tooling could save you years of effort compared to doing things manually, and timelines can be hugely blown out when you're doing stuff part time.

    I appreciate the consideration, but it does need to come with some amount of balance. Maybe your boss was being inconsiderate of customers, but also... maybe not? I have no idea since I have no idea what was being made, but an imperfect tool I can use now is far more useful in the moment than a perfect thing that I don't have.

    Plus, games are non-essential luxuries. Being entertaining certainly does not require being bug free.

    I agree that quality is highly important, but so is shipping.
    I'd love to go down this rabbit hole, but it'd be even more off topic than I already am. :) Suffice to say, I'd check the duration and frequency of those "freezes" before I put effort into generically solving them, especially considering that Unity now has iterative GC that spreads the hit out over multiple frames.

    Whether it's GC or game design or something else, I recommend that everyone look into the idea of "Fire Bullets, Then Cannonballs".

    It's a hobby project. It's "better" to do whatever makes you want to keep going.
     
  41. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    I'm pretty sure you're right, agile is the way to go.
    Unfortunately, all the agile projects I've seen so far have been... not good, for the best ones...
    I think it comes from the fact that my company wasn't accustomed working on agile projects, we've only done waterfall ones.

    I know that in theory, when you don't have a precise specification you have to be agile, but I also know that I'm not good at that.
    So I try to prepare the battlefield as well as I can do, because when I'll work on the game design I know it will be more agile, and I know that I will have a lot of trouble with that.


    In fact, thanks to all of you, I now understand that I've chosen that way to compensate with my inefficiency in agile projects.
    Well, I'll see in a 2-3 years how it works.
     
    JoNax97 and angrypenguin like this.
  42. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    For what it's worth, I want to commend you on the way you've participated in this discussion. You've consistently responded with honest, open and thoughtful answers to questions that would have put many people on the defensive. Huge thumbs up for that!

    Honestly, the number one important thing with projects is getting them done, and persistence is often more important than most of the other stuff we've talked about when it comes to that. So if your system works for you and means you'll get to the end then it doesn't matter what anyone else thinks. And, depending on the project and your resources, a 7 to 10 year timeframe could just be the reality of how long it'll reasonably take in any case.
     
    Antypodish likes this.
  43. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    Well, he wasn't wrong in fact, the company would have gain more money if I had made more bugs.
    The goal is to make software for other companies, they tell us what they need, and er do it.
    Our customers never find out all the bugs during the warranty period, so if we spend money (dev time) to make the software bug-free we're actually losing money.
    It's best, from a business point of view, to not fixing all the bugs and to wait for the customer to see them during the warranty period and to fix only these bugs.

    While I understand it, I absolutely hate that reasoning.
    And if you look into it, that's one of the reasons why some planes fall down... because money is more important than doing a good job.


    It's true that it's not that important if there's a bug in a game, nobody will die because of it.
    But I still think that the job should be done right. I know that as a player I like it when games are polished.
     
    Antypodish likes this.
  44. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    There is no such thing as a precise specification they will change during the course of the projects life. Therefor there is no place for waterfall, ever.
     
  45. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    Thanks.
    I suspect that there aren't many solo devs working for so long on their game, so I wanted to tell about my experience to give some food for thought about the original question.

    I would love to hear about other people who have worked on their game for 5 years or more.
    I'm sure we all have things to learn about the experience of other people.
     
    angrypenguin likes this.
  46. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    We are soon onto our fifth year. (may 2021). For us it's more a matter of finding time between other projects that make money and wife's and kids that steal time.

    We are enterprise senior developers so our approuch to the game is the same.
     
  47. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    Yeah, I have the same problem, having any realistic planning under these conditions is quite a challenge.

    Let's hope that time and efforts will be rewarded.
     
  48. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    389
    Well, I have completed at least dozen projects where the specification never changed during the project.
    Usually our customers need some very specific tools, often to test their specific hardware, so the specification is very precise as the inputs/outputs of the hardware are perfectly known in advance.
    It also depends a lot on the customer, some aren't able to tell what they need, they're always forgetting some features...

    But I guess that it's not really possible in video games as expected feelings are often different than real feelings, so when things are done we feel that making them differently would make the game a bit better.
     
    angrypenguin likes this.
  49. MDADigital

    MDADigital

    Joined:
    Apr 18, 2020
    Posts:
    2,198
    Frameworks and hardware can be more of a blackbox nature yes. But user applications like games a are a different beast all together
     
  50. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    15,614
    I'm not talking about money, though. I'm talking about the utility of the thing being made.

    Let's say I'm a carpenter. I make 1 item per day and sell it for income. My existing hammer just broke, preventing me from working. I can get an 85% good hammer now and keep working today, or I can wait one week for a 100% good hammer.

    Most people would go with the inferior hammer, because it'll get them out of trouble without costing a whole extra week of income. And they can get a better one when they're not in a jam if needed.

    And with software, we can give people the "inferior" (ie: not finished) versions and update it when things are improved, actually giving our customers the best of both.

    Even when we can't for whatever reason, delays to shipping can have a bigger impact than some bugs, and I want to take that into consideration when I'm doing stuff, separately from the profit side of things.
     
    aer0ace, NotaNaN and EternalAmbiguity like this.