About Yokosuka

Page updated 2008-03-25. This page is really in flux and contains somewhat disorganized data at the moment. Sorry!

What's the goal of Project Yokosuka?

Initially, the goal of this project was just to make a game engine for fun, but the goal is slowly moving towards a game engine that will allow people to put together silly little games akin to the memes that come out of ytmnd.com. Think of it as interactive YTMNDs.

Some background: I used to write text-based game engines back in high school and after I entered the working world, I didn't really continue working on games so much. I did work on Project Hazuki a few years ago, but that was only for a few months on and off and the result was, IMHO, a very satisfying 2D Street Fighter II demo. The original goal of that was to create a full-featured Shenmue style game engine, but it never materialized. I looked back at the code later on and realized it wouldn't scale so well, so I decided to rewrite it with a proper design from the very beginning. That's how Project Yokosuka started.

I want to stress that the goal was to do it right (i.e. correctly) right from the beginning. Directories are laid out in logical fashion, code is broken up into components properly, assets are separated from the code, etc. There are a few places where I strayed from the "correct design" path, but I like to think that I will go back later and fix those before I hit the v1.0 mark.

Incidentally, I initially was going to have this run on the Game Boy Advance, but I eventually realized that for the ideas I was coming up with (such as using mp3s for background music and having dozens of enemies on-screen at once), it just wasn't going to work. I cut the cord to the GBA in the summer of '07 and have since been building the app for Mac OS X and Win32 exclusively.

What's the ETA for release?

Who knows? I'm hoping to have demos up by summer of '08. The interesting thing about this project is that because it's a game engine, once I release the binary, you can start writing games for it... so long as you have all the tools necessary to compile the data into a useable format. That's really the thing that will take time: packaging all the scripts and writing documents on how to create games with the game engine. After the first release, of course there will be further updates to the system.

About the code

• A tiny amount of the codebase is from my Project Hazuki engine. I kept mainly the state frame system intact since it worked so well for that game. Honestly, maybe a few hundred lines of code at most.
• Built using gcc and SDL. Why, you ask? It's mainly because the game was written for the GBA initially and it was most convenient to work with GCC at the time. Also, I enjoy unix-style build systems.
• Game engine is written exclusively in C++ with tools written in C++, Ruby, and C#.
• All the source code was written by me. I didn't use any outside game engine libs or source code, unless you count SDL, which is strictly for rendering pixel data to the screen, reading in input from the keyboard, and playing back audio. The game logic, including scripting system, is all mine, though.
• If you take the game code and tools code and add up all the lines, you end up with about 23000 lines of code in total.

Multi-platform

• game engine uses gcc and SDL, so it's portable to anything that can run gcc and can build SDL
• builds on Mac OS X
• builds in Win32 (using mingw32 right now)
• used to build for Game Boy Advance, but sadly no longer does (it would probably be too slow to run at the moment)
• could build for Linux, but have not yet tried

Versioning System

I use CVS. Suits me fine considering I'm not working with anybody else or doing any funny stuff like branching.

Scripter

• manipulate images on screen
• display arbitrary image anywhere on screen
• move image from point A to point B over T frames
• add/remove/enable/disable triggers
• triggers all you to set events whenever a line or a box is crossed within the game (for instance, to trigger movement between stages or to trigger enemies popping up)
• text: can make entities talk via speech balloons titlecard text bottom-of-screen text
• camera control
• follow entity
• enable camera shake
• sound playback (currently only .wav works)
• palette tinting
• can fade an entire scene based on a given target palette (for instance, if it's sunset, can tint the scene orange; if it's nighttime, can tint the scene blue)
• can fade gradually
• can add/remove entities dynamically
• can load/unload stages (i.e. maps) dynamically
• can run several scripts simultaneously
• handles multiple components
• support for waiting on several event types
• clock (i.e. wait so many milliseconds)
• entities dying
• other script terminating
• flow control (GOTO label, SPAWNing of other scripts, CALLing of subroutines or other scripts, JUMPing to other scripts, ENDing current script or KILLing other scripts)
• subroutine support
• will eventually feature:
• variables. global and local: global can be saved in save states; local only apply within context of current script
• parameter passing for subroutines and calling other scripts
• conditional statements

Tools

• asset filesystem compiler
• takes several asset files and generates one larger asset file that contains offsets and "file name paths"
• asset filesystem viewer
• palette compiler
• model generator
• a model is just a combination of an action whitelist, a set of sprite images, and the states and state sequences (the actual frames to play back and associated metadata)
• scenedef compiler
• converts a text file describing a scene into a binary
• stagedef compiler
• converts a stagedef into a binary
• script compiler
• turns a text script into my own special bytecode format that the game engine reads
• stateframe maker
• two apps for converting a bitmap containing several sprites (easy to find on the web) and assigning x,y offsets a
• action whitelist compiler
• an action whitelist is just my name for a whitelist that determins what action an entity will undertake given two condtions: 1. his current state and 2. the input provided.

Coming soon

• variables and flow control in the scripting language
• saving and restoring game states
• some more demos!
• more sound commands (fade in, fade out, loop)
• more camera commands
• more director commands to manipulate the entities

Lines of Code

C++ code

The game engine itself is written in C++.

• 51 .cpp files
• 76 .h files
• Over 15000 lines of code in the .cpp and .h files combined

Ruby scripts

I use Ruby for most of the asset compiling tools, such as the script compiler, the stateframe compiler, the stage compiler, and so on.

• 19 ruby scripts
• 4000 lines of code in the ruby scripts

C# code

• Over 4000 lines of C# code

Grand total

If you combine all of the source code (.cpp, .h, .rb, and .cs), you get a total of 23000 lines of code.