Hoo boy, I wrote a lot. Buckle up!
The process started a little over a week before the project was due and I thought the content was due on a Friday instead of a Monday. I wrote up a quick game design idea, and it turned out to be a half decent idea. I mean, I couldn't think of a title, but all it took was a quick re-theming and it fit, so... meh.
The hardest part, honestly, was cleaning up the design document. Even now, it's still a jumbled mess. I'd like to break it into fewer, more manageable chunks. First, though, I'm going to get this project done and submitted. And maybe watch a lot of anime.
I spent about fifteen minutes writing the content for the rest of the pages, and moving the proposal from markdown into HTML (as you can guess by the relatively little effort I put into the homepage). I plan to refine it all once I've actually written the game, since it's a lot easier to describe something that I've already done and that already exists than it is to describe something I plan to do without introducing too much for me to take on.
What I spent most of my time on was the CSS -- mostly fiddling with magic numbers to get things looking as good as possible. Plus, I had a lot of trouble trying to get the header bar looking just right.
Similarly, right now the header bar and sides of the page are fairly empty. I want to use assets from the game, but since I won't have time to make any for a little while, I'll just need to wait until I'm not quite as busy. I plan to make the background of the header a road texture, and the background of the main body a generic city, made up of assets from the game.
The first thing I did on this project was to redo some of the CSS and HTML on the site, and start designing (mostly on paper) the API I'm going to be wrapping around PixiJS to make a very simple game engine. I did them basically at the same time, because the CSS and HTML changes were mostly boring and fiddly, and the API design was a fun challenge.
The basic movement system, which allows handbraking, was relatively simple to implement; it just required a little bit of trig.
The first big issue I had was getting the camera working -- in my head, and when trying to figure out the math on paper, I'd forgotten to invert something, so it took far longer than it should have. The second was collision detection, but that was just working a couple of kinks out of my implementation of a well-known, well-studied, well-documented theory: the separating axis theorem. Notably, I forgot to account for rotation. Several times. And on two separate occasions, I "accounted for it" by multiplying the rotation, instead of adding it; you can imagine how fun those bugs were to work out.
The third, which is surprisingly hard, was making things bounce off of each other remotely realistically. Any remotely decent solution involves some complicated math to find point of impact, and I simply don't think I have the time to figure that out before it's due, so I'm using a hacky, annoying, stupid way to do it. Oh, well; at least it works alright.
I'm fairly proud of the way I've done levels, at least at a high level: Metadata files, which are dynamically loaded and specify how the level is to be built. In theory, this should make it possible for (a) users to make their own levels, which would be really neat, and (b) possibly even a level-editor that exports easy-to-debug JSON files.
Unfortunately, I didn't get to nearly as much as I wanted. I spent way too
much time figuring out how SAT works, and trying to find minor bugs that
ended up being caused by a single flipped subtraction -- I had
b - a,
when it should have been
a - b. Now I've fixed that, and
collisions work beautifully.
Any code directly taken or adapted from someone else's code is marked with a comment in the source itself. For separating axis theorem, I used several resources:
- Dyn4j's SAT tutorial
- Several GameDev.SE questions about Separating Axis Theorem
- Metanet Software's blogpost on SAT
However, a fair amount of the word was (re)done by me, because the resources I could find were woefully inadequate for quite a lot of things -- they tended to gloss over minor details, like the sign a result should be given, that really impact the end result.
I do plan to keep working on this over winter break. There are a whole lot of features that would be super fun to add, and make this game really fun to play, that I didn't have time to get to. In no particular order:
- A better level system. The tile-based system I have in place now certainly works, and it works well, but with my code it would involve changing about three small things to make it easier and more efficient to load the level, get more detail in the textures, and get shapes which physically can't be represented on a grid.
- Cops! It would be incredibly fun to add cops that started following you if you were a careless driver -- hitting pedestrians or blowing of speed limits; that kind of thing.
- Related to the first, more realistic object shapes. With separating axis theorem, I can have any arbitrary (convex) polygon; all I need to do is change how axes are calculated.
- Force-based turning/collision physics.. Right now, turning is done by modifying player.rotation directly, and the rotation is scaled by the current speed. It would make things a lot more natural to apply a force where the front wheels are to push the car around; likewise, collisions now are pretty unrealistic because I'm directly manipulating the velocity, rather than simulating... well, collisions.
- Sprites. Right now, the game just looks kinda...
bad. That wasn't intentional (obviously); I just didn't have time to
find, let alone, make proper sprites.
Reddit needed browsing, man!It turns out collisions are really complicated. These will be easy enough to add in once I've finished the transition from rectangles to arbitrary convex polygons.
- A better GUI. Right now it's just the time taken in a kinda boring font; I'd like to add a spedometer, various stats, on-screen indicators pointing to the end point and possibly locations of cops, etc.
- More stuff in maps. Right now it's... just the terrain, and the only real "feature" is different friction on sidewalks vs. the road. Especially once I implement the new level system, it'll be easy to make things like speed traps (where if you go to fast, you get the cops on your tail).
- Main menu and a better score screen. It would be nice to have a little play area for people to get used to the car handling a little, and main menus are generally a good idea to have. The end screen is also a little confusing; it's not immediately apparent that the "Back to Level 1" pseudo-button has to be driven over, rather than clicked. That was an intentional choice, but it's kinda hard to tell from the menu itself.
The depressing bit is that, if I hadn't been forced to spend ~24 hours
Googling for 3D models for a class that was not about Googling 3D
models, I could probably have done at least some of this.
that's my excuse. I refuse to blame Reddit. Oh, well; at least
I have a cool tech demo, and a great base to start from to work on a