Code Organization (DragCore)

     My code is much more organized this time around. I find that it helps to separate scripts into things as specific as possible. I made one for each game scene (there are five total) and one for each object that moves and animates itself. My old way was to have a giant GameControl script full of commands for different menus and modes. It was controlled my a mode variable stating which scene was active. It was a mess searching through that thing and I kept finding myself putting things in menus where they didn't belong.

     Now I'm using separate scripts, one attached to each game controller object in every scene. This way, the only functions a scene can access are ones that are relative. All without messing up things in other menus and realigning a bunch of curly braces every time I slip up. I also take care to keep my Update() method clean. I used to put hundreds of lines of alignment and setup code in there, making my games sluggish. Now I only setup once by calling a refresh method in the Unity Start() method and make changes when a button is pressed.

     Messy code leads to bugs that I hate with a passion and these practices keep me away from them, just a little more. It seems obvious to me now, but when I started out I never cared what the code looked like as long as the game worked. Now I'm practicing efficiency and dynamic systems which is what code really needs to be in the long run.

Status Report #19

     Vacation week. Almost nothing got done for DragCore, but I re-energized myself, saw interesting things, and came up with an awesome new game idea to work on next. Here is this week's status report.

Don't Sprite Too Hard

     I'm getting better with managing file sizes. I used gigantic sprite sheets for Fish Feaster, taking up many times more memory than I needed to. It's important to keep in mind how you can use scripts to manipulate sprites in order to have variant sizes, change directions, or even alter colors and transparency. The few lines of code you'll need to do that will be much easier on the memory load than countless sprite files way larger than than need to be.

      In the end, your game will run more smoothly, take up less space on users' devices, and make you feel like a game developer who works smarter, not harder. Making so many sprites by hand was my biggest mistake with my first game, and I never made it again. Now I try to find more ways to mess with sprites through code and my future games will be better because of it.

Bite-Sized RPG Gameplay

     Playing the new Zelda on 3DS had me thinking about ways to make a giant RPG adventure feel convenient through bite-sized play. I want to allow players to enjoy short playing sessions, but still be able to experience a giant quest when they have more time. I decided a good way to go about this is by having dungeons in the game separated by room. Each room is it's own big puzzle, and getting to the next room is equivalent to beating a level in a regular mobile game. Something fast and rewarding that saves on completion so you can put the phone away at a moment's notice.

     Pop-in, solve the next room, pop-out just as commercials end. Get on a train, explore the overworld for a bit, level up, get some money, close the game as you arrive at you stop. All without worrying about being too far from save points or losing your place in the middle of a big complex dungeon.