Tuesday, October 29, 2019

Physics are fun! Also Ludum Dare 45

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

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


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

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

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

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

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

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

Debug boxes showing the OcTree, a heightfield broken into multiple parts and a couple of box colliders
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!

Monday, September 23, 2019

Another Hold, Another New Venture

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!

Thursday, July 18, 2019

Project Ceres

My one side project kind of exploded.

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

I wish I was better at art...

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.

Monday, March 25, 2019

Alot of progress, not much to show

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!

Sunday, January 6, 2019

Ludum Dare 43

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.

Monday, December 31, 2018

Happy New Years!

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!

Sunday, November 4, 2018

Spooky Progress and More News

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!