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

Procedural vs Handcrafted

Discussion in 'Game Design' started by tiggus, Apr 1, 2016.

Thread Status:
Not open for further replies.
  1. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    Is that procedurally generated building placement with the road as input?
     
  2. Aiursrage2k

    Aiursrage2k

    Joined:
    Nov 1, 2009
    Posts:
    4,835
    Well look at something like binding of issac, its a roguelike shooter. I think he hand crafted the rooms, the bosses, etc then he shuffled them up in a random fashion so that people can play the game not 1 time but hundreds or even thousands of times.

    If I play something like "kick ass commandos" where the levels are handcrafted I have a better time playing it myself but it doesnt have the longevity . I'd actually just go with handcrafted because it will be faster for you as the designer to make that playthrough fun (it took vlambeer 2+ years to balance nuclear throne).
     
    Last edited: Apr 6, 2016
    Martin_H likes this.
  3. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    No, all procedural, including roads.
    I've got a pretty clear idea in which way the placeholder blocks are supposed to be swapped out with modular assets, but I still need to figure out the easiest or most flexible way for me to set that up. Got some ideas, but I need to test them first.
     
    Billy4184 likes this.
  4. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    The roads look remarkably similar to the approach I took, you can totally see which edges you dropped ;)

    I think it looks great. I love the buildings and blocks, think you did a fantastic job with this!
     
    Martin_H likes this.
  5. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    That's actually pretty cool, IMO. I'll bet getting a good fill ratio on the building zones was the hardest part.
     
    Martin_H and frosted like this.
  6. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    Yeah, and he did a really slick job on that part! The tiny buildings especially.
     
    Martin_H likes this.
  7. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Thanks guys, much appreciated! I bet you'll laugh when I tell you how I implemented that. Many years ago I've read an article about how someone implemented one of those "word cloud" generators. The author said something along the lines of "Thanks to *forgot the name* for his help, I raise my glass of wine in celebration of his genious approach of throwing random stuff at the screen until it fits." At least that's how it stuck in my head.
    I first generate a grid of nodes, do the stuff for the roads, and then I go through all the grid cells and try collision checks at random positions to place my placeholders. I have a sorted list of those, starting with the biggest ones. I define a desired amount per cell per placeholder and a maximum number of placement tries per cell. E.g. trying for 5 rather big placeholders with only 30 tries will give a high variance between 0 and ~3 actually being placed. Starting with the biggest ones leads to the somewhat even filling of space because the smaller placeholders fill the gaps. I have to really crank up the number of tries for the small ones though. But I don't really care if generating this "city" takes 1 second of computing time or 10, I consider it to be a part of level load time.

    The hardest part really was deciding for an approach how to generate this, not the implementation. I've tried many different grid based rulesets on (grid)paper until I came up with this one while scribbling in Photoshop. For such coding tasks I try to stick to super simple stuff that I actually understand. If I can draw the process on paper, I can code it. The hardest part is figuring out the "ruleset".

    What I have so far is a good start, but it has no "game" in it. I need to figure out what I need in terms of player spawn, objectives, level exit and things like that. I'd also like the environment to not be uniform. I'll probably come up with a simple system to make some areas have more explosive barrels standing around etc.. E.g. I could generate objectives first, scatter roads and placeholders around them, and then during the placeholder replacement phase they can check how close they are to certain types of objectives to skew the chances of randomly picking certain assets over others.
    I doubt that I will be able to make the final "city" (actually it should be more of an industrial area) "make sense" as in roads and buildings positioned in a logical way, like real industrial areas are built. That's not really on my list of goals.
     
    Billy4184, syscrusher and frosted like this.
  8. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    Take this or leave it, but I'd really suggest that you hold the random generation aside for a moment and prototype out the game systems next (if you haven't already). Just modify your existing output to build out a 'typical map'.

    You can use this prototype to help inform what rules you'll really need for the rest of the procedural aspects. An example where I made a mistake here was investing a week in building out the intersection meshes only to realize that in practice, I would stick big red spheres over the intersections anyway. Admittedly, you may not be making such a foolish error in the first place, but prototyping the game play will absolutely help nail down the specifics for what needs to be generated, where and how.
     
    Martin_H, Teravisor and syscrusher like this.
  9. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Thanks, that makes a lot of sense. I'm having trouble to decide how I want to proceed at the moment. I had almost settled for this not becoming a game and just aiming for it to be a 3D asset portfolio piece. Then I saw Deftly ( http://forum.unity3d.com/threads/released-deftly-flexible-top-down-shooter-system.328453/ ) and thought maybe I can focus on the procedural generation for now and see if Deftly happens to end up implementing the bulk of functionality that I need. I'm hesitant to just buy it and try it because so far I'm making use of approximately 0% of assets that I have ever bought. And I've found to be instantly lost once a Unity update breaks an asset. Also some others that have gone the buy-as-much-as-you-can route to make a game seemed to have mixed feelings whether or not that was a good idea. Some of the fun of making things yourself seems to get lost along the way. Also it might be hard to make things work together once you reach a certain number of different assets. If I could just buy a finished game that I just need to reskin and put my procedural generation in, that might be an easier choice. But so far I haven't seen anything close enough that could be adapted. Besides, I bought a starterkit for my abandoned iOS project and I ended up replacing roughly 99% of it with my own stuff, maybe even more. It was a very good choice at the time to go with a kit, I'm just not sure if I'd want/need to do it again at my current level of experience.

    So at the moment I'm trying to make up my mind where I want to go with this. I try to stay away from tasks that could easily turn into a week of work with questionable benefit. Maybe I'll be more motivated to prototype gameplay, if I manage to form a clear vision of how I imagine it to come together as a game. Currently all I can come up with are fragments of aesthetics or some features. I don't know of one game that could be a good base to copy and put a twist on either. I'll probably want it to be somewhere between Nuclear Throne and Men of War: Assault Squad 2, but with a lot less content and depth. And that description likely makes little sense to anyone but me, because AS2 is an RTS.
     
    frosted likes this.
  10. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    I remember that.

    I also remember hearing it and thinking, "OK, they want to end the trilogy - no matter what, Shepard dies this time, for realzies, no cyborg body to use as a plot-crutch." I had no problem with it. You can still have a future game in the ME universe; there's nothing stopping you from making ME 4 in the future 100 years after ME 3, or going the Dragon Warrior route with ME 4 being a prequel to shortly after Humanity discovered Mass Effect technology. Cutting off an arc doesn't equate to cutting off the series.

    Of course, I'm not "everybody", apparently, and here on the Internet, complaining (loudly, with profanities) is what we do best.
     
    Deleted User likes this.
  11. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    I think Tetris was prophetic; it's a story about Trump and building a wall out of blocks to keep the other blocks out.
     
    Martin_H and hippocoder like this.
  12. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    @Martin_H
    I wasn't familiar with either game, i just watched a few minutes of gameplay for both Nuclear Throne and Men of War... Tough to mix those. You're going to go through a lot of trial and error I think. There are some kind of shooter/rts hybrids out there, but I'm not familiar with them really. Always felt unnatural for me (I'm a starcraft guy), but just because it's not my thing don't mean it can't be a great game.

    As for kit or not, who knows. I can't imagine using off the shelf crap to get anything done beyond the prototype phase. I purchased two kits when I first started with Unity and never used a line of code from either, that said I did learn some tricks and techniques by looking at how they did stuff.

    I always found having more references to look through better. Although some of the asset store stuff is just a pile of junk.

    If you want to go for the portfolio piece - that's cool. But if you want to make a game, throw together a prototype before you spend ages on hypothetical assets or maps. You may be surprised at how your needs differ from what you may have thought they were.
     
    Martin_H and syscrusher like this.
  13. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    I'm going to chime in here, not "in spite of being relatively new (just shy of a year) to Unity", but rather "because of" that fact. First, let me say I think @frosted raised a lot of good points. As for me, I have come to Unity from an Elder Scrolls modding project. It was huge (almost 5 years, 35 voice actors, etc.) but turned out really well, and I've decided to do a game-from-scratch because that's the next logical step after modding.

    The lessons I learned from my previous project and am applying now in Unity are these, and I think they're engine-neutral:
    1. If your paycheck doesn't depend on your game-related project, then there's no such thing as wasted learning. If you are learning new skills and having fun, EPIC WIN for you. :) LESSON: If you're not getting paid, do what's fun (including learning, if that's fun for you) and don't worry about the rest.
    2. Scope creep is your worst enemy if it's unintentional, but can be fun if it's deliberate. My other project started as an in-game player home, and morphed intentionally into a full-blown town-house-multiquest combo. The decision to grow the scope was deliberate, because after getting the house mostly done I was having so much fun I decided to dream big. The trick is to make sure either (A) your scope is something you and/or your team can actually finish or (B) to decide up-front that you care only about the journey and not the destination, and you don't care if it's ever "done" or not. LESSON: Control what you can, and manage what you can't control.
    3. If you decide to go big, spend time right at the beginning thinking about your workflow. I had to manage 3500+ lines of dialog, with scripts for 102 NPCs acted by about 35 actors. There were tens of thousands of art assets I imported from published (and fortunately free) art resources shared by other modders. There were close to 400 custom models and textures I created myself in Blender and GIMP. Our mod was in alpha test for six months, then beta for another six months. How will you organize your files so vital work isn't misplaced or accidentally deleted? How do you keep track of voice actor auditions, and casting decisions? How do you track what lines are recorded and what lines are edited and what lines are lip synced? How do you manage your test builds? How does your team (if it's more than just you) communicate and keep track of task assignments? How will you track bug reports and feature requests from testers? LESSON: Workflow is boring and tedious but vital to success on large projects.
    4. Again, if you decide to go big, think about your tooling outside of Unity. All of the dialog for the other project was recorded and edited on my Macbook, but the game engine could only run in Windows, so my world editor had to run in a virtual machine. I was about 1000 lines into the dialog before I realized managing scripts, quest sequencing, audio clips, actor assignments and status, and lip sync files by hand was just not going to scale up. So I stopped and spent about two solid weeks building custom tooling to automate this. I set up a shared git repository for version control and to pass files cleanly back and forth between virtual machine and physical host. I used a relational database (MySQL in this case, but there are others) and a lot of bash shell scripting, plus some awk scripts, to create a database that tracked the list of characters, quests, and actors, and mapped them to one another. I could then edit the dialog directly in the dialog section of the game editor, and at the end of the day I'd export it to a tab-separated file. My tooling then imported that file into the database, examined my hard drive to locate the audio and/or lip sync files -- if present -- and recorded their status into the database. All of this got chained into a Drupal web site that used custom PHP code to allow each actor to download a formatted, printable version of their script for each of their characters, and I even set it up so they could choose large print format to make it easier to read from a lectern during recordings. I could login to the same web site to query the status of each line for each character, to use for planning the next recording sessions or to see what I still needed to edit, import, and lip sync to the avatars. This tooling still left me with hundreds of hours of labor on the dialog part of the project, but without it the entire thing would have been infeasible. Obviously, Unity has better features than the ten-year-old engine I was using before, but these are the kinds of problems that aren't intrinsically solved just because you're in Unity. Importing a few dozen art and sound files is trivial; managing a few hundred thousand is not. LESSON: You don't have to have your tooling all in place to start, but know that you will eventually need to spend time buying or building some, and plan for that in your scope.
    5. As a corollary to point #1, some of your decision about buy-versus-build can be driven by what you are good at, and what you most like to do. Again, if it's your hobby and not your job, you have more latitude to decide (but probably less money to buy). I happen to have many years of industrial controls engineering and database design, and system and network administration. So I'm building my own database tooling for managing persistent (game save) data for multiplayer. I'm decent at Blender and Audacity, but not very right-brained good at art or music. So I'm buying 3D models for creatures and people, plus music tracks, from the Asset Store and elsewhere. I'm building my own scene management logic because Unity off-the-shelf can't do what I need. The UI design is an interesting hybrid: I'm lousy at graphics, so I'm buying the "skin" part, but I'm choosing to build the actual HUD and so forth myself even though I stink at it, simply because that's a skill set I wish to acquire. And there are a few assets that I buy either (A) because I want to learn how someone else did something or (B) because the cost of the asset is way less than the value of my time to replicate its function. I am absolutely capable of writing an HTTP protocol client in C#, but I bought that off the shelf because I couldn't justify my own time investment to create this utility. Businesses refer to this sort of analysis as "focusing on core competency". It's a buzzphrase, but it's got some value here. LESSON: Build-versus-buy doesn't have to be an all or nothing proposal, so choose for each component of your game based on what you can do and what you wish to do.
    6. As a corollary to the preceding, take stock of your pre-Unity experience and skills. This can guide you in scoping your game project, in deciding if you need to recruit collaborators (and if so, the needed skills), and in deciding what to buy or not buy from the Asset Store. My industrial controls background has been an amazing boost as I leap into game programming, because it turns out there is a lot of problem-domain overlap. LESSON: Real life isn't left behind in Unity-land.
    7. Departing from the generalized comments above, I have two specific asset recommendations for you: ProCore Bundle, and Script Inspector. If you're prototyping, ProBuilder (part of the bundle) will let you crank out a lot of "grey box" level geometry really fast. And Script Inspector lets you edit C# inside Unity without having to open Monodevelop.
    I hope the above is helpful. As I said at the beginning, I'm certainly not a seasoned pro in Unity. That's why I decided to post this -- because the learning process is still so fresh for me (and still ongoing) that I haven't forgotten the newbie learning curve yet. :)

    All that being said, those on this thread who are seasoned pros, please by all means feel free to set me straight if I've given bad advice. I'll cheerfully listen and learn whatever you care to teach and share.
     
    Last edited: Apr 7, 2016
  14. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    LOL, dude, that was probably the most solid, professional guide style post I've read on the Unity forums ... maybe ever? LOL!

    It's incredibly refreshing to have someone post something useful and serious about how to actually get something done!
     
  15. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I actually have a bunch of questions about your experiences - this one I've always wondered about though. I've been thinking about contacting modders about textures and models and the like. There's a huge wealth of textures, meshes, etc in modding communities. I'm wondering how much of it modders themselves may actually own the copyright for?

    In the above it sounds like you did quite a lot of it yourself, is that often the case?
     
    AndrewGrayGames likes this.
  16. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Yes and no. In Elder Scrolls modding, Bethesda provides the editor ("Construction Set" for Oblivion, "Creation Kit" for Skyrim, "GECK" for Fallout series) as a free download if you have bought the game. You're legally allowed to make custom levels, quests, companion NPCs, and so forth, by recombining their existing assets (dungeon tiles, foliage, etc. -- roughly the equivalent of Unity prefabs). Those of course come with textures and meshes already supplied. Beginning-level modders are doing just that, in very creative ways.

    Those who are skilled in 3D modeling with Blender or 3D Studio can create and import their own meshes and optionally their own textures. You are legally allowed to use Bethesda's textures on a custom mesh, or to modify and reimport their own meshes and textures, as long as your target is the same game from which you exported. For instance, I made several hundred variants of their dungeon tiles for my own quest, but I mostly used their textures. I also created a lot of original tiles that would mate with theirs but were my own completely original geometry. I cannot legally reuse their tiles or textures in Unity, but I could legally bring my own fully custom pieces into Unity as long as I replace Bethesda's textures with those to which I own copyright. The ones where I modified their mesh are a grey area. IANAL, but I suspect it would depend on how extensive my modifications were -- but the textures are definitely theirs.

    There are also a lot of modders who provide replacement textures for the game, often at higher quality than the originals, and most of those people give permission for their textures to also be a resource for other modders in custom meshes.

    Toward the end of the project, I had acquired tools and skills to make my own textures, so as the project evolved I relied less on modifying Bethesda assets and more on creating my own from scratch.

    Mods vary in scope from a simple tweak ("I think player starting health is too high, so here is a mod to reduce it by 25%") all the way to "total conversion" mods, in which the modders (usually a team) use the Bethesda engine but basically create their own art assets to make a totally different game. Our mod is toward the large end of the spectrum of in-game content, comparable to some of Bethesda's own DLC packs, but it was a much smaller effort than a totally from-scratch RPG.

    The other lesson, not mentioned in my previous post, that I learned is that you can't make a better Skyrim in your spare time with one person. I always knew that a AAA game is a huge project, but in doing our mod which was maybe the equivalent of 1% of that, I gained a very deep understanding of just how many unseen people have to come together to make a really great RPG. I still laugh (and sometimes cuss) at bugs I find in commercial games, but I'm a lot more forgiving now that I understand firsthand how hard it is to perform QA testing in such a complex world simulation. Of course, that's also how I fell in love with game programming. :)
     
    calmproto and frosted like this.
  17. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    tiggus likes this.
  18. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    Talk about convenient timing, thanks!
     
  19. clickrush

    clickrush

    Joined:
    Apr 5, 2016
    Posts:
    24
    Procedural vs Handcrafted is literally just about technique. The outcome is not bound to have any properites regarding depth, complexity, compelling story arcs or anything that we would like to attribute to either of those techniques. Take for example Dwarf Fortress, a procedurally generated game which surpasses many handcrafted ones in its depth even from a lore/story perspective.
     
  20. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    Sorry, I never got around to replying to this. Thanks a lot for sharing your experiences! I'm sure they will be quite valuable for a lot of people around here. That level of modding experience sounds immensly useful to make a game from scratch. I'm sure you'll come up with something cool!
    I'm tagging @Billy4184 to make sure he has seen the stuff about handling voice acting assets because it sounds highly relevant to one of his future projects.
     
  21. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    MVP in this thread - you. Holy crap, that's some excellent information. And I've been a Unity user off and on for six years!
     
  22. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    Cheers and yeah @syscrusher I saw your post, and I was glad to find that you valued workflow at least as much as I do. Even though you seem far more experienced than me, I've spent hundreds of hours in blender and substance designer simply trying to find the fastest way to create assets, reusing materials and detail maps, making modular kits and editor extensions to build them, and so on. For me an greatly optimized workflow is not so much an optimization but merely brings within the realms of possibility the kind of game that I want to make.

    As I've said in other threads (and perhaps in this one), I think the best approach is to look at the workflow from first principles - try to envision how it should be, rather than simply what seems to be the most commonly used - which usually for me means imagining a lot of helpful streamlined tools. Then, try to find ones out there that are already made and tested (which is surprisingly often the case), and only if it doesn't exist, and seems feasible, try to make one myself.

    On top of that, I think the best thing for workflow is to avoid work entirely, and buy assets rather than making them yourself if possible.
     
    AndrewGrayGames and syscrusher like this.
  23. Deleted User

    Deleted User

    Guest

    Then welcome to the world of subpar mediocrity..
     
    Martin_H likes this.
  24. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    I don't mean full game models, but things like textures, sfx and animations. We'll see.
     
  25. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    That's a really good point, @clickrush, and also touches on the issue of whether level design is intrinsic to the depth of the game concept or not. If the whole point of your story is slaying the Dread Queen of Badness in her magical lair atop Mount Scary, then perhaps procedurally generating her castle is not a good design choice. But in that same hypothetical game, if the player encounters random enemies during interrupted fast travel (like in Dragon Age, for instance) then using some random content there would be a story plus because it would add more variety to the random encounter zones.

    I love Portal 2, in just about every way, especially the voice acting. But only a few levels really have to be a certain way to further the story. If Valve had a smart enough procedural generator, they could have done that on a lot of the levels because they're just puzzles to be solved. Very cool, intriguing, stimulating puzzles, but not linked into the story as unique settings.
     
    clickrush likes this.
  26. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    For anyone working solo or in a very small team, our scope is limited by our time, and good tooling is a "force multiplier" with respect to time. :)

    Amen. I am actually a little sad to see that so many of the tutorials for Unity, which is IMO an awesome engine, assume a simple drag-and-drop manual workflow. My previous experience tells me what I need here in Unity, but it's hard to find solid examples of how others are already doing things the right way. This thread has really made me rethink my own project in terms of how procedural vs. handcrafted fits into my model of how I want my workflow to go. It's clear that I haven't thought it all the way through yet, so I'm going to spend some time doing that.
     
    Martin_H and Billy4184 like this.
  27. clickrush

    clickrush

    Joined:
    Apr 5, 2016
    Posts:
    24
    I'am not sure if i've ever encountered a smart puzzle generator which generates well designed puzzles, except if the puzzles are basicly based on random placement/configuration of elements. But as soon as your elements are very tightly coupled into a system that allows only for 1 way to be solved then it gets really hard to do it right in an automatic way.

    The problem with such puzzles in particular is the fact that you want to have a learning progression, where you show the player a new technique or way of thinking in every next puzzle, sometimes only to use previous knowledge to deceive the player first and force him/her to unlearn something. These very intristic and advanced design concepts are very much tied to psychology and need a careful designer to develop. I think Portal fits into that category. The game which is perhaps the best example for this would be Braid. I cannot even imagine a generator for Braid puzzles because the game is so full of details which are carefully crafted and placed, as if the designer knew with every step which mistakes you are gonna do.
     
  28. Deleted User

    Deleted User

    Guest

    There's many things not worth doing yourself, lets say generic assets like speedtree / rock decals etc. I'm pretty sure many can't tell the difference between one generic medieval age barrel to another. Although there is a certain point where it stops becoming your game and becomes a generic mishmash of other people's ideas.

    It can take more time to collate a cohesive design with third party assets than it can be just to do it yourself, as for SFX / animations they are all personal to the type of game you're doing.

    With textures, it's not hard to overlay / change / add normals to existing setups.
     
    Martin_H and frosted like this.
  29. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    You won't find stuff on the asset store that deals with audio remotely adequately.

    You need a lot of stuff built very specifically in order to do a good job on audio, and afaik, there isn't anything on the store that will get you there.

    There is as much difference between professional audio as there is professional visual, there is also a very different set of approaches taken in how audio is cut apart and built. I haven't seen anything in the store that approaches music really professionally... for FX you do have the boom library sets.
     
    Billy4184 likes this.
  30. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    Yeah, whatever I can avoid making, I will, as long as it doesn't make the game bad.

    I'm kind of surprised there isn't a building generator made to work with modular packs on the store. It seems feasible to make one, since presumably the packs are not incredibly difficult to use. I've been tinkering with one myself, so far it only makes rectangular rooms with floors and ceilings, I'm trying to figure out how to most efficiently transfer a floor plan from someone's mind to the program.
     
    syscrusher likes this.
  31. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    I wonder how many projects got ditched because, even though the mechanics and such were not finished, the developer thought to themselves "I've been working on this for a year or two, I've got some mechanics and level design, but haven't even started on the content, do I want to make assets for another 5 years? Screw it!"
     
  32. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    I'm not so sure. I've seen some cool projects that are full of nice features but are still at the 'blockout' stage art wise, and then they disappear. My guess is that they are primarily made by programmers who, in an effort to avoid having to think about art, keep adding features and expanding the scope and rewriting their custom engine, because that's what they find fun. A lot of developers seem to think that art is 'not that important' or something we'll sort of 'knock it all out at the end, just before release".

    But the fact is that even most AAA games are pretty much just reskinned from previous ones, and most of those years of development and 50 million dollar budgets go into making art. It's like 95% of the workload if you are modelling, texturing and animating everything yourself. It might take a month of hard work to make an inventory system or something, but to make one single AAA character alone can easily take that long, and it is like one tiny bit of all the stuff you need to make.

    You might think it's funny when I say that I'm going to revolutionize development, but if I don't find a way frankly I think I would be wasting my time going it solo. And most of that revolution will have to be in workflow optimisation and trying to add procedural generation in such a way that I can still have control over the stuff that I need to control in order to make the game interesting.
     
  33. Deleted User

    Deleted User

    Guest

    Thing is you need to really, deeply understand what needs to be revolutionized before you can do it and that takes years, there's millions of developers out there quite a few smarter than you or I and much much more experienced to boot. If they can't do it, what makes you believe anyone here could?

    I can tell by some of your previous points you're starting to hit reality, now you're down time to pick you back up.. Go for it, there's no reason you can't make a gorgeous looking game with plenty to do. It's just going to take a long time and you need to be stubborn..

    Do it for the experience if nothing else, due to experience I've made stuff some don't believe is possible. From engine frameworks to games.. But I spent years learning how, it didn't just manifest itself over night..
     
    Last edited by a moderator: Apr 12, 2016
  34. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    And, most importantly - sometimes you have to fail, to figure out how to do it better. Don't fear the reaper.
     
  35. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    Actually I don't think I've hit reality at all, when I start saying that something is difficult, it's because I am about to attack it :D

    But I don't know what is different about what I'm saying now. That's precisely why I've been banging on about character creators and such, never once in all my posts on this subject have I said that one person can create an AAA game doing unique modelling, texturing and animation for all the assets. I've been preaching unscrupulous practices and corner cutting, such as buying bulk assets such as textures and animations, and using 'generic' asset creators, since day one.

    All I was trying to say was that asset creation is a big enough wave to break the back of any project, and I think possibly some projects that apparently died due to 'feature creep' actually died of the inability of the developers to move onto the phase of content creation, and they ended up trying to wow people by just adding more features while they tried to figure out what the hell to do about it.
     
    AndrewGrayGames likes this.
  36. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Oh, I quite agree -- I was speaking of some hypothetical future puzzle generator, not implying that it exists now. :) My point was really that many of the levels are just puzzles of increasing difficulty, that the story progression didn't require specific layout.
     
  37. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    What I'd like to do is be able to have an overall 'story' where the reward for clearing a segment is access to a new mechanic. Upon getting said new mechanic, the game generates a level that forces you to use said new mechanic procedurally.
     
  38. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    Check out Dungeon Architect. I haven't tried it yet, but I find its node-based rules editor pretty interesting, and it works with some of the existing modular assets (or with your own modular assets).
     
  39. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    Wow. Looks like I was looking in the wrong place. That looks like a really cool asset.
     
    syscrusher and AndrewGrayGames like this.
  40. syscrusher

    syscrusher

    Joined:
    Jul 4, 2015
    Posts:
    1,104
    The generating algorithm seems deeper than a lot of competing assets. If you decide to buy it, please send me a PM and let me know what you think, because I'm giving it serious consideration myself. (In case anyone's curious, most of my own content will be hand-generated, but I want a procedural tool for specific content subsets and testing.)
     
    AndrewGrayGames likes this.
  41. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    This is the case for almost all my projects. The fun factor causes them to get scrapped before content is an issue.
     
  42. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    The fun problem is extremely hard to deal with because it's so nebulous. It's so hard to pinpoint the problems and making changes can really take forever.

    The thing that kills projects isn't so much "man, there's a bunch of content I need to build then it'll be awesome!" it's ... "I really have no idea if anything I can do will make this good".

    Although, who knows, maybe I'm projecting. This was certainly my experience.
     
    GarBenjamin, Martin_H and tiggus like this.
  43. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    Almost makes me wonder if we should have a "failed unity projects" subforum. It could be funny to show off our worst disappointments to other developers.
     
    Martin_H and frosted like this.
  44. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    I agree and this is why I am shying away from procedural in my current project. It's hard to make a complex puzzle/level design. Now to procedurally generate something on the same level of that is WAY harder.

    I'm not trying to cut new ground in procedural generation, I just want a game that is fun and the easiest way I know how to do that right now is to handpick the experience the player will get.

    I've decided(see my other thread) the best way to address the replayability issue is to allow and encourage mods so that other players can rewrite the story and environment in ways I would never be able to do procedurally or with my own imagination. We'll see how it plays out but it is passing my gut test right now.
     
  45. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    I didn't miss the point, I just think that for a lot of games that isn't the only or main factor in the project being ditched.
    It's certainly an issue though. In terms of the fun factor, well first of all I think that you have to keep in mind some simple rules. I watched a video a long time ago where some people did a talk about adding fun factor to games. The example was simple, a pong game, and it started off being a skeleton. During the presentation, they added stuff to the game that made it progressively more fun, and it had nothing to do with gameplay mechanics. I can't find it now for the life of me or I'd link it.

    OK pong is a simple game, but I think the same holds true, I think these simple rules scale well. For example, the main thing is feedback. When the player does something, there should be a disproportionately large amount of feedback, in terms of sound effects and visual effects (such as a really rich cutting sound and the enemy staggering wildly after taking a hit from a sword). A player is hooked into repeating the behaviour if it feels very pleasurable for them. Every single successful game, from Candy Crush to Mass Effect, take full advantage of this.

    When I started in Unity, I bought a game called Gigantic Army, a 2D side-scrolling mech game. It's very short in length, and has no enemy AI to speak of, they literally just walk at the same speed and fire at you about once every ten seconds, with very slow bullets. Yet, it's fun as hell, because it is an absolute banquet of visual and auditory feedback. Just listening to the mech clanking along was almost worth playing the game! That's probably the first time I realized how little ingenuity was required to make a 'fun' game.

    But yet, I see so many indie games that feel empty and lifeless. You open them up, and there's no immediate hook, it just goes through the paces of being a game. You keep waiting for it to tickle that fun-factor bone and it never happens. There are opportunities everywhere to add sound effects and visual effects, from the moment the game starts, to the main menu, to the loading screen, and into the game, but it never happens, or it is too little. Why? I think for one thing, a lot of indies underestimate the fact that these 'little' things are actually the foundation of the game. And secondly, I think they feel like they're being superficial when they focus on it, that the player 'should' like the game because it gives them the opportunity to explore 100 square miles of procedurally generated terrain, or because it has some 'ingenious' strategic gameplay or other, or because it has a deep story with some really awesome twists. The problem is that these things are really fun for the developer to make, but not so fun for the player, who often doesn't really care.

    For me, the main difference between a professionally developed game and the average indie game is the 'lifelessness' of the indie game. In the indie game, you can almost see all the moving parts, you can tell "oh, ok, that's where they wrote"if (go past this point){ make the roof cave in}". But in an AAA game or whatever, it is so finely designed that all of the visual and auditory cues blend into an experience that is simply exciting.

    And although some of this experience is due to the quality of the visual and auditory effects, I think actually 95% of how good it is is simply that all the details are there, that something does happen when you do this, that there is feedback present at all. Because in a lot of indie games it seems like there is so much missing.

    TL DR read it :)
     
  46. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,009
    EDIT:Moved to pm
     
    Last edited: Apr 13, 2016
  47. Martin_H

    Martin_H

    Joined:
    Jul 11, 2015
    Posts:
    4,436
    I got your back!


    While I agree that this stuff is super important and often overlooked by indies, I'm not convinced that you can "juice up a turd". I'm with @frosted on this one, making games fun to play is bloody hard imho, even with juice added. The mobile game that I abandoned was pretty juiced up in my opinion, I had everything done except the tutorial, and level content. Frosted was spot on with this one: "I really have no idea if anything I can do will make this good". And then I lost all motivation and quit working on it, feeling guilty about it for roughly two years.
     
    AndrewGrayGames and frosted like this.
  48. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    I remember that video too. The trick is: it's hard to know when you're just polishing a turd...or even worse, juicing a turd.

    The biggest challenge that I've hit as a developer is looking at an unfinished product and knowing if it's a turd or if it's just got more work needed to make it good.

    I think the big problem facing most of us is that we don't have a lot of experience actually making games. Most of us haven't seen a game go through all the phases from an idea to a released product. The challenge here is that we don't know what to expect of a game in it's early phases or mid phases.

    This is one of the big advantages that guys who come from big studios have, it's also one of the reasons that working on a bunch of games before you take on a big project is a good idea. If nothing else, it helps to calibrate your expectations of a project at the different points of production.

    I spent a good amount of time trying to juice my last attempt, it helped for sure. But there were bigger problems with how the game played that juice just couldn't overcome. But the truth is, I'll never know for sure. Maybe if I just spent another month adding a dash of this or a shot of that - maybe the whole thing would have worked.

    But after spending months and month and months trying to do - adding a little this, tweeking a little that, adding more awesome effects, raising the stakes on x, y, z, I had to throw in the towel on the design. I tried so many different things, but it just wasn't fun for more than 20 or 30 minutes. It was repetitive as hell after an hour and bordered on exhausting to play.
     
    Martin_H and AndrewGrayGames like this.
  49. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    That's part of the reason for the last few months I've been working on my physical prototyping more. It's much easier to make a fun game out of coins, paper, d6, and my overactive imagination, than having to write code, debug code, create art, get open-source SFX, write music, write more code, and debug more code.

    Physical prototyping reveals weak concepts, and their weaknesses. For example, I was working on a space-based concept based on Star Trek: Voyager about a ship that is trying to reach Earth. Just typing it, it sounds rather simple - you're trying to travel, while managing energy, and the victory condition is reaching Earth. In practice it was anything but simple, and in fact quite tedious - I had to generate entire solar systems and come up with specific events, and all this stuff that was actually quite a pain to run.

    Sure, I could've written a digital DM to do it...but the rules governing these things took so long to actually do and had logic holes you could drive the Delta Flyer through, that it was un-fun, and the part that actual players had in the game was so small by comparison, it just wasn't worth following through on. I gave it a couple of iterations over about three weeks, but when that three weeks had gone by without a worthwhile prototype coming from it, I gave it the axe. I may revisit it later.

    Long story short - if it's not fun for the player, it's worth dropping; you can easily discover a better game concept, because ideas are cheap things.
     
    syscrusher, Martin_H and frosted like this.
  50. frosted

    frosted

    Joined:
    Jan 17, 2014
    Posts:
    4,044
    Just to digress back to procedural generation - I was looking through some old videos I had, and I had one talking about my old map generator:



    I recorded this to show a couple buddies, but who knows, maybe someone will find it interesting. Man, I miss the old black skin.
     
Thread Status:
Not open for further replies.