Sunday, December 20, 2015

A Fighting Game in Javascript - Progress Report


I am mostly finished with the Character() class that I will work from now on. It still needs some tweaking. The fingers are completely out of proportion, for example. Anyway, I needed a posing control screen to start creating the first poses. Got that done quickly and easily with AngularJS. It's great how well it got along with Three.js.

The HUD is temporary. Done in CSS, not using WebGL. It was something I tried in the past, but now I have a better idea in the works. There are gonna be more bars, too. But more on that later.

Once I get some needed poses recorded, there are a few things that probably need explanation. For example, shoulders. They have a control input in the window to the left, but do you see any shoulder? The upper arm is not it. But it's there. I will tell you next time. :-)

Thursday, December 17, 2015

A Fighting Game in Javascript - What is different here?

I found a few results in Google from other developers trying to create fighting games in Javascript. So, what's different here?

There are similarities. For example, the usage of sprites. Don't be fooled, I am going to use "sprites" too. The difference is that in my case a sprite will be a 3D object frozen in a pose instead of an image file. Another difference is that the transition between those "sprites" will be smoothed out instead of a flat change.


This is how many real 3D games work, actually. It's mostly noticed in games that were previously in 2D, then converted to 3D, for example, Street Fighter IV and the brand new The King of Fighters XIV for PS2... I mean, PS4. Sprites from the old version are converted to poses in a 3D model, then put on a timeline (like sprites) for animation. The change between poses can be tweaked with tweens, formulas that provide things like acceleration and bouncing effects, adding to realism.

I haven't yet started working with Animation. At first, it will either be totally awesome or a complete disaster. ;-) We will see.

Thursday, December 10, 2015

A proper introduction

Hello everyone. I am @pauloddr on GitHub, and this is my personal tech blog. I am a web developer with 15+ years of experience and have been programming games in my little free time.

Currently I am working on a personal project, a complete fighting game in Javascript. A game with the gameplay quality you see in Street Fighter and other games of the genre. It's a huge undertaking, and there's a lot to talk about it, so I will try to use this blog to share my technical experiences as I develop it.

I have been gaming since circa 1995, and played a lot of fighting games when arcades were a thing. I have thought of building my game since forever (well, since I started playing), and I finally have some ideas to begin. I am totally aware that building a full game like this isn't an easy task. However, I feel like I can pull something off, using public domain assets for things that I am not able to create (like sounds). I want to see if it's a feasible project to begin with, before investing heavily into it. (And by that, I really mean money.)

Focusing on gameplay first, my ultimate goal is to build a good game that runs in most modern browsers and allows players to enjoy a gameplay experience that they are already familiar with.

Motivation

So why build a fighting game? Aren't there so many good fighters out there already? Aside from my passion towards the genre, there is another reason, something I find lacking in most games of today: customization.

Existing games offer you a roster of predefined fighters to choose from, but very few games actually allow you to build your fighter the way you want. Not only appearance, but also skills and even personality. Many wrestling games do that, granted, but they are inside a very specific niche, and it's not the setting I am looking for.

That said, I want to build a fighting game where players can fully customize their characters. From appearance to skills at the very least. The target audience for that is larger than one can imagine. but this can get complex quickly, especially considering I am building a Javascript game.

And that is my second motivation. There aren't any (AFAIK) good fighting games that run in a browser. A game one can spend hours on, either playing or customizing their characters. A game nobody needs to buy a console to play. Or, just for the sake of calling it yet another PC fighting game. And mobile, too. And, who knows, able to be played in consoles too. Someday.

Concept

It will be primarily a game where the player controls robots. In short (and derailing a bit), this is due to my lack of experience and inability to create proper character models. I am a programmer first, and unfortunately not much of an artist. Robot-looking humanoids are easier to build, and also cost less in terms of graphics. After all, this will be a Javascript game, so performance and memory usage will be of importance. And I believe that, given time, or when I find someone skilled enough to do it, higher-quality robots will surely join the fray.

The setting will be a mix of futuristic and post-apocalyptic themes in a very far future. Precisely, the year will be 3048, a time where humanity mostly failed to survive, but managed to develop technology to allow synthetic bodies to behave like humans. Their brains -- or AI units -- work by developing over time, as they learn things, pretty much like humans. Of course, it won't be exactly the same, but it will be fairly close. As far as fiction goes, it works.

In that setting, robots are categorized. There are normal units, the day-to-day citizens, and enhanced units, recognized as fighting units, who either keep the peace, cause chaos, or entertain others artistically. Those units will be the ones controlled by players, and players will also be able to create their own units from the ground up, with the skills they want, and the look they want (within the possibilities).

Technical

This is probably the part you are looking forward the most. If I am right, you are reading this blog because you are also a programmer, or have some knowledge in the area. But if you aren't, pardon me for going technical a bit.

This project will be a website (of course) which will run on Ruby on Rails. I've been using Ruby for so long now, it just feels wrong to go any other route. I could go Node.js, but I am just more used and comfortable with Ruby. Either way, the website project will be very important. The game basically will be a webpage where most of the game graphics run on a <canvas> element, but some UI work will be done in HTML/CSS.

Obviously, Javascript will be heavily used. As far as graphics themselves, I am going for WebGL with Three.js. I have tried BabylonJS before, but it is heavily opinionated - it makes some decisions for you, without giving you options to customize your needs. It won't work with this project due to the heavy customization plans I have for it.

Graphics

Again, I am not an artist. But I think there's something I can do with these:


Yes, they're just a bunch of cubes glued together. ;-)

The above models were generated in Three.js, using pure Javascript. No external files. Each model is an instance of a Character() class. You can pass different arguments onto the constructor to change it, like, for example, colors, as the examples above show.

Developing that class gave me the opportunity to carry on with the rest of the project. I don't need to worry about the Character class right now. I can "finish" the game with this model. Like I said before, the focus is gameplay, and there's so much to do in that sense that I can not afford spending time polishing the character model. But I won't leave it at that, of course. It just won't be a priority.

At the time of this post, I am working on the posing framework. Basically, Character instances will have methods to receive posing definitions. Every "cube" in the model is able to be rotated, and a combination of rotations end in a pose. As I work in that part, I will be developing some default poses for the next part...

... which is Animation. Animation is just a bunch of poses in a timeline. This is how most fighting games work. So I need a number of poses to create the initial animations. They will be very basic, of course, but with room for improvements, for example, using tweens between pose definitions to give a better sense of movement realism.

After I have the animations ready, it's time to create the basic Skills. A Skill is an Animation with extended information. This is where things like hitboxes, damage amounts, input sequences, etc, come into play. I am thinking this will be one of the hardest classes to pull off, as it will require extensive knowledge about how fighting games work on the inside. I have most of that knowledge (frame data, hit/block stuns, recovery, and so on) but I'm sure I will have to learn more to get it done properly.

Having Skills ready, it will be time to put those Characters into a Match. An instance of a Match holds things like teams, fighters belonging to those teams, amount of HP/SP of every fighter, rounds needed for the match, battle timer, etc. Essentially, the heart of gameplay goes here. And this is where I need this game to shine. This is where multiplayer might be born, if it's done properly.

Multiplayer

A fighting game without online gameplay these days does not tend to last long. Online Play will also be a monster to tackle. In technical terms, I can't just open a socket to a server and then do real-time data transferring to both players. That is very fast, but it's not fast enough for fighting games. This would be laggy as the server intermediates the data packets. In my initial tests, if the server is located in the same area as the player, the full ping would be 80ms. That already represents 1-2 frame drops in performance. If different area, 300ms or so. That's enough to make for a terrible experience. So for this to work, connection between both players needs to be direct. There are experimental web technologies (WebRTC) that allow two browsers to connect directly, so I plan on working with that. If I am not able to pull that off in a webpage in a browser, I am thinking about creating a desktop client with the same capabilities of the browser game. Basically a desktop port. It will work better because it will be a standalone client and will also have access to more hardware-oriented features (namely: network, sound, graphics) that are otherwise limited in browsers due to safety concerns.

As far as gameplay goes, the amount of customization that I have in mind will also present a challenge in online play. This is where balance will play the most important part. Since I totally do NOT like unbalanced games, I will do a lot of research on this to get it done right.

Customization

Actually, building the character with anything but cubes was intentional.

Think of it as a robot you assemble. Every cube, or group of cubes (hands, for example), will be able to be replaced by other geometries. Those geometries will be customizable with paint jobs and will also have sockets for additional accessories. Think of arm blades, shoulder pads, perhaps some clothing like capes and stuff. (Not everything needs to be metal. And it's not even metal, it's synthetic anyway...) All in all, you will be able to replace those low-quality cubes with better things, giving your robot a better look, and further improve it with accessories and effects.

As for skills, every robot, as a fighter, has the knowledge of a martial art. Players will be able to choose which art their robots start with. Then, every skill will be tailored under that martial art. Say your robot knows karate. You will be able to pick the punches and kicks you want, from a huge collection of skills, then improve them based on a character level system. Those skills will be first tailored to the chosen martial art, but some skills are global and available to all arts. Things like stance, the way your robots walk, jump, fall, and even how they take hits, everything will be customizable. Win poses, taunts, dashes/running, the list goes on.

I am so looking forward to start developing this part. I am truly passionate about customization in games, and I want it to be as much an enjoyable experience for everyone as it would be for me.

Monetization

Working on this project has been a slow process as I mostly work on it during weekends. My day job takes all my energy during the week, and I need the money. Speaking of the devil, yes, I want to build a game I can monetize. Another sensitive subject for sure, but I already have a very clear idea of what to do without turning it into a Pay-to-Win scheme. I have played other games that favored monetization above anything, even balance. Having broken, overpowered things that you can purchase with money sucks the fun out of things after a while. There are other ways to monetize without compromising balance, and I believe it's even better, money-wise, to have a balanced and competitive game, as it makes players stick around for longer, increasing their chances of spending money in the game.

What's Next

Next for me is... a lot of work. :-) I am currently working in the posing framework and improving the functionality of the Character class. The next posts may have small reports of my progress, hopefully with some code and pictures.

See you then, and thanks for stopping by.