Physics are fun! Also Ludum Dare 45

Hello everyone, I hope you're having a fun Halloween time! I've spent most of the last few weeks working on costumes for the family, but I've also managed to squeeze in some programming, and even another fun project that my wife suggested and is co-producing!

Early this month was Ludum Dare 45! I thoroughly enjoy attempting this jam and I was looking forward to giving it another run. The theme was "Start with nothing" and I set a restriction to NOT make another 2d sidescroller action game. Instead I started with the idea "Open a shop in a back alley as a homeless person." I do wish to take a moment and say I recognize the sensitivity of this topic. Many cities in the US are facing a major problem with homelessness, and I strongly feel the position of many citizens and governments are actively making the situation worse. This helped shape the tone of my game to focus on the desperation of such a situation.


Every morning random garbage spawns in 2 back alleys. You must collect this garbage and attempt to talk to people to find anyone willing to give you money in exchange for this garbage. "One man's garbage is another mans treasure." If you are unable to raise $10 by nightfall you will not have enough money for food and water, and will not survive the night. To make things even harder every item is made up of a grid which takes up space in your inventory. Your inventory is pathetically small at 2x5, with items being 1x1, 1x2, 2x1 or 2x2 in size.

Just because you manage to fit an item in your jacket doesn't mean you'll be able to sell it. People are not willing to stop and chat with a homeless person and will largely ignore you. If you don't have exactly what someone wants, when they want it they'll continue on their way and get the item from somewhere else.

This game took me right up to the deadline to finish and is missing many features I had hoped to implement. That said if you are interested I have posted a playable version to Itch and the source code is available on Github.

I've been really focused on working through physics and collisions for Project Bogie. I know I want rather large environments and a system that integrates well with my entity-data structure, so I figured I could tackle most of the collisions from scratch. This is working pretty much as well as I had hoped, with some parts going very smoothly and others being kind of a pain, but progress is being made every week and I can't complain about that!

The flight physics I want to try are loosely based off real aerodynamic lift models. I am boiling the flight dynamics I wish to see in each aircraft into as few tables as possible. I am not trying to make a simulator so everything is being focused on feel.

I should note that I do not plan on including any real world vehicles. Everything will be fictional and slightly futuristic. I find the aesthetic for Crimson Skies very appealing.

Collisions are causing a bit of a headache. Object to object collisions were surprisingly straight forward to implement and I am very happy with the results. Terrain is currently problematic and I have gone through several iterations to find what works the best. I do not need incredibly accurate terrain collisions to get a functional prototype working, I do need one that works consistently. This is likely going to be my focus for the next week or so.

Until next time!

Project Ceres

My one side project kind of exploded.

It started as a "Multiplayer Asteroids" kind of game and turned into what is currently dubbed "Project Ceres" (real name determined but to be revealed at a later date). At it's core it's still about blowing up random asteroids.

The objective for now is to blow up asteroids which will drop little power ups. You need to return these power ups to the spawn area for additional points. Rinse and repeat until you explode, at which point your score gets reset and you can try all over again!

I am feeling close to finished with the core gameplay. In the end it wound up a lot less fun than I had hoped. I am not likely to polish it much beyond the minimum needed for it to be playable as I already have a queue of new projects I'd like to try.

Universal Sound Board side project

I've been quiet the past month and a half, but I haven't stopped working. I'm still working on the tutorial series for jme3 and I'll hopefully get the next article up in the next couple of weeks. In the meantime I made a fun little soundboard app!

Universal Sound Board

Instead of making a keybinding for every sound file you want to play (ctrl-h for hello.wav, ctrl-g for goodbye.wav) with this soundboard you can make custom "key combos" that lead to your desired sound. Turn on the key-capture with a user defined key (ctrl-v by default) and enter the combo for your sound. This lets you make as many sounds as you want in easy to remember combos! ctrl-v, h for hello, ctrl-v ty for thank you. The possibilities are endless.

The only restriction is you cannot assign a sound "passed" another sound. If you have "h" as hello, you couldn't make "hg" as goodbye, since it'll start playing "hello" first! I suggest you make your combos at least 1 or 2 letters deep to prevent them from stepping on eachother. g-h and g-g could be "hello" and "goodbye" respectively, and you could still use "h" seperately, or as the start of even more combos.

I hope some of you find this interesting and make some fun soundboards. Install a virtual audio cable for twice the fun ;)

The need for sheep

Hello, today I'm going to talk about a little project I've been working on to address something that's severely lacking from my favorite game engine, tutorials! That's right, I've been working on a super simple project with the intent on turning it into a short tutorial series!

Now some of you may be familiar with another blog I started once upon a time, Adventures in jMonkey Engine. (WOW, was that really 5 years ago?) Back then I barely understood java let alone jMonkey as a game engine. I started the blog with the intent of "learning" both java and jme through teaching it. I wound up giving up on after I hit a major roadblock on my rc car game project which ended in my taking a hiatus from game development for several months and generally forgetting I had that blog at all.

Back to the present, my wife recently told me she wants to learn java and help me make games! She has absolutely 0 experience with java and programming in general, but she loves video games, which is honestly all I think you really need nowadays.

I decided to make some new tutorials that approach jMonkey's way of doing things and really showing how to utilize the different aspects of the game engine. I'll focus on setting up the jMonkey IDE and focusing on best practices for creating games in jme. There are a few tutorials out there already but a lot of them are old or are long videos with no voice over and showing a highlighted mouse waving in front of what is being demonstrated. jMonkey doesn't have many tutorials that could be compared to what more mainstream engines have such as Unity's "how to make an fps" tutorials.

So I'm finishing up a small demonstration game which I will then break into pieces and put together a "how to make a game in jme" series which will be uploaded to this blog and maybe youtube(not sure). Here's a couple screenshots showing where the game is now. It's still a little early so some assets will change but the core gameplay is set!

Well that's all for today, just letting you all know what I've been doing and giving you something to look forward to!

Gothic is out

Gothic is up on Itch.io, for a multiplayer game it does not have a game browser or any easy-join functionality. You'll have to find other players and share ip's and set up port forwarding. There is a single player challenge mode with a castle prefab to see how quickly you can take it down, but the enemy does not return fire.

This project is now on hold until I can get enough support to justify looking into a central server. With a central server it'd be easy to implement a games browser and host games without forwarding ports, but I don't have the means to support one at the moment.

I have another small to medium sized project in the planning phase right now, Project Field. I'll have some more info on that shortly.

If anyone is interested in playing Gothic feel free to comment and I can set up times to have a server hosted on my personal computer. The only map in the game is 2 teams at the moment but each team can have multiple players controlling it! They share resources and units can a lot of fun can be had assigning roles within the teams and coming up with strategies to counter your opponents onslaught.

It is also extremely easy to add new maps or units to the game. Even though the project is officially on hold (kinda like Reindeer Rearing) I might swing around and add a new map or two. If you like making maps for games take a peak in the /assets/ directory (open the .jar with win rar as if it were a zip archive). There is a simple xml detailing the info for a map, and a text file under /assets/Scenes/Maps that you can append with the xml for your map and it will appear as a selectable map in the game. The challenge castles are a regular xml you can open and modify as well, and can be listed in a map as a valid challenge target.

I apologize for Gothic coming out in such a state but I wanted a chance to put the game out there as an early prototype to see if people are interested in this style of game. Single player would be an awesome addition but writing good ai for an rts is difficult and time consuming, especially for a project I am unsure will be played enough to justify the amount of time involved.

Project Gothic

Working title: Project Gothic
Defend your keep while you smash your opponents! At the moment I only have multiplayer working. I will upload it as soon as I have a simple "time trial" single player, and I'll eventually add in ai opponents.

This project was a LOT of firsts for me. Building a game for multiplayer from the ground up requires a very different mindset and I hit a lot of roadblocks along the way. I try to rely on as few external libraries as possible to keep the design as clean as possible. I use jMonkey Engine as it's a very good, easily expandable engine based on lwjgl. For the UI I use Lemur GUI which is built from the ground up to work with and resemble jMonkey's scene graph and spatials. This makes adding and modifying ui elements extremely simple. I also use ZayEs Entity-Component system. By following "pure" Entity-component design philosophy I was able to add in complex systems that are very modular in nature, and allowed very easy online integration and I can trouble shoot each system independently. This does come with a memory over-head of storing large numbers of component objects and systems often have similar structures that are kept separate from each other. I feel requiring more memory is worth the trade off of having very distinct systems and components with very few cross contamination.

The assets are very simple assets I threw together quickly to have something playable. I probably won't revisit the assets unless this project gets enough interest.

Well that's all I have for right now. Expect something playable to be uploaded in the next couple of weeks!

Reindeer Rearing early build!

An early build of the project I was teasing is up on itch, Reindeer Rearing!

Reindeer Rearing is a simple game where you have 15 days to raise a reindeer to be the best reindeer it can be among 4 different stats. To train a stat you engage in a mini game related to that stat. When you win the stat is increased. When you lose a corresponding stat is effected negatively.

As it stands it's a pretty early version I put up to enter in the contest I originally started the project for. The mini games are not balanced well, though most do scale in difficulty. It's lacking a lot of art assets and animations as well. There is also no audio in the game yet.

Over the next week or so I will have another update which will focus on adding in more artwork and hopefully getting the balance of the mini games.

While I'm working on art assets for Reindeer Rearing I also plan on implementing my new sprite system into Dungeon Hoard. This won't get uploaded right away as it doesn't add anything performance wise for the player, but it does help maintain pixel accuracy while also making it much easier to add new units and animations.

I'll have a new blog post later this week talking about how I achieve pixel accuracy in a 3d, floating point game engine.

Ludum Dare 40

I'm in!

It's my first time trying a game jam. I figure I can take the weekend and really put in an effort at making something short and sweet.

Result will be uploaded on itch.io regardless of quality. You've been warned in advance :P

Lots of progress

It's been a little over a week since I last posted. I've made a ton of progress but not alot that can really be shown. I'll do what I can with some quick screenshots.

First of all I decided to just ignore the particles issue for now. I'm nowhere near ready to start really working on fx and what i have works for what is needed.

I fixed a bug that had been annoying me since I first wrote the flight physics. When the aircraft was near 180 and the velocity dipped more or less the flight physics would go crazy. This was most obvious when I tried to implement barrel rolls. When upside down the angle of attack would get stuck at + or - 180 and you would either turn into a rocket ship or get slammed into the ground. well I fixed it! before I was finding the difference between your 3d forward vector, projected to 2d space, and the 2d physics engine velocity vector. This worked for small values but not larger ones. I now project the 2d velocity vector into 3d, and convert it to a "local" vector for the plane. I then project the local 3d vector back to 2d and find the angle. Theres actually less math involved in this case since atan2, which is expensive, is only called once instead of twice. All other math involved is fast multiplication, and I get the results I need for ALL angles!

I also fixed the "Snap" that was shown here.

As you can see in the gif I now have a better camera. It centers on where the player is looking while making sure the players vehicle stays on-screen, that way you have a good view of whats in front no matter your angle.

The next big step is terrain editing. I am working on an editor to make generating terrains fast and easy for myself. I'll do a more in depth post on it when it's in a more finished state. Once I'm happy with terrain editing I'll of course need a more general level editor where I can define terrain, player spawn, enemies, objectives, scenery, etc.

This project is definitely the longest one so far, but also the most complex yet!

Particles

I'm having some trouble with particles. On one hand I'd like to keep them simple so I can re-use the assets between emitters. On the other hand jMonkey's built in particle system doesn't like dark particles.

I am happy with the effect I came up with for rockets, and I was able to re-do my old particle system to keep persistent trails around after the rocket entity dies. But I am not happy with the blend modes available to jme.

Jme has 9 different blend modes for it's particle material, and of those modes 6 are "additive" type modes, or modes which when combined make the color brighter. This makes sense for alot of particles, white smoke, clouds, fire and electricity all make things brighter. When you want things to get darker though, it gets more complicated.

So much of the effect gets blown out from the additive modes.

Alternatively I can use alpha blend, and color all the particle effects in an image editor. This results in some nice looking effects but it becomes much harder to re-use assets. Currently all of my particles are simple black and white textures which makes it easy to use the same effect for fire, smoke, fog, water, etc.

I think I am going to look into adding more blend modes myself over the next week or so.

Zay-es and "Blueprints"

One of my favorite libraries for jmonkey is Zay-es entity system. Zay-es is a powerful entity-component system that really forces you to consider an entity-component system from a very "pure" perspective. This is really great for rapid prototyping as I have built up a collection of components that are very easy to drag and drop from project to project. The only thing I really need to change are the underlying systems.

That said, entity-component systems to have their shortcomings. One problem I have been trying to find a good solution to is saving and loading entities. Zay-es has a way to do this, though from what I've read it's focused more on saving/loading the entire system as opposed to a single entity. I am interested in saving/loading a "blueprint" of an entity, much like Unity's prefabs. In the past I have used factory type builders to get an entity when I needed to spawn many similar objects, such as bullets or enemies.

Today I figured out a way to achieve this using json files! I came up with a simple way to use Gson to read and write easy to read files with all the components you would like attached to an entity. These files are simple text files so modifying them outside an ide is simple. Here's an example file for you :

com.mru.lib.scene.TransformComponent
{"position":{"x":0.0,"y":1.0,"z":0.0},"scale":{"x":1.0,"y":1.0,"z":1.0},"rotation":{"x":0.0,"y":0.0,"z":0.0,"w":1.0}}
com.mru.lib.scene.ChildComponent
{"parent":{"id":1},"offset":{"x":0.0,"y":1.0,"z":0.0},"scale":{"x":1.0,"y":1.0,"z":1.0},"rot":{"x":0.0,"y":0.0,"z":0.0,"w":1.0}}
com.mru.lib.scene.ModelAssetComponent
{"key":{"name":"models/MG.j3o"}}

My simple Gson parser assumes that every component is preceded by the class path. This is read using a buffered reader and the class is located. After a class is located the reader will read the next line using Gson which will instantiate the component.

The read/write commands are held within an "Entity Blueprint" class, which is basically just a set of components and the read/write commands to parse the files. During run time the blueprints can be used to quickly set components of entities as they are created.

In the example above you will notice a "child component". This is an example of the pitfalls to my system. Any component that references another entity (id:1) will not work after loading. There is no way I can guarantee entity's id's at runtime. For now I can design around this by not making blueprints of entities that rely on such components, but in the future this is a problem I will need to address.

The Getaway

Hello again. This week I made a game about running from the cops. The Getaway is a game where you've just robbed a bank and now you have to get as far as possible before you get run off the road and arrested.

Controls are simple, cursor keys to steer/accelerate/brake, left control or spacebar to shoot. M toggles music.

This weeks game was a little ambitious and I was hard pressed to complete all the features I wanted. I wanted there to be at least 2 enemies as well as civilians, but only 1 enemy made it in the game, and as it stands there are no civilians.

Infinite scrolling worlds are tons of fun to make and the effect is very nice, but I wasted a day and a half writing a procedural generator for the road system which included turns and varying road widths that I eventually just removed from the game due to the added complexity and how I wasn't happy with the results.

Collisions proved difficult as I didn't want to rely on dyn4j's built in collision handling, instead I opted for my own which matched the style I wanted to go with more closely. This was a major time sink though and probably accounted for a third of the work, but the game does play how I envisioned it so I don't consider it time wasted. On top of everything I decided to try multi-threading with the collisions. This lead to a solid day of de-bugging and odd behavior that took awhile to sort out. The magic of ecs made this a lot less painful though and I'm glad I tried it.

The other big time sink was assets. I like 3d models and I can whip out the mesh in maybe 2 hours for one of these cars, but textures eat alot of time for even very basic paint jobs. Particle effects are also very time consuming. I had no stock images to work with so I wound up having to run some simulations to get the effects I have now. Most of this should be easily re-usable for future projects though, which is a plus.

Ultimately this week proved tough for me as I had very high hopes for this project but in the end I had to remove large segments of what I was working on just so I could finish something by Monday. I'm pleased with the amount of work that went into this one though, and behind the scenes this project is easily twice as complex as any I've done yet.

Tools used: jMonkeyEngine, Zay-ES, Lemur, Dyn4j, Blender, Krita.
Download URL
https://drive.google.com/drive/folders/0Bz4nByoX2Ks7MGNHMVdGYkVRM3c?usp=sharing