Problem with objects and imports
Monkey Forums/Monkey Programming/Problem with objects and imports
| ||
| Hello all. I am trying to understand how to split my code in different files to make everything better organised. I am encountering a problem that i think is still down to how i use objects. I will try to describe the situation without any code. I have 2 objects, player and enemy. The objects are put into a list that is shared between the 2. The problem is here, since i am trying to split my code in "main" and "objects" i don't know where to initialise the list. If i have everything in the same file everything works properly, because i initialise the list in the main app. How can i share a list that need to be created before creating objects? If i put the list as a field of the player class (using the global keyword) it will work for player because when i create player the list will create itself as well, but that won't work for enemy. I can't put the list creation in a function because it won't work, enemy and player will have null fields because the list isn't created inside the class... How can i solve this problem? Basically is it possible to create a general list (a container) for both enemy and player? I am trying to make layers for my objects, like a layer for the "actors", a layer for the interface etc... I was thinking of creating a parent class (actor) that include the list as a field, but then i don't know how to initialise the parent class so the children classes can inherit the list field. I hope it make sense... |
| ||
| I think you're trying to make things too complicated and/or sophisticated. While it is possible to put instances of Enemy and Player classes into the same list if they both derive from the same class, it's not necessarily all that helpful as a general rule (depends how much stuff they have in common, but if you weren't allowed do it, it would never block you from writing any game). Your list or lists of players and enemies shouldn't belong to the player or enemy classes, but to the controlling class. Something like the following would work: The Enemy class imports player and has a method like: Method ChaseNearestPlayer( playersList:List< Player > ) So enemies don't each contain a list of the players. They either get passed it like the above example, or they have sopme way of finding it either as a global variable or because they can find it via the Level object. Hierarchical organisation is your friend: only a few major controlling classes should hold the permanent information about the game. That way everything gets initialised before it gets used (because e.g. the Level class doesn't start updating until everything is initialised) and everything has one place to find the information it needs. |
| ||
| thanks. i just want to inform you that i read your reply as soon as you posted it, and i am working towards correcting my code. i think i might have found a solution... |
| ||
| Gerry do you import only the files required per file then ? What I do is have my main build file import all project files, and then all project files just import the main build file, because of the cyclical imports monkey handles it all from there. I wonder tho if importing only the required code is more efficient or if the exported code is all bundled anyway. is there a real bonus or difference ? |
| ||
| I import only the files required, and generally I import every file a file/class needs even if some of them would be implicitly imported [ i.e. if b publicly imports a and c imports b, then c doesn't need to explicitly import a, but I would import it anyway if a class or function in c uses a]. I doubt whether it makes a lot of difference - maybe somebody who has a real monster of a project can tell us! There's nothing wrong with the way you do it either - I just like to be able to see every file's dependencies at a glance. It might be a useful exercise for mteo, though. Keeping the import list fairly short is a good thing, and helps you organise projects. If a file has a ton of imports, it should be because it's a central organising class, e.g. a Level class that owns all the players and enemies etc. Obviously you don't have to take it to extremes, e.g. I usually just import mojo into a window-type class, rather than fuss about individual mojo modules. A typical main game window class for a snake game might start with: Import mojo Import gerry.helpers Import snakeglobals Import angelfont Import snakegame Import buttonbar [Now I think of it, it's sneakily importing a Snake class via snakegame which it's not supposed to, but it only uses it in the DrawSnake method, so I will let it pass.] I am lately leaning towards moving a few more things into globals than I used to, particularly resources which I used to bind to the main window using them. |
| ||
| I was wondering the same. Because at the moment for me it's pretty difficult to import only the required code, because i have so many cross creation going on that i am loosing track of what i am doing and where.... |
| ||
| mteo, download the zip file from this link. The example is from fantomEngine, but it is specifically targeted at a good way to handle file organization and imports. http://www.fantomgl.com/?p=521 |
| ||
| The compiler doesn't care - at worst, it takes a little longer if your structure is not ideal. Code in a way that works for you, and helps you not make mistakes. |
| ||
| I think i found a solution to my "problems"(they aren't really a problem, it's only that sometimes i look at other people's code and think that it looks more elegant than mine,even if mine works!so i keep tinkering instead of getting on...),trying to implement it right now and so far it seems working. Thanks for the fantomEngine example. |
| ||
| Personally I always use private imports. That way they don't "bleed" into other modules, and it requires you to import exactly what you need. |
| ||
| The solution i found works brilliantly. It's not actually a solution to a problem but mainly how i was accessing my fields. Basically i declare my layers into the main program, and i pass the layer as a field when i create them. |
   |