>>1084 Zero is mostly awesome software, but one thing that I've noticed is that it teaches people a "designery" mindset of game creation instead of a "programmery" one. What I mean is, when you open Zero, first and foremost you have the level view. From here, you can create and drag objects around. This teaches students that the basic action you as the game maker will be doing is positioning things in the world, and making them behave, instead of writing code that makes things do stuff.
Hypothetical, not-at-all-a-thing-that-actually-happened example: I am working on a 2D side-scrolling game that has a parallax background. The other designer on our team places a "background" object with a Sprite component (our engine is set up very similar to Zero), and a "follow camera" component he made and a "parallax" component he made into the level. The former makes the object follow the camera, and the latter makes it move based on the player's velocity (for some reason, and not the camera's position… don't worry about it). He repeats this for every layer of the parallax background, twice, because when the one background moves to the left, you need to seamlessly show the other one on the right, meaning that because we have five layers of background, now there's ten objects. (I am fully aware that this can be done using UV coordinates to just make the textures "wrap", but our engine isn't built to support that, and I'm not in charge of how the graphics systems work.) This meant that every level JSON file was littered with ten or so entity definitions, and that if we wanted to change the way the parallax stuff worked, we would have to go and edit the same thing in multiple different levels.
Then I made a change to the way the camera works that completely broke all of this, so I had to fix it. I rewrote the system from scratch, instead making a sort of "parallax manager" component that one entity in the level has. When the level begins, it spawns the background entities, and keeps references to them and manages how they move, all from this one manager entity. Better yet, I modified the level loading code such that our JSON files have a list of all parallax layers, and how far "back" they are. This way, when we have different parallax backgrounds in different levels, all you have to do is modify the items in that list in the level file, and boom, different background. No copy-pasting large JSON objects. No worrying about keeping track of all the JSON objects (because the serializer serializes objects in whatever order it sees fit). Simple and easy.
In my opinion, my solution is the better, more "programmery" solution. It is simple, changes to it can be easily made since it's all in one place, and it easily facilitates making different parallax backgrounds on different levels.
But the way students are learning game making these days isn't about programming first; it centers around this idea of placing objects in a space, and attaching bits of code to them to make them do what they want. This is obviously useful for many things, but I think having the programmery mindset gives you a huge leg-up over your competition, and learning Zero right out of the gate (with the first lesson being, "place these physics objects in a level to make a Rube Goldberg machine") isn't necessarily helpful for that.
Post last edited at 03/21/15 (Sat) 01:00:56