Project Organisation
BlitzMax Forums/BlitzMax Beginners Area/Project Organisation
| ||
| Hello Everyone! I used to program in blitz plus for a little bit a year ago,and its been about 3 weeks that i have picked up blitzmax. I wanted to know how everyone here organizes their projects in bmx? With the import statement,I find it confusing while making resources. How does everyone use that? The problem im having is like this - -> - this symbol means that the file on the left imports the file on the right Moving_State -> State Walking_State -> State Moving_State -> Walking_State This would generate errors. I guess that is because state is being imported twice in moving state. But isnt there any way around this? I could program by cramming the whole thing into one bmx file,but I think it would get ridiculous after a while. Another thing, Could anyone recommend me some learning resource for a typical game architecture? |
| ||
| What's the exact error you're getting? And could you post a code sample? What you're describing should work fine. In the case of 'Moving_State', you actually wouldn't need to import 'State' because 'Walking_State' imports it. However, the duplicate should be ignored. |
| ||
| Posting the actual error will usually help to get the problem resolved more quickly :-) |
| ||
| My game organization was like this: Moving_State -> State Walking_State -> State Moving_State -> Walking_State Walking_State -> Moving_State Tank -> State,Moving_State,Walking_State State,Moving_State,Walking -> Tank Now,Tank has a constant called tank_speed When I try to run this,it either gives const already declared and cannot run something.bmx.gui.debug.something . I can maybe guess the cause of the first error but the second one? |
| ||
Julias. You are somewhat vague in your description ? Here is some code I wrote about movement of a tank - if you think it will help you or it can better explain your situation. |
| ||
| I'm really not sure how some code about moving a tank is going to help with his import problem? |
| ||
If this is really the layout of your imports, you have a bunch of circular dependencies :Moving_State -> State Walking_State -> State Moving_State -> Walking_State Walking_State -> Moving_State Tank -> State,Moving_State,Walking_State State,Moving_State,Walking -> Tank Why do State, Moving_state and Walking_state need to import tank? Surely the whole idea here is that tank will implement the features of state? If you draw the connections on a sheet of paper, you shouldn't see any loops/circles of dependencies. BlitzMax doesn't support this. The graph should look like a tree, with the trunk (your main game file) at one end, and all the branches at the other. |
| ||
| And if you can't work out a way to remove your circular dependencies you will need to combine some of your files into single source files. At a push you can also use Include "file.bmx", which allows you to keep the files physically separate but combines them into a single monolithic file at compilation time. However, if you make changes to any of the included files, the whole lot will need to be recompiled. With imports, only the recently changed file is usually recompiled - which can result in faster build times depending on the size of your project. |
| ||
| Thanks everyone:) I was trying to isolate each and every class into a separate bmx file. The mistake I made is adding the constant in the tank which,as you said,led to circular imports. I was trying to implement the state design pattern from http://gameprogrammingpatterns.com into a tank game to get a feel of how I should implement it. :P |
| ||
| To avoid circular imports Main imports Tank.bmx Main imports OtherEnemy.bmx Tank.bmx imports TankBase.bmx (base object with rudimentary functions not using other custom types, TTank extends from TTankBase) TankBase.bmx imports "UnitsBase.bmx" (TTankBase extends from TUnitsBase) OtherEnemy imports UnitsBase.bmx (TOtherEnemy extends from TUnitsBase) OtherEnemy imports TankBase.bmx (instead of Tank.bmx - if they need to access that type) Benefit:while type "TTankBase" might return an "GetAmor()" of 0, the real "TTank" returns "Field armor:int" when calling an overriden "GetArmor()". This example assumes, that "GetArmor()" is only available for TTankBase and ancestors, TUnitBase does not have armor or so (else we would not need to know about TTankBase in the OtherEnemy.bmx file) "OtherEnemy" wont need to know about the real implementation of "GetArmor()", you just give it the corresponding tank (of type TTankBase or an ancestor). Blitzmax will then call the appropriate "GetArmor()" part. So if you gave an "TTank" object, the armor will be "armor", while a "TTankBase" would return 0. This allows you to have other "Tanks" extend from "TTankBase". Ok ... and this could be done vor various things... not only tanks. You could have "TBehaviour" which takes care of moving, planning ... and then you extend into various behaviour schemes. I wrote about behaviour now, as I darkly remember that this was subject of some threads a while ago ... "components design". Also "state pattern" is a behavioral design pattern ... bye Ron |
| ||
| It is these two lines that lead me to believe he is writing a game about tanks, Brucey. State,Moving_State,Walking -> Tank Sometimes you have to read a message all the way through. :) Now,Tank has a constant called tank_speed |
   |