Is it theoretically possible to write a large game with one script? How have you decided when to use multiple scripts?
For instance; I am working on the bare bones of a classic PS1-era strategy RPG. I plan on creating one script per-scene with the design mantra ‘x is a game’. So: the Overworld is a game. The individual battles are a game. The party-management is a game.
I’m afraid of this approach, but I’m going to do it anyway-- so here I am, hoping to hear your thoughts on control structures, maybe even an example of how you’ve decided to use scripts?
To use a single script is indeed possible, you need to use a lot of tags // to not be lost inside, i used multiple coz it’s more easy to track down problems for me. When you say you want create one script per scene that’s not impossible, just bear in mind that separate scripts like that will not have the same values, so i suggest you to put in root, that’s kept for every scene, a script with the variables you need to be used in every scene. I may be wrong but i will approach like that now. Good luck.
You can see how the developers have separated out the logic in their scripts so that they are solely responsible for one feature or object. Some reading on Object Orientated Design can be found here: http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign which gives some high level approaches to structuring a project.
Thanks for those examples, it’s interesting to see how things are stitched together. These will serve as a good example of the sorts of Entities that I will end up creating. I think that the single file approach is so attractive because I’m a total novice, I’ll suck it up and actually learn to communicate between scripts.
Okay, so I’ve been reading the Flappy Bird example; this is seriously as simple as defining a bunch of listeners in a traditional sort of ‘main’ file and using fire() from the children to drive the application. PlayCanvas is incredible.
You could look at this as vertical or horizontal logical structure.
Vertical means you have dependencies all the way from top to bottom. Meaning if you change anything at any level, it affects everything above.
Horizontal means usually there is very little dependency, so each of a logical part independent from each other, using some established simplistic messaging logic, to make them talk to each other.
Vertical - is much harder to maintain in long term, and makes you very dependent on legacy code. Gamedev is dynamic, meaning that you will end up with cases where you will need to change certain core aspects. And with vertical approach this will be extremely hard, as everything above it will likely break.
Horizontal - is much easier to maintain, developing you ensure you have pieces easy to change, throw, rewrite. That way you can change most of application aspects without too much overhead because of ripple effect of a change that might break a lot in vertical approach.
So separation - is good. Keeping each bit clear and simple. It is pretty much Unix philosophy - keep things small and single-purpose.
