Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice
  3. Dismiss Notice

How to simplify things

Discussion in 'Game Design' started by juicebox_boy, Jan 28, 2015.

?

Am I a fool for asking/saying this?

  1. Yes

    0 vote(s)
    0.0%
  2. Super yes

    0 vote(s)
    0.0%
  3. Maybe

    8 vote(s)
    100.0%
  1. juicebox_boy

    juicebox_boy

    Joined:
    Jul 21, 2014
    Posts:
    11
    Hey guys,

    Looking for some hard hitting honest advice.

    I've been working with the unity system/learning for about almost a year now. When I first started I was told "make small games and complete them." I have done a few basic "dumb" games for practice (stuff with no originally but helps understand programming).

    I really want to work on my next project which is much larger 3-d game, but don't know how to divide out the work. It's larger but I just am thinking can I really do this by myself? I shouldn't go into a project thinking like that but that's what been going through my head.

    So my question is ,for the some of you that went from making simple games into your first "bigger project," something like is a full adventure start to end game (not a "quick" game that the game can be played in a few minutes but repeats with different levels over, not that there's anything wrong with it), what were your first steps and did you do it by yourself?

    I've been trying to learn maya now as well as unity, animation, and level design...I'm getting about a C- at best.

    I'm signing as I'm writing this because I know I sound like I'm looking for the easy answer/way out but I just feel kind of lost and feel I can't jungle all of the balls(positions) needed. I'm basically airing out my thoughts.

    Thanks for reading and sorry if I sound like a fool,
    Patrick
     
  2. Kiwasi

    Kiwasi

    Joined:
    Dec 5, 2013
    Posts:
    16,860
    Random thought dump on coding in this situation

    Modular design is important. Just because you are the only developer on the project doesn't mean you should take shortcuts here. Pretend other people are going to be using your classes. (By the time you go spend a couple of weeks on artwork your code might as well have been written by a stranger.) Keep as much private as possible. Don't change your public API. Make your classes complete.

    Ideally you should not need to think about any of the details of any classes you are not working on. The public API should make it obvious what you can call, why you can call it, and what it does. Trying to understand the entire code base at once is a recipe for insanity.
     
    angrypenguin likes this.
  3. wccrawford

    wccrawford

    Joined:
    Sep 30, 2011
    Posts:
    2,040
    I think you're still skipping a step. You're jumping from small to large, and skilling small-ish, medium, and medium-large.

    You've found that making a game with 1 level is easy. Now make a game with 2 levels. You can even use the same game, probably! Just make a scene change.

    Then make a game with 5 levels. Again, can probably be the same game.

    Then add in menus, and level selection, and other things, 1 piece at a time.

    At any point, you can start on a new game and start from scratch or work on the old game, as befits the situation.

    Once you've figured out how to do each individual step, fitting it all into a huge project is a lot easier to understand. In fact, I'd say that until you've done each small step, it's practically impossible to understand how it all fits together.
     
  4. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    12,758
    Here's a different perspective: Start your large game. (Large, not huge. You're not going to make Assassins Creed by yourself.) Do your best to make it modular, for example by making separate test scenes for each key piece of technology (moving around, interacting with objects, switching levels, etc.) Use stand-in assets; don't create content (models, text, etc.) until your tech is mostly done. Keep notes.

    At some point, you'll realize it's a disaster. That's okay! Drop the project. It may sound counterproductive, but there are some insights you can only gain after tackling a big project. Hold onto your notes, code, and content. You'll be able to salvage pieces for later projects. If you need a breather at this point, finish a tiny game. Then take your large game from the top again with all your new insights!
     
  5. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    @TonyLi speaks the truth. The only reason I'm able to be working on my Eastern RPG now, is because of a prototype RPG that laid most of the groundwork that I realized was a terrible idea. That said, I'd put effort into designing cohesive, uncoupled code, and I kept my code! That's saved me months of time on framework development - or, $100 towards buying, and subsequently weeks of time on customizing ORK.

    And you're missing an answer to your poll: "No." It's never foolish to have a bad idea/bad concept/bad game so long as you learn from it. Fools fail to learn.
     
    BrandyStarbrite and theANMATOR2b like this.
  6. galent

    galent

    Joined:
    Jan 7, 2008
    Posts:
    1,078
    if you're trying larger / more complex for the first time, it's probably a good idea to pop out to the asset store and pick up a framework or a complete project to build off of. Project complexity scales exponentially, not linearly. A good framework or even a complete(ish) project will get you started on a whole bunch of fronts.

    Good luck!
     
  7. Deon-Cadme

    Deon-Cadme

    Joined:
    Sep 10, 2013
    Posts:
    288
    @juicebox_boy - Good that you have taken time to practice and get comfortable with code *thumbs up*

    To split a project into tasks and order them based on their dependencies is always a hassle... it gets easier with time... why not look at it as many small / medium projects that build on top of each other? Get one thing working, test and have fun with it until you get satisfied... then make a backup of the project and start working on adding another puzzle piece. You can always fall back to your backup if you make big mistakes.

    Have you done 3D characters in Unity before? If not, maybe start with picking up a free character model from the asset store. get it hooked up with some free animations and get familiar with that... I would personally just throw in a big surface with collision in the scene to have something to move the character on. You will at least know that the character and animations are working if something goes wrong which mean that it is your code or mecanim etc... that isn't.
    Then tweak controls and related values until you are satisfied...

    A next step could maybe be to just switch the free model for one of your own and see to that you get this working... You now got a reliable character setup so that should be working... so if things go wrong... then it is probably your character that is messed up.

    Then maybe continue after that with switching out the animations with your own (if you have too) and make sure that they work. You could also make some missing animations if you can keep the existing ones and just try to add them...

    Maybe adding a basic test level after that... followed by some basic game logic... basic enemies or obstacles...

    Take it one piece at the time... if you aren't familar with something... use google and YouTube to check some tutorials for how they did it first and then make your own attempt.
     
    DanSuperGP likes this.
  8. TheSniperFan

    TheSniperFan

    Joined:
    Jul 18, 2013
    Posts:
    712
    I can only give you some very, very general tips.

    1. Have a plan
    Don't just open up Unity and create your game. Don't 'create by coincidence'. Plan your game, then plan some more. Furthermore, plans do not exist in your mind. They're available as document or they don't exist.
    The ultimate goal would be that you write a document that explains all features so good, that someone else could implement them.
    Of course you don't need to put that much effort into your documents, if you're working alone. However, the message is still the same: Write S*** down.

    2. Split the workload in a good way
    If you're tackling the development of your game as one huge task, it's easy to loose the drive that you need in order to complete it. The thing is that the only thing you'll see, is what you haven't done yet. You're just asking yourself to get burned out in the long run.
    If you're able to divide your games in individual parts, you also have some confirmation that your programming style isn't completely S***. Orthogonality or modularity is an important factor by which you measure the quality of software systems.

    3. Don't overestimate yourself
    Starting each project with: "I'm gonna make an MMO! This time it'll work for sure!"
    Be realistic about what you can expect yourself to accomplish.

    4. Don't underestimate yourself
    Starting each project with: "The cool stuff is too hard for me, I'll just stick to small mobile games despite not being really interested in them at all."
    Eventually you'll need to take the risk, for as we all know "Life begins at the end of your comfort zone."

    5. Ask yourself whether you really want it
    5. Understand that there's no silver bullet
    I tell you that game development is hard, no matter what some want you to believe; No matter how much our tools have advanced. There is no secret tip to being a game developer. The only tip is that it needs hard work, determination, patience and a good amount of endurance. But that's hardly a secret.

    To me, game development doesn't mean creating 'a game'. I refuse to call all those people who flood Steam and the app stores with cheap-ass Unity games 'developers'.
    If you feel like gamedev is too hard for you, either man up or stop wasting your time. If you don't want to put in the work, you're wrong here.

    The kind of questions I often see people post (especially on the scripting forum)...Jesus Christ. I still find myself answering those threads, as I do right now - I mean, what were you expecting? Someone to tell you a secret that magically made everything go your way? - and I don't necessarily do it for the ones asking the question. The amount of people reading threads is far, far, faaaaar larger than the amount of people who participate.
    If someone asks a very basic programming question and I answer, I do so for two reasons:
    1. The person gets an answer
    2. People who are actually willing to learn, may find it while doing the research the OP clearly couldn't be asked to do


    So yeah. No secrets, just hard work.

    (Wow, that turned into quite the wall of text.)
     
  9. juicebox_boy

    juicebox_boy

    Joined:
    Jul 21, 2014
    Posts:
    11
    (UPDATE 1/30/15)

    Thanks again guys, I'm saving this page for later use.

    At the end of the day I have my 30+ pages of project, but going to try and "one at a time" build things that can not only be used for the game but future games as well to save time.

    BUT before even that I feel I'm going to practice on a one level medium game, 5 level medium game, and so on until I feel the coding skills, as well as others are there. As well as figuring out the best way to handle a menu screen, or a certain enemy animation, or certain character actions, or anything.

    I will try to take this as a 1000 piece puzzle and instead of slamming all the pieces together at once, try to look at them one at a time.

    Sure I'll probably throw out 90% of the idea if not all of it by the time I re-read it

    It really is a breath of fresh air for me to hear this, I want you guys to know it means alot and that I want.

    I know this forum gets alot of this and even more people searching for the "golden answer" but eventually, EVENTUALLY, I'll get to the point where this game will be made, even if I have to pass a thousand tiny goals before I can even start on it.

    I'll update eventually on what I came up with,
    Patrick Bowers
     
    TonyLi likes this.
  10. ostrich160

    ostrich160

    Joined:
    Feb 28, 2012
    Posts:
    679
    This is how I got started. In my opinion, the old 'Start with pong' is counter productive, it takes away alot of the energy you have to start off, Instead, I say just try making your big idea. Try, and then fail. Because with all the tutorials you'd have to watch and skills you'll have to learn, you need to have the energy,
     
  11. MagicZelda

    MagicZelda

    Joined:
    May 1, 2013
    Posts:
    90
    Plan Plan then Plan some more. Try reading a Software systems Design book or 2, this will help with larger more complexs projects
     
  12. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    First - you don't sound like a fool, you sound like someone who wants to learn. That's different from, "I W4NT 2 MAEK SORD ARTZ ONLINE B4 POKEMON COMES ON!"

    So, you've created some smaller games, and proven you can make something. You know by now how to write code, make art, and make or find sounds. You know how to get something out for people to play.

    I was in the same boat as you when I created The Hero's Journey. It was a "cut-down" adventure game based on Zelda 2 for the NES, that took me 10 months. I had created a basic starfighter sim (SHMUP: Orbital Combat) and a cut-down RTS (Zombies vs. Knights). ZvK had given me insight into a then-nice UI system that I was able to abuse with wild abandon. First point: what useful bits of code have your previous projects given you?

    I had a concept of what I wanted to make. I watched LPs of it (H.C. Bailly and Dario8676 were great resources.) Someone linked me a dissection of the game, specifically everything wrong with it. In short, I looked at what I wanted to make, and did my darnedest to understand what made it work and what made it break.

    Next, the construction. I started with a prototype level that had the basics of everything in the game - almost a vertical thin-slice of the game, if you will. That's where you should start construction. Create a test scene for as many features as you can. Don't worry about content. Don't worry about graphics; you can polish later. Create a test scene and first prove to yourself that you can make the core components of the game. Second point: Playground scene to build the basics of your game.

    From there, expand outward, and create a little content. For my current project, my public thin-slice consisted of a town with a single "side-quest", a world map, and a dungeon with random battles, because pretty much that's what an Eastern RPG is made up of. Since then, I've expanded outward a little bit (I lost time revising my UI to Unity UI over the past two weeks, and stomping bugs). I shared it on the Game Design Weekly WIP thread to get some useful feedback I'm acting on. Third point: make a little content for a publicly available thin-slice. Show it off and get critique on it.

    A larger project like an action game or JRPG is going to require an iterative approach. Don't think of it as, "I'm going to tackle the whole game before pokemon comes on this evening!" Think of it as, "In the next two weeks, I am going to _______". Every so often, show your work and invite critiques.

    TL;DR - You've learned to make something by making small dumb games. To make a larger project, you will now need to add discipline and planning to the list of skills you've picked up. It's not as bad as it seems, though, because you can already make something. It won't be easy - it will suck, trust me - but it's doable. People - like me, among many, many others - do it daily.
     
    Last edited: Mar 6, 2015
  13. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
    Where are your games posted? I suspect you already know the "hard hatting honest advice." Perhaps, your brain is having an argument.
    • The impatient brain wants to skip over the next 10 steps - it posted this thread looking to confirm that's okay.
    • The wise part of your mind suspects you're not ready - it posted this thread looking for guidance.
    Everyone's path is different, so there is no 'right' answer. I propose the next logical step is for you to FINISH a small game and publish it on a real platform (Android, iOS, web, steam, kongregate). As an example, consider Block 64 (see sig) - that's 16 days of work, in my spare time.

    Gigi
     
    angrypenguin likes this.
  14. CDMcGwire

    CDMcGwire

    Joined:
    Aug 30, 2014
    Posts:
    133
    I'm new to the game development scene, but designing levels for LittleBigPlanet back in my days as a young lad taught me a few lessons that I still need to remind myself of:
    • As TheSniperFan noted, you need to do work. 2 hours every other month isn't doing work. This is where I fail the most.

    • Your most beloved finished project, might not have been one you ever intended to make. My most successful, and largest, level in LBP2
      [Played here by a helpful, screen capture equipped forum goer:

      Kind of just... Took shape. I essentially put the clay on the table, messed with it until it started to look like something, then took that first shape I saw and solidified it into that. It was a mess. I moved on to make other things. Then, when the tools got better and my skills were more refined, I revisited the level. I broke it apart and reworked it until it was something new and improved (though, still not great) but still within the restraints of that previous image, giving me a limit to work within.

    • Tools are hard to use. The first few weeks with something, the first few projects, will be painful as you try and wrap your head around the correct way to use the tools you have. You will be driving screws with hammers and cutting boards with a pocket knife. It's frustrating, but you need to pull through that phase. Once you can use the correct tools subconsciously, all that work will go much more smoothly and will be more satisfying.
    It's still work though. So join me, as I also attempt to break out of my own lack of drive, into the realm of infinite impossibility. I did it once, and I wish to go back.
     
  15. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,066
    Here's a bit of a different take. Try aiming to write a 'starter kit' for the game you are making, with the aim of organising, labelling and clarifying things in such a way that new users of Unity would be able to take the project and make something of it. Make one core scene, comment all of your coding, public tweaking variables, everything as flexible as possible, and most importantly of all, use programmer art until you have a functioning product.

    You can model for fun in the meantime, just get lots of practice making lots of random stuff you feel like making. And when you game is functioning, if you are good enough/are still interested, you can work on the art yourself, or hire artists to get it done for you. If you lose interest, you're likely a much better game developer than when you started, and you have something you can probably make some money from on the asset store.

    The worst thing I ever did was open Blender when I had a great game idea. Avoid this at all costs. I started coding a space combat starter kit a few weeks ago and now that so much functionality is present, I might end up just throwing in my own assets to make a game of it :) and the best thing is that it isn't a mess like all my other projects.
     
    Gigiwoo and AndrewGrayGames like this.
  16. Deleted User

    Deleted User

    Guest

    I think you can't truly understand why you shouldn't make a AAA game until you try and make one, is AAA artwork that difficult? No not really, is general coding and shaders that difficult? Mmm nah not really.

    The biggest two challenges are time and balance, because have you got a month to spend tweaking rock placement? Have you got months to meticulously go through cut scenes and make sure every animation matches exactly, all lighting and post effects match at the correct angles at the correct seconds? Can you make something look pretty, yet still make it performant?

    You may have a scene with 100's of meshes in it, that takes 10 seconds to walk through. So point being, we all have access to the same texture libraries / tech and engines as the mammoth games makers do. But as time is a constraint we'll have to balance quantity, not quality.

    But you don't know until you try.
     
    Gigiwoo and AndrewGrayGames like this.
  17. Fera_KM

    Fera_KM

    Joined:
    Nov 7, 2013
    Posts:
    307
    I very much agree with the above poster, @ShadowK .

    Realistically speaking,
    There is a few questions you should ask yourself after having a grand idea,
    the most important one is,
    How many years you are willing to put into it.

    The technical difficulties, being if you are able to actually do it,
    is not that important, because as most things, you can pick it up as you go along.

    What is important however,
    is the what personal bar you set for the quality.
    And this is really hard to do, because once you get better at things, your own standard are also increasing exponentially.
    And what once took an evening of work, now takes weeks or months to reach your own lowest standard.

    So, in my opinion,
    you have three options to pick from.
    1. Set a timeframe for completion, be strict about it, and throw your personal standards out of the window.
    2. Keep your standard, and accept depression and tedious task as your everyday life for a few years.
    3. Strip down the project to the a minimum requirement to have a working program and put everything else on a wishlist. (And by minimum, I mean absolutely minimum, which means no story to speak of, one level, one enemy, one npc etc etc).
    At least if you are able to complete that, you have a proof of concept, and are able to make educated guesses on how much time you should expect to spend on the "wishlist".
     
  18. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    Totally agree! One of my (many) problems is I will get caught up in the specific story of a game I am working on and then a quarter of the way through I'll decide, you know what I don't want this to be scifi I want it to be fantasy, etc. and spend a lot of time rethinking assets as opposed to working on the game framework which really doesn't care whether you use a space marine or elf.
     
    Gigiwoo and Billy4184 like this.
  19. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,066
    I totally agree and think this is the best reason to design the development process such that at any stage, if it simply becomes too difficult, you can simply dial back the 'wow' quality of your work easily. For this reason I think that the order of progress should be:

    1. Game mechanics (one test scene) with programmer art;
    2. Design story/scenes/levels still with programmer art (your story will have to be good to survive this! :))
    3. Asset creation and iteration.

    The great thing is that after step 2, most of your grunt work might be finished if you are hiring for the art, and you can fully test assets inside the game as soon as they are available to see if they mesh well. And regarding what @tiggus mentioned, you can probably make pretty drastic changes to your background/story after step 2 without losing a whole lot of work.
     
    AndrewGrayGames likes this.
  20. TheValar

    TheValar

    Joined:
    Nov 12, 2012
    Posts:
    760
    Coding your mechanics before creating assets is probably the more logical way to do things but I have always done them together. In fact I usually have a few art assets created before I write a single line of code. For me this process helps to keep me excited and motivated. I like to be able to see my game coming together and for me that means having it look nice. That is just my personal preference and definitely not the conventional wisdom.
     
  21. Deleted User

    Deleted User

    Guest

    Well I don't even think you have to cut back on the wow factor, I've seen some games made by 2 people that look and play better than entire teams of AAA artists and engineers. It's just they weren't going to create a 30 hour gameplay epic with 50+ shiny features that didn't really add much to the game in question anyway.

    I see a lot of people on here saying I want to make an MMO or an RPG like Skyrim, from personal experience forget it. It's not even worth trying in a larger team never mind by yourself, because the AAA guys will always do it better in every way possible.

    You just have to be smart about it and to get that experience, you have to try it and fail miserably.

    If I could afford to employ generic engineer 1032, who nobody knows what he actually does but makes people laugh anyway so we keep him around and employ a "landscape artist" who's a glorified rock modeller then it's time to make silly big games :)..

    Check this out, 2 people YES 2 people and it's awesome IMO:

    http://www.polycount.com/forum/showthread.php?t=137627
     
    BrandyStarbrite and Gigiwoo like this.
  22. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,821
    Crap, he must've found my union card. :(
     
    Gigiwoo and Deleted User like this.
  23. Deleted User

    Deleted User

    Guest

    LOL, well there's always someone. I remember at this one place, they had an engine PR manager although it was an internal engine so I'm not sure why he was there. Nice guy though :D..

    I know what your biggest mistake is, you have a quote from Hippocoder in your signature.
     
  24. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,066
    I'm not saying you have to, and of course it is preferable not to have to, but I'm saying that life is easier when the option is there. If you really want a great looking game, you can spend the next 2 years getting assets together, but if you make your simple prototype first, you game will be there in its most primitive form and you feedback and fan base will be starting to build up before you have started the most time-consuming part of the project.

    Momentum is hard to build up but also hard to stop, and starting with asset creation I think is like starting a car in fifth gear, even a pebble will be able to stop you. Making a few pieces of art might be motivating but I always seem to get into the trap of wanting to see more and more art without the game actually being made.
     
  25. Billy4184

    Billy4184

    Joined:
    Jul 7, 2014
    Posts:
    6,066
    This video is just fantastic...
     
    Gigiwoo likes this.
  26. Gigiwoo

    Gigiwoo

    Joined:
    Mar 16, 2011
    Posts:
    2,981
    Perfect! +1. Adding this link to the Feedback Friday discussions.
    Gigi
     
    Last edited: Mar 18, 2015
    Billy4184 likes this.
  27. Kellyrayj

    Kellyrayj

    Joined:
    Aug 29, 2011
    Posts:
    938
    I'd like to add some thoughts to Ostrichs post here. This is how I learnt. had a really good week of "progress" then I hit a wall that I couldn't get over, my ideas didn't seem that good and too time consuming to implement. I gave up, but I learned everything I needed to start the next project which was also a super failure. But that time I only spent a half a week on it and learned a whole bunch more.

    I guess what I'm saying is make what you are excited to make and then learn how to fail fast. You can't unlearn anything and abandoned projects aren't wasted time as long as you gained an inch closer to realizing your next goal. Keep at it, it's daunting for sure but really very fun.
     
  28. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    Excellent advice. I think people can get so caught up in the complete something and release something thing they forget there is a ton of value just in the doing period. Tackling your big project outright or at least parts of it is very beneficial. You will learn a lot. You will need to think on a bigger scale and deal with systems and patterns that would not be a focus while on something like pong. I do think there is value in building small even tiny games. Especially for a complete beginner. And also for an experienced dev the tiny games are a means to try out ideas quickly and to build and test systems that will be needed for the bigger scale games.

    Normally people tell the "I want to make an RPG game" folks to "go make pong" meaning well but I think perhaps not considering the person has no drive to make pong. I generally tell them to take a piece of their RPG and build it. Make a very tiny town for example. One building. One or two NPCs. Focus on player control, movement, collisions etc. Then do the NPC control. And so forth. Basically it is like building a model of their game.

    My own approach is to choose a game to focus on just to allow me to build more and more tech that I need to finally build what I want. As well as learning Unity, its strange quirks and its features in general. I am on my 5th game project now. The one shown in my Avatar. This game is representative of my current knowledge of Unity and several systems I have created over these 5 game projects: Raycast and Overlapping Area based collision detection system, invisible Zone definition and collision detection, Persistence system with ongoing updates (if the player leaves an area and returns later the local environment will reflect this), Interactive Behavior system allowing me to more easily build interaction between specific objects and object types, status bar manager and so forth. Basically it is way more involved than one would expect from first seeing the game. At least at this point. But I am moving toward my target. When the time comes for me to switch to 3D all of these systems will either drop in as is or else be easily updated to work in 3D. Anyway so this is an example of how to build smaller games yet maximize the value you're getting from such projects. Always build something in them that allows the current game to be a simple testbed for a system you need for a more complex larger game.
     
  29. Tomnnn

    Tomnnn

    Joined:
    May 23, 2013
    Posts:
    4,148
    That's also the most fun part of the project. The idea you focused on most is mostly complete and transplantable, and the project is not yet big enough to give you mega-headaches when a small change breaks everything :D
     
    GarBenjamin likes this.
  30. GarBenjamin

    GarBenjamin

    Joined:
    Dec 26, 2013
    Posts:
    7,441
    A small change should never (bad word so let's say very rarely) break everything. Ideally you should be able to mess around completely gutting a system and the only behavior that changes is for that area. Of course if the system is critical such as collision detection, interaction (rendering ... hmm I see a black screen now lol) etc it can surely look like a small change broke everything. ;)