Monday, December 25, 2017

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.

Wednesday, December 13, 2017

Newest Project

I wanted to wait until I had more art to announce it, but I've been super busy writing back-end stuff that I haven't had time to do more than the very lowest level of art.

I'm making another game! It WILL be out the 23'rd, and it will be available on Itch.Io. It involves reindeer and elves and a large man in red. It will play like a collection of mini-games which loosely effect each other over the course of each play through.

Here's a reindeer doing a belly slide!

Monday, December 4, 2017

Post Ludum Dare #40

Ludum dare was by far some of the most fun I've had making a project. Having the feed with other creators open in the background really gave me the motivation to keep moving forward. Even when I realized my codebase was becoming quiet shaky, I pushed through. I have a finished game! It is small and not well balanced, it becomes quiet repetitive, but it works the way it should, and I am very happy I submitted it.

You can play it here.

Friday night when the theme dropped I quickly started brainstorming. I decided on defending an ever growing hoard, with the number of enemies directly corresponding to the size of your hoard. I opened a text document and quickly jotted down my basic game loop:

"you're a swordsman, you run around collecting gold coins
the more coins you have the more enemies spawn to kill you you'll eventually die BREAKDOWN Character-sideways movement, jump, swing sword Enemies- gobs, ignore player rush towards gold if gobs collide with player player takes damage gobs die after 1 hit
player has hp, takes damage from gobs
gobs who leave the area permenantly take the coin with them"

GDD complete!

I open jMonkey ide and create a new project and start importing libraries. I initialize my repo and make a first commit, everything going smooth. Until I realize I made my project inside of another one of my projects directories. I quickly tell jMonkey ide to move the project, but now my repo is messed up. I try to fix to no avail. Not the best of starts, but I'm not to worried.

Next I create some very simple artwork. A simple human, a coin, a pile of gold "poo", some cobblestone, and scribble of a "Gob" - the main enemy in the game.


With some quick artwork finished I can start working on some game elements. This is one of the first times I was attempting something in true 2d, with all pixel art. I knew I needed to keep pixel densities as close to eachother as possible but I didn't know how to approach a spritesheet or 2d animations. I made a simple entity component that you assign a texture to, and the system will create a jMonkey spatial which uses the size of the texture to determine the size of the quad needed for the world. This worked perfectly, for now.

Working without animations is easy, most of the logical code is similar to games I've worked on in the past. I decided I wasn't going to use the library I have been building up with easily re-usable code for this project. I was curious how I would come up with implementing things without using my old code as a crutch. This turned out to be a good thing as I have re-worked systems I have taken for granted in my old library and I believe my new systems are much cleaner. This helped with this project as I could quickly implement exactly what I needed without any added weight.

With dyn4j integrated, character movement functioning and the beginning of the coin code started I decided I was far enough along I needed to start having animations. I needed a way to visualize attacks and goblin states without relying on println's. This is when I realized that nifty system I designed in the beginning was actually quiet terrible for sprite animations.

For sprite animations it's best to have large image maps with every frame of the animation on one image. With my current system this would have caused the game object quads to be huge and the animations to not appear correctly. I was relying on a sprite shader I found in the jMonkey forums from a long time ago (Thank you Pesegato!) which would position a quads uv coords along an image for the specified index, thus making setting the frame as simple as "setFloat(index)". I probably could of found a way around this, kept each frame a seperate image and loaded each image as needed but I believe this would have been much slower.

I wound up making a "bandaid" system which took an animation component, a new image and just stole the existing game object quad to use. Not great at all, but functional.



Fixing the animations took me to the 24 hr mark, I had no sleep at this point and was looking forward to another 24 hours. I used to work 2 jobs so I've been up for 48+ hours in the past, but things are a little different sitting at a computer. I made sure to take frequent breaks. Get up, stretch, grab drinks. Eventually my stamina was wearing thin.

Nearing 30 hours I had finally finished the coin counting and inventory system. It's a pretty reliable system but it is limited. No entity can carry more than 1 coin, and the entityId is simply added to a list of "carrying coin" entities. If the player reaches his hoard his id is removed and he gets +1 hoard. If a gob runs off the world his id gets removed from the list. Gobl spawns are a simple 1+hoard/3.

36-37 hours in I took a nap. Thank you to my ultra-supportive wife who put up with me being grumpy and got me out of bed after 2.5 hours.

The nap helped but I was still exhausted. I wound up finishing art assets, re-doing all the animations and called it done. I really wish I had tried to add in 1 other enemy type and an "end game" boss, but my head was way to cloudy to focus. I wound up posting the project a couple hours before compo ended and went back to sleep.

When I woke back up around 7-8 (an hour before compo ended) my wife asked to play the finished game. I went into my dist folder to open the finished game file as opposed to loading the ide which takes a lot longer. I'm really glad I did because it turns out I had packaged everything wrong! I spent the next half hour or so figuring out what went wrong, fixing it, re-packaging and re-uploading. Still turned in early but now I had at least a working executable uploaded!



Ludum dare was an awesome experience. As a newbie dev this was a kick I definitely needed and enjoyed every minute of it. I already plan on entering the next dare, as well as focus on producing more finished projects between now and then.

Thanks for reading and I hope to see you at a dare in the future!

Friday, December 1, 2017

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

Tuesday, November 21, 2017

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!

Sunday, November 12, 2017

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.

Saturday, November 4, 2017

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.


Sunday, October 29, 2017

Back from hiatus & Itch.io

Hello, I hope you all had a good summer. Mine was busy, working non stop 12-14 hour days all summer, now I'm done with that and I have time to sit down and work on games again! :)

I decided to upload all my games to itch.io to make downloading them easier and not rely on google docs, which isn't really intended for distributing large numbers of downloads.

My itch url is https://mruniversegames.itch.io, I'll work on uploading the games I have completed over the next couple of days. I am also working on a new project which I hope to have finished in the next 2 or 3 weeks!

I hope to see you again soon.

Tuesday, March 21, 2017

No longer a game a week :(

Hey everyone, sorry as the title suggests I'm not doing a game a week anymore. For those curious I decided I wasn't going to continue at that pace last Friday as I was working on The Getaway. The primary reason is simple, I need to get a real job and these games are growing in scope.

I will now be posting every other week.

On one half I will be getting at least a part time job soon so I will have maybe half as much time to work on these games. Making games has honestly been the most fun I've ever had revolving around video games. Getting a new job will certainly not stop me from doing this, but I do need a source of income as my savings are starting to dwindle.

On the other half the scope of my games has grown every week. This may be do to my own lack of planning but it was difficult to jump straight from one project to the next with no break in between. I also put my previous projects on hold for the previous 5 weeks and it wasn't until last week when I gave myself a break that I had time to look back at any of those, and I made a ton of progress!

I will apologize that I won't be releasing every week. I am hopeful that releasing every other week will see a solid foundation for the quality I expect in my finished pieces, while also giving me the chance to work on my long term projects and support myself and my growing family.

Thanks for reading and I will see you on the 27th with a game featuring Bombs!

Monday, March 13, 2017

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

Monday, March 6, 2017

Bork Pawtrol

This week I was challenged to make a game themed about internet memes by my wife... I'm not entirely proud of this one, though looking back at it I realize it has far more assets and stuff going on than any of my previous games. This week I bring you, BorkPawtrol...

So what is BorkPawtrol? well for those who don't know Bork is the sound a Doge makes... apparently... and Pawtrol was a fun play on words apparently... Originally I was asked to clone MoonPatrol, which I wasn't opposed to but I thought I had enough space-themed last month so I wanted to try something fresh. I went with an infinite runner where you control Doge, bork other internet memes and try not to fall in holes by turning into a corndog...

Controls are simple: Right arrow fire a bork. Borks will kill any meme they hit. Holding Up arrow will transform you into a corn-dog. Corn-dogs can fly, but corn-dogs cannot bork. Corn dogs will fly over pits, but will run into Shoop Da Woops. Press M to toggle music off.

What troubles did I run into this week? Mostly animation, and not game engine related. Blender wanted to fight me every chance it could. Mostly with the ogre-xml exporter which I had never tried before. I'm fairly sure I understand it's issues now and will be able to avoid these headaches in the future.

Tools used: jMonkey, Zay-es, Lemur GUI, Blender, Krita

Download URL
https://drive.google.com/open?id=0Bz4nByoX2Ks7OEQtRGhpSDJhSXc

Sunday, February 26, 2017

Landing on the Moon

Hello again, this week I bring you, jLander! A game where you must successfully land a lunar module on the moon. Careful, you have limited fuel and every input needs it! You get points by landing on a zone (smaller = more) and having extra fuel remaining. Landing zones are highlighted green. Landing empty means you won't be able to return to orbit.

I am going to stop bundling a runtime environment to keep download size smaller. If you are having trouble getting the app to work, be sure and download the latest version of Java here.

As usual I made jLander with the help of JMonkeyEngine LemurGui, Zay-Es, and this week I used dyn4j for the physics.

The hardest thing about jLander was setting the proper win or lose states. Turns out theres alot of different ways to win or lose, and I most likely missed a couple! For those who are curious, you are considered landed when: The lander is in contact with the terrain, the lander is pointed +-3 degrees from straight up, the lander is not applying thrust, the lander is not out of fuel and finally, when the lander has not moved more than 0.4 world units for a total of one second.

A short review for dyn4j. It took me the better part of 2 days to be fully comfortable with how dyn4j operates. Now that I am familiar I believe it will be easier for me to implement the engine and its features in the future. That said, the documentation is rather lacking. I gather that for the most part dyn4j is intended to be freely integrated how the user sees fit. This has positives and negatives but I believe I will attempt to use the library in future projects where it makes sense.

There is a known glitch where if you crash while applying thrust the particle effect continues to play. I could probably iron this bug out, but particles were one of the last things I implemented and I'm honestly feeling done with the game as it is now. Sorry :p

Download link:
https://drive.google.com/open?id=0Bz4nByoX2Ks7S2ZKRlRaNUJBLWM

Monday, February 20, 2017

jSnake!

This weekend I finished another game, this time a Snake game. As far as gameplay goes it's a very basic snake game, there's only 1 objective and that's to eat as many coins as you can without eating yourself or a wall. Arrow keys or WASD for controls, M toggles the music on and off and Enter will reset you when you die. There is a secret way to make the game go faster, which also awards you more points every time you eat a coin ;)

As far as the technical side of things the game itself was actually super simple. I made it in jMonkey again, with zay-es and lemur gui like last time. The game itself is actually just a grid of numbers with each number representing either empty space, a wall, a coin or a part of the dragon. Every time the game world updates it advances the head of the dragon by the currently chosen direction (just hold the direction you wanna go) and it will remove the tail, all the other numbers stay the same. If a coin is eaten it doesn't remove the tail this round, so it will grow.

The hardest part was getting the game to be visualized in 3d. I accomplished this by breaking my map down into several parts.

First, the Dragon (or snake as it's usually referred to internally) is a list of coordinates which are written to the map every time it updates. This list is ordered so I always know where the head and tail are, and I can keep tabs on each part of the body. The head and tail always exist and they just update their positions, a new body needs to be created every time the coin is eaten though. At first I thought the entity component system would make this hard, but in practice it made it super easy to update the body without much work.

The coin is rather simple. The 3d model is actually always present, it just gets hidden when the coin is eaten. Then the game will attempt to place the coin somewhere on the map, once a frame until it's successful. The larger your snake the more attempts this will take. I suppose theoretically you might get to a point where it takes several of the games turns before a new coin actually appears, but in practice you're more likely to get bored and bite your own tail before then. (editors note: 1 game turn = alot of frames)

The maps 3d model is updated on a reset. This is to allow the possibility of a map re-size, but for the purposes of this demo I just left the size fixed.

Once again you can download the finished game by using the url below. I posted a win32 build and the JAR so if you have Java installed it should run on most operating systems.

https://drive.google.com/drive/folders/0Bz4nByoX2Ks7NGd5X0QzWjVFSjg?usp=sharing

Friday, February 17, 2017

Intro and jAsteroids!

Hello and welcome to my gaming blog! This blog is a place for me to post about what I'm working on as well as links to things I've finished.

My goal is to make a game a week for at least the next year. These games will likely all be small, and most of them clones. I'll detail out the creative process for each game and be sure to highlight areas where I had trouble so hopefully you can learn to make games as well.

Last weekend I finished my first game, jAsteroids! This is a simple asteroids clone coded in Java using jMonkeyEngine and zay-es. I followed zay-es tutorial rather closely to implement the spatial rendering, but most other code I had to create myself. I implemented a super basic collision detection for every collide able object in the scene. The asteroids are defined by an integer, 1-5 which corresponds to their size. Every time an asteroid collides with something non-asteroid they are destroyed and spawn 2-4 asteroids of the next size down, until size 0 where no more will spawn. The game ends when you clear the screen. Write down that score and re-start to see how high you can get! (sorry, no persistence between levels, I only had 3 days)

Your ship has 3 health before it explodes. So fly safe and clean up those asteroids ;)

You can download by clicking the jAsteroids above, or by using this url below.
(sorry, win32 only for now, if you would like to see other OS's let me know!)
https://drive.google.com/open?id=0Bz4nByoX2Ks7QV82UUViekxjWUU

I will be taking suggestions for what games people would like to see made over 1 weekend.
This weekend will be a Snake game ;)