Mr U Games

Welcome 2020

2020-01-01T18:41:00.002-08:00

Hello, I hope you had a good new years! I had a good holiday season but again I didn't get as much done as I had wanted.

I put alot of effort into learning Lemur's style system which is really cool but has a high learning curve. When I implemented my ui elements for Reindeer Rearing the first time in Lemur I wound up making many sub-classes of the default components. This looked good and worked as expected, but it was alot of work and alot of copied code. Using lemur's styling it looks like I can minimize this duplicated code almost entirely. Here's my current placeholder ui until I can re-work in the pixel art from before:

I was able to implement the chime sound effect when buttons are pressed in 7 lines in the style, which is automatically re-used for every button. In the original Reindeer Rearing the simple chime effect was 4 lines of code every time I created a button.

I am also completely re-working all of the mini games. I am aiming to get them to feel more responsive and overall more polished. At the moment they are all simple debug shapes or output text so there isn't much to show, so I hope to have some of the artwork moved over or replaced by my next post.

That's pretty much all I have for today. I'll try to have more artwork and maybe some usefull code snippets next time. Consider that a resolution ;)

Bogie Weapons and the return of Reindeer Rearing

2019-12-03T17:43:00.001-08:00

Hello, I hope you had a great November. My November was very productive. I had a solid week off from work due to the holiday and I dedicated most of that time to working on various projects!

Bogie is churning along nice and steady. I continue to bash away at physics to get them as consistent and predictable as possible. I was able to boil down the aircraft flight model into several easily modifieable and understandable tables and the results are very pleasing. The underlying math for the flight model is not likely to change dramatically from here on.

After I got the flight model in a useable position I started playing with weapons. I now have working machine guns and guided missiles, all weapon code is still rather early though and likely to change alot.

I was able to implement asynchonous loading and loading screens with progress bars! This was a first for me so I am pretty happy to discover how simple it could be.

December is here, and that means I decided to revisit Reindeer Rearing. I wound up leaving RR in it's broken state 2 years ago when I realized I was trying to build on top of a broken base. I decided to give the project a complete re-write while using the assets I had already created. Hopefully I can have this finished before Christmas.

That's all for my November update. I apologize for the lack of pictures but nearly everything I have finished is either completely behind the scenes or just being drawn with debug lines atm. I will do my best to have some screenshots for my next update!

Physics are fun! Also Ludum Dare 45

2019-10-29T18:47:00.001-07:00

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!

Another Hold, Another New Venture

2019-09-23T17:40:00.002-07:00

Game design is hard, solo game design is even harder. Sometimes you start with the greatest ideas and rush in to happily create what you think is awesome. Sometimes you get 80% of the way to a playable prototype and realize that awesome idea is really just some sparkly mud.

I'm putting Ceres on hold (probably indefinitely) since after getting as far as I did, I realized it was just plain not fun.

Now I'm working on another project under the name "Bogie" for now. This is a genre I've always wanted to try making a game for! As of writing this I don't have much more than cubes flying around in what feels like the direction I hope to take the project, but I'm also tackling some engine level problems that I've had crop up in previous projects. This is making for a much slower start than on Gothic or Ceres, but the end result will be several new libraries I will be able to re-use in the future which are solid and well tested.

Sometimes life hands you lemons, other times you try to grow lemons and realize you planted a thorn bush. I know I haven't had a playable project in awhile, but that's ok. Every day I'm working to make the next playable thing the best playable thing I can make!

Thanks for coming by and reading. If you're looking for something fun to do there are some playable games linked on the right, or check out my "Interested in making games?" section and try making something fun!

Project Ceres

2019-07-18T06:24:00.003-07:00

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.

Alot of progress, not much to show

2019-03-25T17:07:00.001-07:00

Hello, I just wanted to pop in real quick with an update. I've been making a lot of progress on fixing up Gothic. It's had some pretty major changes but most of which will be largely invisible. The biggest challenge I'm facing now is a decision to re-write the real time aspects into turn based gameplay. This decision came after I tried 3 or 4 different economies in a row and just wasn't happy with any of them. I think the turn based approach makes player actions more meaningful and fits with more traditional artillery games. The turns will be much like Worms except the player can set up multiple turrets to all fire at the end of the turn while also building and repairing structures. Managing your population will be an important resource to maintain peak performance.

I've started a couple of other side projects as well to keep my motivation up, but I won't talk about them to much as they're both pretty small in scope and will likely not be seen for awhile. One is not a game and is a challenge I like to return to every couple of years to try different approaches to solving. If I wind up with something worth showing I'll make this freely available with source code so everyone can fiddle with it. The other side project was a random idea I had while trying to convince a friend to play with jMonkey Engine. Again, not certain how far I'll pursue it but for now it's giving me a short break from staring at the same catapults every day.

Not much else to report. Thanks for stopping by!

Ludum Dare 43

2019-01-06T13:25:00.000-08:00

I realized I never made a post about my participation in Ludum Dare 43 where I finished my newest project, Slime Venture!

The theme for the latest Ludum Dare was "Sacrifices must be made" and what better thing to sacrifice than your own body or the bodies of similar creatures? I decided early on to stick with my theme of 2d platformers as I have become very familiar with the systems involved and I new I could get a functional prototype done quickly. I didn't dedicate the whole weekend to the compo so I wasn't willing to tackle something entirely new.

Credit to my wife for suggesting slimes, which were a great choice as I didn't have to put much effort into assets. Simple colored cubes while not much to look at were fully functional and believable. The bright colors also made it easy to differentiate the slimes from each other and the background.

JMonkeyEngine is of course my go to 3d engine with Java as the primary language. I decided midway through the project to also incorporate Groovy script to supplement Java and give me an easy way to test features without needing to compile. This also taught me that when Netbeans' Gradle plugin compiles a project with a sub-project containing your assets, those assets are copied and stored in a separate folder. After an hour of head scratching I figured this out and made a simple work around to access files directly for testing only.

I used dyn4j for the physics and collisions. Integrating the physics into JME is easy and consistent.

Zay-ES was used to take advantage of an entity-component system. While I don't feel as strongly about ECS as I used to (At one point I couldn't fathom making a game without one) I do still feel they are very useful and when implemented correctly greatly speed up prototyping. The art is in finding a balance between to many and to few components for any given situation and really fleshing out your systems on paper. Remember, your systems ultimately drive what components you make and not the other way around!

Lemur UI is my favorite GUI system for JME. It lacks some features but is so easy to work with that I rarely run into an issue I can't resolve.

The game loop is very simple: Every level has a spawn point that sets the player's avatar to a slime with a given size and color. Every level needs to specify a trigger to activate level end. The only trigger I used for the Jam was a simple detection zone that would detect the player entities id if the player was inside the zone. There was no visual editor for levels and they are all described via groovy script calling java functions to build the various set pieces.

Slimes all have a size (1-5) and a color (blue or green in the prototype). Slimes who are a larger size will consume slimes of a smaller size. This is true for slimes of the same color, so beware you can still be eaten by "friendly" looking slimes! If you consume a slime that is your color and smaller than you, you grow 1 size. If you consume a slime that is a different color and 1 size smaller than you, you shrink 1 size. Smaller slimes move faster and jump higher than big slimes. Most levels features obstacles that were to small for large slimes to pass through, so you would need to shrink yourself enough to squeeze through. Other levels would require you to eat slimes in a certain order to be the correct size to finish the level.

All in all this Ludum Dare was tons of fun. I didn't dedicate my entire weekend, and altogether probably spent 12 hours working on this project. By setting the scope very small and dedicating more time to interacting with my wife and kid I had a much easier time focusing on programming when I did sit down to work.

Happy New Years!

2018-12-31T13:40:00.003-08:00

I hope you had a wonderful holiday season and are welcoming in the new year! Here's a little update on the state of my projects.

I worked a lot of overtime at my day job this month so I wasn't able to completely re-write Reindeer Rearing like I had hoped, but I was able to greatly reduce the ram usage by cutting out a largely redundant system I was using to handle sprites. I was able to touch on all of the mini games at least a little under the hood to make them better self contained and more reliable. I haven't experienced any crashes through testing but if you find any bugs don't be afraid to message me! Lastly I re worked how the toy builder mini game handles the different toys. What was before 7 textures and a data file has been reduced to a single texture! This isn't a texture sheet either, to add new toys is as simple as drawing their finished sprite. The game will automatically split this sprite into 3 pieces and color it black when it's loaded. The sprites are currently all hard-coded but in the future I'd like to support user files to add to a sprite list.

Now that the holiday season is wrapping up I look forward to the next item on my list, Project Gothic. Gothic is still the most viewed/downloaded game on my itch and it desperately deserves to be re-worked into a more functional and finished project. I have no time frame on when I plan to move updates for Gothic, except that I will be converting the project over to a Gradle project tomorrow and I'll start whittling away at it after that. Gothic is the focus until I deem it in a polished state!

While Gothic is my #1 focus I find I tend to work better if I have a side project going for when I hit roadblocks. The side project while I work on Gothic is going to be Slime Venture! I fully intend to polish Slime Venture into a finished project now that the Jam is over. It was well received and I believe has a very firm framework that held up very well during the short period I put it together. It won't be my primary focus for the next couple of months but I will be revisiting the level generation and menus to make it a better game in my spare time. I will also be making some finished assets for it to practice with Blender animations and prep for more detailed work that Gothic will require.

I wish you the happiest new year!

Spooky Progress and More News

2018-11-04T18:45:00.002-08:00

So I had originally hoped to have Spooky finished by Halloween. That didn't happen. I've actually become quiet invested in making a suite of 2d platforming tools within JME which has resulted in Spooky taking a LOT longer than originally anticipated, and also means the scope of Spooky is probably getting bigger than originally planned as well. Making games is fun!

I have the foundation for a much more robust Sprite system than I've done before, and I've implemented Tile Maps with a custom collision system that is looking very promising. The platforming aspects of Spooky are something I've wanted to do in games for a long time, but I always used pre-made physics systems. Using physics is great for some games, but in games where you want more deterministic responses to collisions and the environment they tend to make simple things more difficult. Hopefully this makes Spooky's controls much tighter and more responsive than Dungeon Hordes were.

The month of November will likely not see any major updates to Gothic as I had expressed last time. I still really want to sit down and work through all my poorly realized net code and incomplete understanding of ES systems to make Gothic the game it deserves to be. For now it has been moved from "Probably in November" to "Maybe in January". Not the best news but that's where it's at.

Reindeer Rearing will still very likely see updates come December. A large amount of work I am doing for Spooky should be directly applicable to Reindeer Rearing. I'm honestly excited about the chance to clean things up and really fix some of the more game breaking bugs I had left due to time constraints. (Reindeer Rearing was originally made for a Jam).

My current schedule looks something like this: Continue working on Spooky with the hopes of getting a vertical slice level by the end of the month. Once December starts wherever I am at with Spooky will go on hold until I can at least clean up Reindeer Rearing and tackle some of the bigger bugs as well as re-do the sprite system to be in line with Spooky's sprite system. Once RR has seen enough polish to warrant another update, go back to Spooky.

Next update will have some screenshots no matter how ugly they are!

A Scheduling Update

2018-10-04T12:56:00.000-07:00

Hello again! it's been a couple of months so I figured I should make a post saying what I've been up to and my current road map.

First off, I disappeared again after getting another job. Finding good ones is hard, but this one will likely stick for awhile. My hours are a lot better and I have had a LOT more time to work on things, of course I also have my kid, so that's where a lot of that time went!

I also built a new computer from scratch. This was a much needed upgrade though it did result in a couple of weeks where I didn't have access to my usual desktop environment. It also lead to me switching from Windows to Linux. I still have a copy of Windows 10 that I mostly use for playing games, I am about 90% on Linux Mint now. This means I have less distractions since most games are a reboot away so I can focus on tasks better.

I've been working on my programming projects so here's the quick rundown:

Project Dawn (from WAY back when I first tried making a game in unity) has been re-booted entirely and I've actually made a lot of progress. It's a 3rd person spaceship game somewhere in between the X games and EVE Online. I probably won't mention more than that for a long time since that's a very large project and even though I've been burning through my checklist it's still a very long ways from being playable.

Sheep Tutorial is kind of on hiatus for now. I lost some of my source files when I transferred (an issue with getting Linux to play nice with ntfs file systems caused by my relative lack of Linux experience) but it's not abandoned, just waiting for a long weekend where I can sit down and get back up to speed.

For the month of October I am working on a project called Spooky! It's planned to be a 2d platformer I am planning to launch on October 31st. More info will come as I make progress worth showing.

If all goes well with Spooky and I get relatively close to my release without any major issues, November will be dedicated to going back and really re-working Gothic. I've noticed it's probably my highest trafficked project and I really sort of dumped it without giving it a proper round of polish. I won't make any major promises outside of cleaning up the UI and re-working alot of systems that were largely hacked together.

Lastly, December will be Reindeer Rearing's month of love. I plan on thoroughly re-working it's systems and giving it a solid round of polish it definitely deserves.

Well that's pretty much all I have for right now. I hope to have some screenshots and better news to share shortly!

Simple Arcade Game 4: User Input and Spatial Controls

2018-07-17T17:16:00.000-07:00

Welcome back to our simple arcade game tutorial where we look into what it takes to make a very simple, flock herding game using jMonkeyEngine. Today we are going to start adding logic to our game. We are going to start with a simple way to steer the white cube we made last time by reading user input, and applying the movements to our game objects via Controls.

First, let's look at our GameState class. Our GameState extends AbstractAppState and overrides the Initialize method. We also have a custom method to spawn our player object. We are going to add a few more lines in our Initialize method to handle user input.

First let's grab the SimpleApplications input manager. The input manager needs to have Mappings added which we will later listen for, so let's define some static mapping names so they are easy to find later. We then take our InputManager and add our mappings to specific key bindings. For keyboard keys we use a KeyTrigger and grab the keycode from the KeyInput class.

public class GameState extends AbstractAppState{
    //We make the input mappings public and static so they are easy to find later
    public static final String PLAYER_FORWARD = "Forward_Move";
    public static final String PLAYER_BACKWARD = "Backward_Move";
    public static final String PLAYER_LEFT = "Left_Move";
    public static final String PLAYER_RIGHT = "Right_Move";
    private Spatial player;
    private Node scene;

    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        SimpleApplication application = (SimpleApplication)app;
        AssetManager am = application.getAssetManager();
        Node rootNode = application.getRootNode();
        scene = new Node("Game_Scene");
        rootNode.attachChild(scene);
        
        player = createPlayer(am);
        scene.attachChild(player);
        
        //configure user input
        InputManager input = application.getInputManager();
        input.addMapping(PLAYER_FORWARD, new KeyTrigger(KeyInput.KEY_UP));
        input.addMapping(PLAYER_BACKWARD, new KeyTrigger(KeyInput.KEY_DOWN));
        input.addMapping(PLAYER_LEFT, new KeyTrigger(KeyInput.KEY_LEFT));
        input.addMapping(PLAYER_RIGHT, new KeyTrigger(KeyInput.KEY_RIGHT));
    }
    
    ...
}

If you run the game now and start pressing the cursor buttons... nothing happens! We still need to register a listener for these mappings. Let's make GameState implement ActionListener so anything we want to do with player input can be done very easily.

The ActionListener interface has a single method we need to override, the onAction(String name, boolean isPressed, float tpf) method. When we register a listener to the key input, the onAction method gets called from ALL keybindings we register. Therefor, we need to sort through all possible inputs with if or switch statements. I prefer if statements because it is easier to assign blocking vs non blocking keybindings.

public class GameState extends AbstractAppState implements ActionListener{
    ...

    @Override
    public void initialize(AppStateManager stateManager, Application app) {

        ...
        
        //disable the default flycam
        application.getStateManager().getState(FlyCamAppState.class).setEnabled(false);

        //configure user input
        InputManager input = application.getInputManager();
        input.addMapping(PLAYER_FORWARD, new KeyTrigger(KeyInput.KEY_UP));
        input.addMapping(PLAYER_BACKWARD, new KeyTrigger(KeyInput.KEY_DOWN));
        input.addMapping(PLAYER_LEFT, new KeyTrigger(KeyInput.KEY_LEFT));
        input.addMapping(PLAYER_RIGHT, new KeyTrigger(KeyInput.KEY_RIGHT));
        //here we register GameState as a listener with the input manager and assign
        //it all the mappings we want to listen to
        input.addListener(this, PLAYER_FORWARD, PLAYER_BACKWARD, PLAYER_LEFT, PLAYER_RIGHT);
    }
    
    ...

    @Override
    public void onAction(String name, boolean isPressed, float tpf) {
        System.out.println(name+" was pressed");
        //We WANT the forward button press to block a backward button press, so we use if/else
        if(name.equals(PLAYER_FORWARD)){
            
        } else if(name.equals(PLAYER_BACKWARD)){
            
        }
        //we DON'T want the forward or backward buttons to block left and right buttons
        if(name.equals(PLAYER_LEFT)){
            
        } else if(name.equals(PLAYER_RIGHT)){
            
        }
    }
}

Now if you press play you can use the arrow keys to print the name of the binding you are currently pressing to the console. You may also notice the camera moving when you use the arrow keys, this is because SimpleApplication creates a FlyCam by default. It's easy enough to turn off by adding another line to our Initialize Method.

We have our user input registered with our input manager, now how do we get this to control our cube? The simple answer, Controls. Let's make a new package com.mrugames.unit and create a new class, Mob.java. Mobs in game design lingo are simply mobile entities, or anything that moves. That is exactly what our mob control is going to do, move whatever it is attached to at a specific speed every frame. Make our Mob class extend AbstractControl and override the 2 abstract methods controlUpdate(float tpf) and controlRender(RenderManager rm, ViewPort vp). We won't be using control render in our mob class, but it is a good place to put render specific code.

For our Mob class we want to store the maximum speed the mob can move as well as the current input direction for the mob. We will assume the input direction is a number between 0 and 1. Every frame that the input direction is greater than 0, we move the mob by it's maxSpeed*inputDirection*tpf (time per frame).

The Control class has a convenient "spatial" field which you can use to access the Spatial the control is attached to. Spatials also have a convenient "move" method which takes a Vector3f argument.

public class Mob extends AbstractControl{
    public float maxSpeed = 1f;
    public Vector2f dir = new Vector2f(0,0);

    @Override
    protected void controlUpdate(float tpf) {
        //every frame that dir is greater than 0, move in the direction of dir by
        //our max speed
        if(dir.lengthSquared() > 0){
            //spatial is a protected field inherited from AbstractControl
            spatial.move(dir.x*maxSpeed*tpf, dir.y*maxSpeed*tpf, 0);
        }
    }

    @Override
    protected void controlRender(RenderManager rm, ViewPort vp) {
        
    }
}

Now that we have our Mob control, we need to attach it to our player Spatial. We can then access our Mob control in our ActionListener to set the Mob.dir to match the players input.

public class GameState extends AbstractAppState implements ActionListener{    

    ...

    private Spatial createPlayer(AssetManager am){
        Mesh mesh = new Box(0.5f,0.5f,1f);
        Geometry geo = new Geometry("Player", mesh);
        Material mat = new Material(am, "Common/MatDefs/Misc/Unshaded.j3md");
        geo.setMaterial(mat);
        //Add a new Mob control to the player
        geo.addControl(new Mob());
        return geo;
    }    

    ...

    @Override
    public void onAction(String name, boolean isPressed, float tpf) {
        Mob playerMob = player.getControl(Mob.class);
        //We WANT the forward button press to block a backward button press, so we use if/else
        if(name.equals(PLAYER_FORWARD)){
            if(isPressed){
                //Called the frame the button was pressed down
                playerMob.dir.y =1 ;
            } else{
                //Called the frame the button was released
                playerMob.dir.y = 0;
            }
        } else if(name.equals(PLAYER_BACKWARD)){
            if(isPressed){
                playerMob.dir.y = -1;
            } else{
                playerMob.dir.y = 0;
            }
        }
        //we DON'T want the forward or backward buttons to block left and right buttons
        if(name.equals(PLAYER_LEFT)){
            if(isPressed){
                playerMob.dir.x = -1;
            } else{
                playerMob.dir.x = 0;
            }
        } else if(name.equals(PLAYER_RIGHT)){
            if(isPressed){
                playerMob.dir.x = 1;
            } else{
                playerMob.dir.x = 0;
            }
        }
    }

As you see there are some simple tricks we use to process the player input. The ifPressed variable will be true the frame that the player activates the mapping, and false on the frame that the mapping is deactivated. This makes on/off functionality easy. If you need to be notified every frame that a mapping is being activated, take a look at the AnalogListener class. We will cover the AnalogListener in more detail later.

Go ahead and press play! You'll see our little cube drift around the screen corresponding to your button presses.

Simple Arcade Game 3: Scenegraph

2018-07-02T16:45:00.000-07:00

Hello again and welcome to another jMonkey Engine tutorial! Today we are going to take a detailed look at probably the most important aspect of jMonkey Engine, it's Scenegraph.

A great overview of how jme uses it's scenegraph is available here, but I'll run a brief overview for those who want to dive right in.

The Scene in jme is made up of Spatials, mostly Nodes and Geometries. Nodes do not have any visual elements, but can have children elements. Geometries have meshes and materials and will be rendered, these are the elements you actually see! All spatials must be connected to the RootNode, which is the top most node in the scene. You can easily make complex or large scale models with many moving parts by mixing Nodes and Geometries.

The most important thing to remember: DO NOT EXTEND NODE, GEOMETRY OR SPATIAL. Instead you should store your game data seperately, in the Spatial's UserData container, or as a Control which is attached to a spatial.

UserData can be any Object and is easily written by using Spatial.setUserData(String key, Object data), and later retrieved using Spatial.getUserData(String key).

Controls are a lot like AppStates, except they only work on the spatial they are attached to. We will go over Controls in a later tutorial, but if you are interested in making your own controls now they are easily attached to a spatial using Spatial.addControl(Control control), and retrieved by using Spatial.getControl(Class<T> controlType) where T extends Control.

We are going to make a new appstate for our game, let's call it "GameState". We need to override the "initialize" method as this is where we will be modifying our scene.

public class GameState extends AbstractAppState{
    private Spatial player;
    private Node scene;

    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        SimpleApplication application = (SimpleApplication)app;
        AssetManager am = application.getAssetManager();
        Node rootNode = application.getRootNode();
        scene = new Node("Game_Scene");
        rootNode.attachChild(scene);
    }
    
}

Lets go ahead and cast the Application app to a SimpleApplication so we can access our RootNode and the AssetManager. We should also define a Spatial object that will reference the Players spatial so we can easily find it later. We also define a Node for the Scene. Create a new Node with a string argument for the node's name and attach it to the root node via the Node.attachChild() method. We will be attaching all the game objects to the game scene instead of the root node to keep them separated and easy to work with!

Now let's define a new method to create our player object. We will eventually be using a Dragon model, but for now let's simple spawn a box to represent our player. First we define a new method, createPlayer(AssetManager am). We are going to pass the assetManager from our Application object to this method to allow the use of pre-defined material definitions which really speed this process.

public class GameState extends AbstractAppState{

    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        SimpleApplication application = (SimpleApplication)app;
        AssetManager am = application.getAssetManager();
        Node rootNode = application.getRootNode();
        scene = new Node("Game_Scene");
        rootNode.attachChild(scene);

        player = createPlayer(am);
        scene.attachChild(player);
    }

    private Spatial createPlayer(AssetManager am){
        Mesh mesh = new Box(0.5f,0.5f,1f);
        Geometry geo = new Geometry("Player", mesh);
        Material mat = new Material(am, "Common/MatDefs/Misc/Unshaded.j3md");
        geo.setMaterial(mat);
        return geo;
    }
}

Spawning a model is as simple as creating a geometry, giving it a mesh and a material. Here we use the Box shape to create our mesh. With 3 floating point arguments we construct a box that extends into the x, y and z axis by the given amount. This will give us a box that is actually 1x1x2. Simply pass the mesh to the Geometry as an argument along with a String name to attach the mesh to the geometry.

Next we create the material. Here we are using a Material Definition which is how jmonkey defines what pixel and vertex shaders control the material. We are using the built-in material definition for Unshaded objects by simply defining the path to the j3md file. You can view other material definitions included in the jme3 library in the jme3-core.jar/Common/MatDefs. Call Geometry.setMaterial() and we are finished.

In the initialize method add the 2 lines player = createPlayer(am) and scene.attachChild(player).

This is enough to have our GameState spawn a player object and attach it to the GameScene node, which in turn is attached to the RootNode and will be rendered. Now we need to attach the GameState to the AppStateManager, let's do this in our MainMenu state so in the future we can have a button start the game.

Open our MainMenu appstate and add the following lines.

public class MainMenu extends AbstractAppState {
    private AppStateManager stateManager;
    private float countDown = 3f;
    private BitmapText text;

    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        super.initialize(stateManager, app);
        this.stateManager = stateManager;
        
        ...
    }
    
    @Override
    public void update(float tpf) {
        if((countDown -= tpf) <= 0){
            stateManager.detach(this);
            stateManager.attach(new GameState());
        }
    }
    
    ...
}

First we need to define 2 new fields, stateManager and countDown. The state manager is passed via the initialize() method when the AppState is attached to the AppStateManager. Go ahead and assign this via "this.stateManager = stateManager" so we can access it later.

Then in our update loop we are going to count down from 3. Once our countdown is equal to or less than 0, we will remove MainMenu from our AppStateManager and attach a new GameState. Do this by simple subtracting tpf from countDown once a frame and checking with a basic if statement. Remember, in a video game you NEVER want to use wait() as this will completely lock your thread from doing other things. Making simple timers like the one above is easy and guarantees that your other appstates have a chance to run their updates while we wait.

Now if you press Play you will see our lovely Main Menu for approximately 3 seconds before being taken to our game state, and spawning in a simple, white cube!

Universal Sound Board side project

2018-06-02T11:15:00.000-07:00

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 ;)

Simple Arcade Game 2: Intro to Appstates

2018-04-13T17:05:00.001-07:00

Welcome back to another lesson in making a simple arcade game in jMonkey Engine. last time we got the jme sdk installed and created our project. Today we will look at jMonkeys powerful appstates, input handling and a first glance at the scenegraph.

Let's open up our project and take a look at the example class that was provided.

public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }

    @Override
    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    }
}

The first part is our java main method. This is called by the jvm, and here we create our jmonkey application.

Next is the SimpleApplication method, simpleInitApp(). This is called after the application is created and has finished starting up all of jmonkey's dependencies, but before simpleUpdate and simpleRender. Here you can initialize the game state, create game objects and modify the scene graph. By default it creates a box mesh, wraps it in a geometry, assigns a blue material to the geometry and attaches the geometry to the scene graph. We'll discuss geometries and the scene graph in more detail later.

Next up is the simpleUpdate method from SimpleApplication. SimpleUpdate is called once every frame and is where you should store game logic that happens over time. Frames are called as fast as possible, and while your game is small it's very possible to see 4000+ frames called every second. The argument "tpf" (Time Per Frame) is used to provide you with the amount of time, in seconds, the previous frame took to execute. This value is what you will use to move objects smoothly and consistently.

The last method created by default is the simpleRender method. We will not be using the simpleRender method for our simple arcade game and it is safe to simply remove it for now. SimpleRender is called after the simpleUpdate method and can be used to modify how the scene is rendered through the RenderManager. It is not safe to modify the scenegraph from this method.

You may be tempted to start writing your game logic and putting it all in the nice simpleUpdate method, and you wouldn't be wrong to do so. Super small games can easily exist entirely within one class and you could get away with using your SimpleApplication for most of your game logic, but did you know there's a better way?

JMonkey provides us with a concept called "App States". An appstate is a confined version of simpleInit and simpleUpdate which can be attached to a simple application and every frame all of your appstates will be executed before calling simpleUpdate.

Why would you want to use an appstate? The answer is simple, you can seperate un related code, easily pause/unpause or remove game logic simply by attaching or removing your appstates. You can have a main menu appstate, which you disable when you start your game appstate. Your game appstate could create several additional app states to process the game state. When you press the pause button you can easily pause only the game appstate while activating a new pause menu appstate and so on. Appstates make game design easy and robust and are one of jmonkey's most powerful features. Let's go ahead and create a main menu state right now!

In the sdk right click the package that contains your Main class and select "New/Other." From there select JME3 Classes category and under File Type choose "New AppState."

Let's name our new appstate "MainMenu" and click finish. You should have a class named "MainMenu" with the following code:

public class MainMenu extends AbstractAppState {
    
    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        super.initialize(stateManager, app);
        //TODO: initialize your AppState, e.g. attach spatials to rootNode
        //this is called on the OpenGL thread after the AppState has been attached
    }
    
    @Override
    public void update(float tpf) {
        //TODO: implement behavior during runtime
    }
    
    @Override
    public void cleanup() {
        super.cleanup();
        //TODO: clean up what you initialized in the initialize method,
        //e.g. remove all spatials from rootNode
        //this is called on the OpenGL thread after the AppState has been detached
    }
}

Looks familiar doesn't it? You have an initialize method which is called before any update method the frame the appstate gets added to your application. Next is the update method, called once a frame before the SimpleApplication's update.

The last method is a new one, cleanup(). Cleanup is called before any update on the frame after an appstate has been removed from the application. This is how you can remove any objects associated with your appstate from the scenegraph.

Now lets have this appstate display something when we activate it!

Out of the box JME doesn't have the most robust built in gui library, but it does have plenty to get us started. We'll make use of the BitmapFont and BitmapText classes to display a simple label on the screen.

First let's add a private field to MainMenu to hold a reference to our BitmapText object. Then we need to load the default font file provided with jme. To load assets we'll use the Applications asset manager. BitmapFont has a method, "createLabel" that will create a jme spatial we can attach to the scene graph. To display the text we need to attach it to SimpleApplications default gui node. We'll need to cast app to accomplish this.

public class MainMenu extends AbstractAppState {
    private BitmapText text;

    @Override
    public void initialize(AppStateManager stateManager, Application app){
        //jME has a built in font which can be loaded from "Interface/Fonts/Default.fnt"
        BitmapFont font = app.getAssetManager().loadFont("Interface/Fonts/Default.fnt");
        text = font.createLabel("Hello jMonkey Engine!");
        ((SimpleApplication)app).getGuiNode().attachChild(text);
    }

This will attach our text to the origin point of the Gui Node. We'll go more in depth with the scene graph next time, for now you only need to know there are 2 scenes included with SimpleApplication, the Gui scene and the Root scene.

Let's hop back to our Main class and create an instance of our appstate. Go ahead and delete everything in simpleInitApp(), we don't want the blue cube anymore.


public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        MainMenu menu = new MainMenu();
        stateManager.attach(menu);
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }
}

Now if you hit play, you don't see anything. This is because of how jmonkey handles the gui scene. Our text is spawning at 0,0 and going DOWN, which pushes it off of our screen! not good, let's fix it! Go back to the MainMenu appstate and let's move the text.

public class MainMenu extends AbstractAppState {
    private BitmapText text;
    
    @Override
    public void initialize(AppStateManager stateManager, Application app) {
        super.initialize(stateManager, app);
        
        BitmapFont font = app.getAssetManager().loadFont("Interface/Fonts/Default.fnt");
        text = font.createLabel("Hello jMonkey Engine!");
        
        //set the text to the center of the screen
        Camera cam = app.getCamera();
        int width = cam.getWidth();
        int height = cam.getHeight();
        float x = (width/2)-(text.getLineWidth()/2);
        float y = (height/2)+(text.getLineHeight()/2);
        text.setLocalTranslation(x, y, 0);

        ((SimpleApplication)app).getGuiNode().attachChild(text);
    }
    
    @Override
    public void update(float tpf) {
        //TODO: implement behavior during runtime
    }
    
    @Override
    public void cleanup() {
        super.cleanup();
        text.removeFromParent();
    }
}

Wait, that's a lot of new code! It's ok, first we need our applications resolution, the easiest way to get this is from our camera's width and height. Next we find the center. The gui origin is the bottom left, and text grows from the top down. Lastly we need to set the translation with setLocalTranslation.

Now is also a good time to remove the text from the scenegraph in our cleanup method, this way when the appstate is closed the text will go with it!

Now try pressing play. Your message should be nicely visible in the center of the screen!

That's the basics to Appstates, you can create them, attach and detach them to add and remove game behaviors. There is also a convenient setEnabled() method you can use to pause an appstate you don't want to remove completely. We'll be making extensive use of appstates to get our simple arcade game running well!

Simple Arcade Game 1: Installing JME

2018-03-31T09:16:00.000-07:00

Welcome to part 1 of making a simple arcade game in jMonkey Engine! In this series we are going to look at making a simple top down game about herding sheep. The focus of these tutorials will be primarily on learning how to use JME to accomplish simple game mechanics and get you started on a project of your own. We'll cover topics such as app states, controls, the scene graph, transforms in 3d space, the asset pipeline and any other topics that crop up while we are finishing this simple game. Before we can dive into writing our first game, we need to get jMonkey Engine to run!

JME is a java library, and of course you will need a version of jdk found here. I'll assume you have at least jdk8 installed for these tutorials.

The simplest way to work with jMonkey Engine is to install the latest community SDK. The JME SDK is a customized version of the Netbeans IDE with some very helpful features that will make working with JME much simpler. It is possible to use your own IDE, or even a text editor and compile on your own, but for this series I will assume you are using the provided SDK and it's helpful JME integrations.

Go ahead and download the jMonkey SDK here.

If you are wondering why my screenshots look different, it's because I use the awesome "DarkMonkey" plugin available under "Tools/Plugins" You may want to look through what plugins are available and see if there are any that interest you or might make development easier.

Once you have the SDK installed you will need to create a new project. In the top left go to "File/New Project..." under Categories choose "JME3" and under Projects choose "Basic Game."

Click Next and choose a name for the project and a folder to store all the project files in. I am naming this project "SheepTut" and storing it in a folder on my secondary drive. Be sure you have access to the folder you choose as you will be adding and removing files often.

Now you have your project created, it should be visible on the left under the "Projects" tab. If for some reason you don't see the projects tab, go to "Windows/Projects" or press "CTRL-1" to open a new projects tab. I keep this docked on the left side for convenience. If you open up all of the project folders you should see something like this:

If your source packages and libraries look different, right click in a blank area in the Projects tab and select "View Java Packages As..." and select "Reduced Tree."

So what are we looking at here? Well first is the Project Assets folder. This folder will be packaged inside the .jar file when you build the project and is where you will be storing all of your game assets, 3d models, textures, sound files, etc. It comes pre-filled with some sub-folders which are all empty by default. This is fine, we'll be adding our own files soon enough.

Next is the Source Packages. These are all of your Java class files and where you will actually be building your game. Right now it has 1 package called "mygame" with 1 Main class. Feel free to create a new package if you would prefer something more descriptive. Java convention states packages should be named after their "reverse internet domain name" so I'll go ahead and create a new package called "com.mrugames." and click and drag the Main class into my new package.

When clicking and dragging a java class it will ask if you wish to refactor, click yes to let the SDK handle formatting the class to it's new package.

The next thing listed in your project tab is the Libraries. This contains all the jMonkey Engine libraries you will need to run your game, as well as your JDK libraries for the version of Java that is installed. If you wish to change the JDK simply right click on your project, go to properties and under Source/Binary file select the JDK you wish to use. If you do not see the version of JDK you were hoping to use and it is installed on your system, then go to Tools/Java Platforms, Add Platform and follow the wizard to locate your JDK.

The last folder listed is called "Important Files." This contains your build file which you will probably not need to edit. The SDK should be able to modify this file for you as needed through project properties. If you do find yourself needing to modify the build script, this is the quickest way to find it.

Now that you are familiar with the jMonkey project, let's open the Main class that was generated an run it! Simply double click Main.java and you will be greeted with a class that extends Simple Application and has 4 methods, a main(), a simpleInitApp(), a simpleUpdate() and a simpleRender(). You should be able to press Run Project(F6) and be greeted by the jMonkeyEngine splash screen!

Press continue to finally run your first jMonkey Engine game:

Congrats! You managed to get jMonkey Engine SDK to run and created your first project! If you had any difficulties getting this far feel free to leave a comment either here, on this blog or at the jMonkey Engine forum where either myself or someone from the super helpful community can point you in the right direction.

Next time we will take a closer look at the Simple Application class, the BaseAppState class and how jMonkey handles frame updates!

The need for sheep

2018-02-28T19:46:00.002-08:00

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

2018-02-13T12:25:00.004-08:00

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.

One Game Mechanic Jam 3

2018-02-12T11:20:00.001-08:00

This weekend I took part in a little game jam held on Itch.IO by Game Dev's Quest. I kept the game super small this time with the focus only on interactive buttons and dials on pre set machines. Here's my submission.

LemurUI really helped a lot this time around. It's strong integration with jMonkey engine allows the ui to be implemented in any way you can imagine within jMonkey's scene graph. This means all those 3d buttons, the lever and dials are all gui element "MouseEventControls" and mouse event listeners. The ability to put this control on any spatial in the scene graph is awesome and something I will definitely make use of in the future!

I also used ZayEs entity/component system again. This is simply my favorite addition to jMonkey and really makes storing data with game objects a breeze. Each station added or changed components based on user input. The bottle spatials were also handled by the components using the component filter system which is something I haven't tried before. It's probably not the cleanest way to do things but it really allowed for rapid prototyping and I always new exactly what code was responsible for different things.

I had fun in this jam and look forward to the next one ;)

Project Gothic

2018-02-04T21:53:00.001-08:00

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!

Playing with Unity

2018-01-19T02:33:00.001-08:00

I love jMonkey engine dearly, but it would be irresponsible to not look around at other tool sets.

I decided to take a look around at other engines since jMonkey doesn't have a very large range of deployment options. I like java a lot and I will continue to make java games in jMonkey, but I've fought with the Android deployment non stop for over a year and am just not getting it to sort of function. I would also like to support some play in browser capabilities which jMonkey lost when browsers quit supporting java applets.

I've used Unity in the past, it's actually what I first started learning to program on. I'm having to re-teach myself to work with the very loose way which unity runs. This is making the transition especially annoying since my current project must support networked multiplayer.

I'll try to have another blog post with some screenshots of any progress here shortly.

In other news, I'm learning jMonkey joystick support, and you'll likely see the effects of that soon as well ;)

Also, I set up streaming/recording software. I'm probably not gonna do live streams but it has made capturing video alot simpler. I'll work on getting some video previews for my games on itch!

New Year

2018-01-07T21:49:00.002-08:00

Hello everyone, I hope you had a wonderful New Years Eve/Day!

Here's what I've been up to:

New enemy added to Dungeon Hoard, the Kob! It's a flying enemy that travels twice as fast as a normal gob. Once it picks up a coin it gets weighed down and moves at half the speed of a normal gob. Plus, it's cute!

Reindeer Rearing has it's early release. I've put in some more work into assets, mainly adding backgrounds to some of the mini games and trying to flesh out the over-all look of the game. With the holiday season over and the Jam wrapped up this project will definitely slow down. I still have goals with it, but updates will be further apart now.

In it's place I started a new, longer term project. I am aiming for the end of the month. It's primary focus is multiplayer, which is something I've never attempted before! I already have a large amount of work synced and have had multiple clients connected across LAN and a not so good internet connection.

Looking forward to showing more progress in the coming weeks!

Reindeer Rearing early build!

2017-12-25T19:32:00.001-08:00

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.

Newest Project

2017-12-13T23:06:00.000-08:00

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!

Post Ludum Dare #40

2017-12-04T18:19:00.000-08:00

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!

Ludum Dare 40

2017-12-01T17:40:00.002-08:00

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