Sunday, March 5, 2017

One Month of Learning JavaScript gamedev

About a month ago a friend of mine guilt tripped me into trying to learn JavaScript and gamedeving in it instead of whining about Unity whole day. I reluctantly accepted, and began learning how to use Pixi.js

Day 1 of many

Behold, a spaceship which is totally not an Elite:Dangerous wireframe Cobra, floating in the empty vastness of grey space.

I then ended up slightly distracted by Three.js and 3D models.

 Day 3

Around this point I fell into the feature creep trap. Frustrated with struggling with random unfun challenges and obstacles, many of which stemming from my unfamiliarity with JavaScript, I ended up spending more time writing down a 50 page long document about a game idea. I dub it, "Feature Creep: The Game".

Back on the subject of actual gamedev, I keep forgetting the cardinal rule for beginners: CUT CUT CUT. Keep it simple. Minimum viable product.

Days 4 and 10

As you can see here I'm getting sidetracked with lots of fluff like trying to add lots of different things before the concrete of the foundation has settled. That being said, I did learn some nifty things:

Day 10, evening edition

Like a kinematics/rigid body "simulation" that responds convincingly 75% of the time! It's amazing the amount of things you need to learn to make games if you're not going to copy and paste literally everything. Moving an object? Equations of motion, second order integration, Runge-Kutta method if you paid attention during class. Handling collisions? Elastic collision formulae. Tell the layperson you're making a game and they'll think you're goofing around and being a kid instead of trying to wrangle third year physics problems.

Day 11

So after 10 days I had this. You had ships that bounced off each other and the edge of the screen. You had linear acceleration that ramps up and down instead of your velocity suddenly going from 0 to MAX. You had a little working health bar, a very rudimentary laser that only fired when you faced the right way, and a placeholder docking/station menu system.

Unfortunately by then I was completely exhausted and fed up. My code looked like regurgitated spaghetti, I still had no idea how encapsulation worked in JavaScript, I couldn't explain closures, and every tiny new feature I added made the entire rickety foundation creak and moan to the point where it was just a pain to keep the whole thing standing.

Day 14

The nail in the coffin was trying to implement my own World-Clipping-Viewport camera system, as well as a working minimap. Eventually I managed to get something working, but by then I was so fed up that I completely lost interest for about a week.

Day 22 (including 7 day break)

After said week, I tried to tackle the UI/game world/camera problem from a more structured and methodical point of view. I made decent progress before being flummoxed trying to implement RĂ©seau crosses or grid markers for the background that would scale in position between each other, but stay the same size on the screen, and also disappear/reappear based on how far you zoomed in or out, so that you wouldn't have hundreds of tiny crosses littering the screen when you zoomed out completely.

Once again, by the time I figured that one out I was fed up. After another week's break, I decided to go back to basics. Cut cut cut. No fancy UI layouts, minimaps and grid systems. Just a spaceship shooting rocks.

Day ???

So here we have my current Asteroids clone. It's the closest I've ever got to finishing a game. It has a proper working game state/game loop, with a rudimentary menu. It initialises a level, you shoot bullets, things blow up, it even has win conditions when you're the last one alive, or if you die. All I need to do is differentiate the player sprite and enemy sprites and add a score board, and technically it'll be a complete game. Let's see if this last 10% takes 90% of the time like the first 90% of the work took.