Why have multiple files for one program?
Monkey Forums/Monkey Beginners/Why have multiple files for one program?
| ||
| Hey everybody, new monkey here. I followed all of Jim's tutorials, and am now working on my own project. Expect lots of annoying questions :) Could someone explain to me why we use multiple files for one game? For example, in Jim's "Falling Game" we have "main.monkey" as well as "falling.monkey". I understand that the .data file is necessary for loading images/sounds and whatnot, but what are the reasons for not putting everything else in one file, and what are some general guidelines I should follow when making my game? Thank you! |
| ||
| If you put every thing in one big file it becomes very hard to maintain, and finding bugs would become a nightmare. For one simple program a single file is adequate, but more complex programs need to be broken up into manageable modules. |
| ||
| is it simply for simplifying editing then? Nothing to do with memory management? |
| ||
| is it simply for simplifying editing then? In simple terms, yes. If you build one of the samples as a desktop application and take a look in the .build directory and explore the contents of the glfw folder. You will see the there are a number of directories and a few files. The main.cpp file is the source code generated by the MonkeyX compiler. This is what your MonkeyX code gets converted to and is a single file. Now imagine having to maintain that. Now in this directory is another called glfw. This is where the code resides for building the glfw library that is needed by the application. If you explore the contents of this directory you will see that it is broken into a number of files. This make it much easier for some to update or fix bugs. The files that you see with the .o extension are object files. These are compiled source code that are used during the linking stage to create the final executable application. The files with the h extension are know as header files. These are usually used to for defining function proto types and variable definitions. Nothing to do with memory management? It has nothing to do with memory management. Only for the management of your project. You would manage memory within your application when running. MonkeyX uses what is know as Garbage Collection. |
| ||
| Thank you very much. That cleared up many misconceptions I had |
| ||
| Also you can over time write various reusable libraries and group them together in one file then just import them at the start of your code. Just makes coding easier in larger projects at times, although I often start with it all in one file so I dont need to keep swapping then as it gets larger split it up :) |
| ||
| Software projects depend on some sort of architecture, this theory goes very deep and there lots of good books about it. But in the most simple and practical terms, the conceptual model of the software, needs to reflect that on the file system as well. For example if you look at your project's classes and see that they can actually organized that way in the file system as well, then this is the most easy and painless way to do so. It would seem very odd to try to fit everything in one file. The program will work in both cases, but in one case you retain the conceptual model of the application "the big picture" and in other case you loose it. Chances is that if you read your code after 3 years and having forget everything (or another person reads your code for the first time), you will understand it ASAP but with poorly written code you will loose lots of time trying to fixing it that in the end you will have to start over. |
| ||
| Even when you think you are just loading one file -- when you are using mojo you are loading several files.without realizing how many files are being used in your application. Potentially each one of those files could import even more files. mojo being a framework for games gets loaded when you import it for your use ( and as you can see below imports several other files for support. If you had to have all that in your one game (which it actually does pull all in when it goes to compile ) would be hard to maintain if you had it in your own game file. '################################################################## ' Module mojo.mojo ' ' Copyright 2011 Mark Sibly, all rights reserved. ' No warranty implied; use at your own risk. #If MOJO_VERSION_X Import mojox.app Import mojox.input Import mojox.audio Import mojox.graphics #Else Import mojo.app Import mojo.audio Import mojo.graphics Import mojo.input Import mojo.asyncloaders #Endif |
| ||
| Thanks for all the replies they've all been very enlightening. It was going through the forum posts on here that made me jump in to monkey a month or so ago. You guys set it apart from all the others... I wonder whether I should start a new thread for each question I have or just start an "Odaniv has a question" thread. |
| ||
| I can just speak for myself, I don't take as a guideline to create as many files as possible without the IDE supporting that, e.g. by having a "replace in files" dialog for some renaming and refactoring jobs, and even being able to undo that. At the moment I've decided to use TED, so I put things like game logic in one file, all classes for that. And code that doesn't relate in a "lexical" way or is another language anyway I put in other files. And I hate writing declarations twice (http://www.lazycplusplus.com/) but that's not a problem in Monkey. |
| ||
| The reason I would advise you to use seperate files is that they are easier to test. Everything is fine until bugs show up in your project (and they will). Once the bugs are in your project, they are a hell to fix (you can easily waste hours). You should always try to eliminate as many bugs as possible once you're finished writing a piece before you integrate it into the main project. For starters this should work pretty well:  (looks ugly I know :C ) |
| ||
| The computer doesn't care whether you have one file or a hundred. But you should care, For a very simple 'beginner' program, by all means just extend mojo.App and add a few functions. You're still using lots of files, except that most were written by other people! But when you have a bit more code under your belt, you'll realise that separate files have a lot of advantages: - for understanding and debugging, everything to do with one part of your program is in the same place, and nothing else is there - for re-using code, you can import just the files you need into your new project, and leave unrelated stuff behind. |
| ||
| If you want to quit coding early and have a headache that kicks your ass because of bugs then go with the single file setup. If you want to end the night productively with no bugs or headaches, ready to start more coding in the morning, go with the multiple file solution. There's a point also I'd like to make. Frustration is the biggest Mojo killer. If you struggle to complete a section of your game or fix a bug and it is because of poor project management you'll soon find that quitting is the only option. Why? Quitting relieves your mind of being frustrated at fixing a mess. When things are organized and flowing beautifully quitting is the last option. Why? Because the thought of Quitting when productivity is high and progress is extensive, that calm feeling and buzz you get when your coding Mojo is at its apex, is the last thing you want to do. Preparing yourself to successfully code by planning ahead making sure to avoid anything that will frustrate you is way better than diving in to a project blind at what might happen. Your mindset is key here. |
   |