Game Programming Snippets

Actions Must Have Consequences

2023-05-15T18:48:00.001-04:00

I've tried a number of different Android games recently. And i noticed a disturbing trend all of them simply give you actions to take that have zero consequences. All the micro transactions gatewayed games are all the same.

They were actually a type of online game that way pretty easy to make they involved lots of players all competing in a ranked challenge. The biggest problem of course for winning these games was to either gang up in large groups to trounce your enemies or pay a little or a lot to win. These style of games have transitioned into the mobile space for a long time now.

I'm talking about games like <insert-game-here>. Not only these games but also games like idle apocalypse, marvel snap, and others. It could be described as soulless. Because the big problem is that when you take an action in the game you don't have any consequences. It's impossible to take a bad action almost. Since the design is to keep you playing every day. And when you do loose something I'm these games it usually comes as a waste of money if you've sunken anything into them.

They are being very aptly compared to gambling games. Or casino games where by your only actual action is pressing a button. And any kind of 'fun' is simply watching an animation. And your only goal is to find all the animations in the game. They are very devoid of meaning. And a huge part of this is driven by the similarity of mechanics that all these types of mobile games or Farmville style games have.

They are devoid of consequences which removes all meaning. For sure these games are ones without a loose condition making them as safe for players as possible. However this is just lazy designing, it's safe for the designer. if you actually put in consequences for the player and give them one chance with new game or start over then how can there be any meaning.

By the way I am fine with games that do not have a loose condition so it's

Amber Sol game release 0.5.1

2019-05-16T09:21:00.001-04:00

https://youtu.be/jfu0TT3bCx8

Here is a gameplay video of the 0.5.1 release which you can download and play for free on itch.io https://addiekinstudio.itch.io/amber-game-project

Any feedback is appreciated even if it's negative.

I hope you enjoy!

Why you should write your own tools!

2019-05-07T13:58:00.001-04:00

Tools, Tools, Tools

I am all about the tools. When I think about what a tool does for me its really about doing the heavy lifting. It's about moving mountains not simply hammering in nails. I think that helps me focus on the right features when writing the tools I need.

When making games everything about the game code is very much unique. And you really want it to be that way. You want to be able to control the whole experience. None of it should feel out of place or break the experience with the game for the player. Even the menus and screens you interact with should be fun and enjoyable. You want there to be constant feedback and everything to be themed to match your game art, setting, etc.

Aside from just the UI and menus games must have content. Plenty of content! Creating this much content is hard work and time consuming. You want the maps to be large enough, the world to feel as big as you can. You want to make the game feel new and fresh every time the player jumps into the game. The player needs to feel like there is something left to discover and that means more and more content.

Building all that content can take up a lot of time so most game developers will build tools to take the tedium or error prone pieces out of building it. As a developer you want to be able to tweak things easily everything from player stats to animation timing. Making it super easy to make these changes without compromising quality.

Having good content building and editing tools can help you take your game to new heights quickly. Tools come in all shapes sizes and for all purposes. If it's just a little tool to help tweak multiple constant values using set formulas to tools for building foliage with a custom displacement shader. They are all valuable to you and will make your game more consistent better looking and ultimately more enjoyable for your players.

Engines don't replace tools

In general engines try to be blank canvases there are some like RPG maker that are more specialized but I do not think the idea of single purpose specialized engines really has taken off. Games that offer modding support are good examples of what those types of specialized engines would be like. And either the games come with good tools to make modding much easier or the community of modders will create tools to do the job. The key thing to notice is that either way tools are needed to build/modify the content.

There are also lots of Unity 'tools' in the asset store. More so every day! They are there to help you build all kinds of different games. Some of the most popular tools are ones that take the tedious, difficult, or most time consuming tasks during game development with Unity and make them easier.

Tools are fun to make

Aside from being extremely useful for developing content. Once you've gone from tweaking text files to make new levels to editing them in a gui based map editor you made you begin to see the places you can now take your game. Instead of it taking days to design and tweak a level you can now build a level a day.

As you build the features in your game your tools also evolve, they can help balance the level details, keeping things feeling consistent and avoiding annoying bugs and time consuming tweaking of settings. Having things like random map generation tools and help give you a head start when staring at a blank canvas and you can't seem to decide on what type of level would fit next in the games progression.

Adding that next capability to a tool can help propel your game to new heights. For instance a templating tool in a map editor would help you reuse parts of other levels making it simple for you to build much more content. Creating specialized brushes that automatically apply edge smoothing or texture splatting on maps to make them feel less grid like will help you move faster.

Do not be afraid

I have seen a lot of engineers and teams shy away from building tools or combine commands they do over and over again into simple scripts. When trying to get a game done those are the things that can keep progress from being made or being so slow that development eventually gets extremely difficult as you add more things to your list that need to be done.

Even if your tool only takes a two step process and makes it one step. Every time you use it you get exponentially increasing returns and time savings. If you continue to invest in adding more commands to the single command running script the savings increase each time you run it. Same goes for editing tools, if I needed to do 500 clicks to adjust this object to get it to align properly thats time for each click. But if I had an auto-align feature even if it still required a couple of clicks like 2-3 clicks. That's still huge savings.

So it's generally very much worth it to write scripts to simplify multi-step processes when doing game development. Or really any type of software development. I like a saying that one guy I worked with liked to say, "Make the machine do the work!"

So build those tools and reap the awesome rewards, make them part of your process and they will benefit you greatly.

[Announcement] AmberSol version 0.5 released

2019-04-05T10:39:00.000-04:00

Announcing

A coupe of weeks ago I released a new version of my game Amber Sol you can download it for free at itch

It has taken a long time to get this update out. A lot of things changed in game and I am proud of the changes. The game is still not complete though. There's a lot of work still to be done.

Its getting closer to my vision but there are some interesting decisions to make. Progress has been slow, I don't think I really ever appreciated all the effort that goes into the small details in game development.

Sometimes the smallest thing can be very difficult or time consuming to get right. But I keep moving forward and have fun adding each and every part of the game.

AmberSol Development Video 08 03 2018

2018-08-03T17:07:00.001-04:00

The next release will include loads of fixes for various parts of the game. Just smoothing out the gameplay and interface a bit. The update will also include working shields that can be turned on or off. This update includes ship designs being saved between game plays.

You can download and play the latest version for free on itch.io https://addiekinstudio.itch.io/amber-game-project

AmberSol Dev Vid 07 11 2018

2018-07-11T14:42:00.001-04:00

And development keeps pushing along. In this new demo release you can customize your own ships while wiping out all the alien squads on the orbiting planet.

Pleased to say progress is good, but there is a lot more to do for sure.

Starting a studio and making games...

2018-06-09T18:56:00.001-04:00

Anor Studios is started

You can see my games and play them on the Anor Studios Itch Page. Currently have been working on a small 2D arcade style shooter called Amber Sol you can play the demo with the itch client. Here the latest dev video.

Keep it simple...

I am trying to keep it as simple as possible and focus on polishing the design. Keeping it fun is a definite challenge.

After years of practicing and making so many different variations of game framework codes I have finally been able to put my fingers on what makes a game feel good.

I was not able to do it alone. Here were a couple of videos that really solidified things in my mind on what makes a game feel good. It also happens to be the kinds of things that really really enjoyed about game programming.

You definitely need the juice.

Here is another that I thought presented some good techniques.

Two videos worth watching. I was so excited after watching those two that I stayed up almost all night doing things I completely ignored to my then simple 2D space game.

It was incredibly satisfying, fun, and the biggest thing was it was easy. After all these years I missed something so obvious, the fun. It's of course in the explosions and the things going on on the screen.

So come along for the ride...

I don't plan on stopping any time soon so if you have followed me at all please keep doing so. I know I don't get the highest points for engagement. That really has never been my thing, mostly code has been it. But with itch I am really trying hard to get into marketing, building a community and being involved.

Call for help!

So if you can appreciate someone who really just takes a long time to "get with it" and want to help them out, please give me a shout out!

There is nothing like the motivation of knowing that what you do has an impact!

Thanks for reading and understanding!

Too many projects syndrome

2018-06-04T14:21:00.001-04:00

The syndrome

As I sat down to write this I was trying to figure out what I should work on today. I started by going to my latest game project. An Android game using Love2D which are Lua bindings for one of my favorite libraries SDL. I had always enjoyed development using SDL in C/C++ and so found development in Lua to be similarly enjoyable. Alas my current projects graphics are all pixel art. For which I use a tool I had built for myself. Writing your own tools during game development is not unheard of at all. I believe its kind of a necessity. Creating your own tools in game development gives you a lot of advantages and huge time savers. If your favorite image editor doesn't give you the fine grain control your looking for or convert to specific formats or provide a way to, um say bake in additional information into your images well you need to write a script or code something to do it for you. And even though I initially created the editor many years ago it's still missing lots of features and something of the things about it are limiting. I have been meaning to open source it but I just haven't cleaned up the project enough yet. And there in lies the rub.

So whats 'the problem'...

Well I started thinking about all the other projects I have that I have ideas to enhance. I need to port a UI library I created in lua to java so that I can use it in my image editor, and java based games. I have a jogl based game that I want to convert to lwjgl. I have 3 old 2D map editors written in Java that could use some tlc. I have a code editor project, an os project, a programming language project. And of course not to mention the 12+ shelved game projects that got started worked to a point and abandoned.

For about a decade I have suffered from not having either the expertise, focus, time, or resolve to finish any game project. I have a treasure trove of projects that stemmed from what in my mind could be great games and fun projects. I would set them up and start to work on them. Ultimately getting stuck somewhere in the creative process which usually was not far into game development. So I would drop that project for another idea entirely and repeat the same.

I have created more than a few tools along the way, from an image editor that I use often to build graphics for my frantic game project building project to full game building applications. All these half baked projects has taught me a tremendous amount about myself. What it really amounts to is that all this time I have really been simply practicing and practicing. But practicing like this does not produce many useful or playable games. Nor does it help in my goal to quit my day job. It does serve a very important purpose however. And that is that I can use each of these projects as a way to avoid the feelings that lead to wanting to drop a project because I have a ton of experiences that can help me identify when I am in the practicing mindset and when I am in the productivity mindset.

In addition to learning how my personal process leads to failed projects. I have also vetted to various degrees a large number of game ideas. These ideas can be extremely useful. I still look back at some of the game ideas for projects in my collection. When I look at those projects I had a vision of the game I was trying to make. A lot of those games do not exist in the set of games available for me to play, leaving me with the same desire to bring those games to life.

LWJGL 3: Voxel Game Update (Adding blocks)

2017-09-27T22:29:00.000-04:00

Well just a small update to report. I was able to get block placement working it works quiet well. It is obvious that there needs to be a small type of delay between each block being placed. Because they are placed really really fast.

The rebuilding of the vertex and texture buffers is also very quick which I am extremely happily surprised by the rebuilding happens in only a couple hundred milliseconds. Its enough for perhaps a slight jitter if done too much to fast but I will not be creating vertex and texture buffers to do animated effects. So for my purposes it does not appear that I will need to do any background jobs for rebuilding and swapping the rendering.

Although that is something that I would like to experiment with cause I'm a sucker for making things run as-fast-a-possible.

Now on to jumping and some world collisions stuff...and may be some moss growing :-D I'm excited (you should be scared)

LWJGL 3: Voxel Game Update (Removing blocks)

2017-09-15T21:36:00.005-04:00

Building a game is tough work. There are so many things that need to be put in-place. Each time I work on a game project, I always get a little closer to having something more closely resembling a game. So I feel like I'm on the right track. Got a good idea for something I want to play. I've been building many of the pieces of this game throughout the years.

So the way the project started most of the code was like in a single class and as that approached a point of tough to manage I split it up, modularizing it and picking some of the best design I could. Only time will tell if that pays off or not.

I also spent some time cleaning up a ton of clutter left around from various points of experimentation and rework. As well as demo and other types of codes that had been used to debug the opengl learning I was redoing over the years. It's been a literal on and off with OpenGL and OpenGLES. I used to do a lot of DirectX work many years ago did some XNA stuff for a little while too back when I was using Windows. These days are pretty much spent with Linux and not really any thought of turning back.

So, I added sounds and light levels to the combined block texture. I separated out the PlayerController class, built up a World class that is handling all the blocks. Currently working on a Parcel (i.e. chunk, partition) system to allow for a larger number of sections of the world to be generated on the fly. Things are working out well so far. Their building up nicely, got a couple of bugs to fix as is normal. Currently focusing on some movement code, adding gravity and stuff with simple collisions, jumping etc.

Oh I also added ray picking and removing of blocks. It happens instantaneously and since there isn't an inventory or item system yet, there are no tool requirements. I will have to blog about the picking at some point. It works quiet well and is exceptional at using all the GPU memory available since I have not added code to clean up old vertex and texture buffers that are left behind. Just add that to the list of things I need to do.

This time around I am trying to work off of a list of items, a todo list/backlog. I just keep it in a simple document and X off things when their finished no dates or targets yet but maybe I'll add something like that. I mean I would probably just want a number of days since it's been modified with the goal being to keep that number low. I think I'll add a simple one item inventory with a tool requirement for breaking blocks.

Some current screenshots with a few missing blocks, the sides are not really well defined because another backlog item is being able to change the light level for each side. The textures need a lot of work their just placeholders for now until it becomes a playable game and then they will need to change.

Ttfn...

LWJGL 3: Texture Coords and Picking

2017-08-21T22:21:00.001-04:00

So instead of catching up on facebook and looking for nice videos and photographs of the 2017 solar eclipse, I decided to do an update on what I have been working on.

Ray Cube Intersection...Picking

It works but it needs a bit of debugging. It doesn't always work when I think it should, may be it has something to do with the direction of the ray or the way the ray is used in the algorithm.

But as you can see I checkered test cubes with left, right, top, bottom, front, back images which are generated on the fly as test BufferedImage's and then added to a single final texture which is generated for all blocktypes and their respective side images that are specified in a single json file and referenced by name in the code.

There are lots of optimizations to made later down the road that will improve performance dramatically but already a good number of blocks can be displayed on pretty old hardware so it shouldn't be a problem to begin building the gameplay out and experimenting with different mechanics.

Also notice I added the cross-hairs. That is coming from a font texture that is procedurally generated using the Graphics2D object into a BufferedImage and then converted to a Texture. So atm just building some very basic capabilities into the code that will help to build the overall pieces of the game. There is a lot of stuff to get done though and its no small task.

The Glorious Test Cube

Inside the test cube atm...no lighting of textures yet.

It was much easier to tell the issues with the faces and texture coordinates once I had these helpful textures generated.

Also generating them using code was much easier than generating them with an image editing program. I didn't have to worry about them being misaligned or a little bit off, not that they need to look uniform but it was just easier to create and algorithm that loops through each element of an array of strings a add the Textures to the TextureManager than it would have been to Open -> Edit (drawing drawing drawing) -> Save -> Open -> Edit (...) -> Save and then name the files put them on the class path. Ugh but I guess that is why I am a programmer.

Ah the simplicity of being a cube, what a life...

The other blocks are test grass blocks with different textures for the top, and bottom, and another texture for the left, right, front, back. I do not have a block editor just yet but adding new blocks is simple enough, create the textures and add the new block to the json file. It's not entirely decided how I will do world generation but it will be epic. Nah amazing, ok it's going to be really fun if any thing.

So far this has been a lot of fun to create and see the different things come together and hopefully even though it is seeming a bit like Minecraft the end result will be its own unique experience.

I had tried to do these sort of things with a engine like Unity and contemplated doing it in something like Unreal Engine. But both of those engines would have made the procedural texture generation and cube lighting a nightmare. Especially with attempting to control the way those engines utilize buffer objects and other aspects of the GPU. Though having most of these types of things done for you already can save a lot of time obviously. Still I believe the end result ends up suffering from performance and smoothness issues unless you really cater to the types of pipelines those engines were made to do well. But it also means an incredible amount of work for me to do. But like I said I'm having fun so as long as thats happening things are good. This isn't like my day job or anything so it's a good off the clock activity to help keep my programming skills sharp and exercise coding I do not get the opportunity to do with my day job.

LWJGL 3: Texture to GPU and back

2017-08-11T22:26:00.000-04:00

Time Flies...

It's supposed to end with "when you're having fun" but that and a lot of other cliche sayings have all been in question lately. For one thing who ever said that "slept like a baby" was actually supposed to be mean waking up every two hours to feed and then fussing because you do not want to close your eyes. And since I'm a programmer I have fun when I am getting things done and there is time left over in the day. Not when I only get to sit down and do things for five minutes right before bed. And then you look down at the date on your computer and see that more than a month has gone by since your last post. Ridiculous!

What was accomplished?

So there is some small bit of progress... The hard part of actually doing things the way I wanted to do them... see I wanted to combine a bunch of textures as texture classes after they had been converted from BufferedImages and their contents transferred to the GPU. But how to do that was not entirely straight forward, or so I thought.

See the BufferedImages were being loaded and in order to not be bothered with hashing out different methods of copying the images to the GPU based on different ColorFormats I simply rendered the image to a new BufferedImage whose format is ARGB but in OpenGL the complimentary image format is RGBA so yeah simple one would say just use the rotate assembly instruction and we are all set. ***BUZZER SOUND*** WRONG!!!! you cannot do that in Java. Thanks a bunch Jawa.

So after fiddling and fiddling with it because I wanted to pull out all the pixels into an array instead of accessing them one by one through the BufferedImage object I present you with my silly idea of progress.

And then...

So once I got that to work properly and could stop fiddling with bits in Java which is not a fun process. I was able to generate a single texture from multiples and replace those multiples with SubTextures in the TextureManager. That all works now and that enabled me to externalize all my BlockTypes into a single json file which enables an editor that I will work on to add new blocks this is huge because editors can make adding content 10 times faster than editing a growing json file and 100 times faster and less error prone than adding new blocktypes in code.

Addendum

And here just to make this post complete is how the textures are loaded from an image in LWJGL 3.

And there you have it now on to bigger and better things. Like I also added movement in 4 directions WASD and fixed a bunch of odd things that were incorrect about displaying the textures and generated a Font texture and a number of other things but ya know other topics for another day. TTFN

Playing with LWJGL 3

2017-07-06T21:28:00.001-04:00

Recap & Update

I have been very busy lately. Got a new job, moved, had a kid, ya know the usual life stuff. I must admit blogging has never been something I have been good at. As is evident by my infrequent posting and sporadic change in directions. I have ultimately discovered that my personal projects that I talk about here, work on for a little while and then abandon are my method of learning. I am not sure whether this is indicative of us as human beings or if its just me. I can never stick with any of my "fun" side projects very long. Perhaps I have not put enough effort in or none have reached a good enough point to be released creating a sense of responsibility to continue working on it.

It is probably one of the reasons some of my more useful programs stay unreleased since I do not want to have to support them and can just use them for the purpose they were created for. For instance I have made at least 3 different tilemap makers, and a small image editor that I use often. Perhaps another reason is that most of them were made with Java Swing and those apps are not particularly fun to modify after a while or pleasing to utilize.

now on to the goodies...

LWJGL 3 and Vertex Arrays

So navigating the options available to different opengl versions is almost nightmareish. So the basics are pretty simple for working with these arrays. You gen the array glGenBuffers you bind the gen'd buffer glBindBuffer. Then you fill the buffer with your data, from using JOGL for this and switching to LWJGL I must say having only to send a FloatBuffer object to the glBufferData call is kind of nice. The included screenshot is rendered from a single vertex array with a single texture array for the 3d geometry. As you can see by the render quads though that is the texture used to render the individual blocks. Yes omg another block game, whatever man its a good way to expirement and learn so sue me if I generated a 100x10x100 block world and culled 76832 blocks that are not open to the sky or surrounded by others leaving 23168 blocks to generate a buffer of 10008576 floats.

For the geometry I am using 36 vertices per cube (108 floats) and rendering without culling (omg I know, but hey I was debugging). I am using a glsl shader with a simple projection * view * model matrix multiplication to transform the three dimensional coordinates to the camera 2D plane. Currently I am using the nice JOML library for the projection but quaternions for the camera.

Triangle Strips

Now as for the 4 quads...ooops the heading gave it away. They are rendered as triangle strips in a single vertex/texture and index buffer. In order to get them to be rendered as triangle strips I used GL_PRIMITIVE_RESTART setting the restart index glPrimitiveRestartIndex. I had to use 0xFF to set the short constant in java as well as enable the behavior using glEnable(GL_PRIMITIVE_RESTART). There are a lot of optimizations to be made here.

Next I want to get up a decent FPS counter to track the effectiveness of the optimizations. Also put in a number of performance tracking logs.

Thats all for now...

Green Algae: Dev Update pathfinding

2016-09-18T10:39:00.002-04:00

Finding the way

So just implemented a brute-force pathfinding method implementing a basic Flood-Fill (Breadth first search) algorithm. It's wasteful but effective. I plan to improve the pathfinding method to a more practical implementation for use in other areas. It's enough to get started integrating it more abstractly into the basic game world for easier use when characters want to move around. It was pretty fun seeing it work.

Other work

On top of the pathfinding, I reworked the map generation which is hopefully more efficient, reliable, and is making more evenly distributed islands. If you noticed from previous screenshots the islands were all generating on an angle moving to the top-left while generating. Was due to the infamous off by one error, though I was kind of digging the realistic nature of some of the island strips. Perhaps that could be a useful generation permutation in the future.

Where's the build?

I wish I had something playable that you could check out but it's just too rough right now. And I do not have any process for putting together a public release yet. But things are moving along getting some basic AI and decision making system set up is probably my number one priority. Once I have a solid extendable task based system for controlling units assignments it will open the gates to adding all kinds of content. Right now it's just reworking and molding the current code into a more effective structure.

Suggestions welcome

By the way the game concept is very much flexible at this point in time. Not much at all has been solidified. That being said, I am completely open to suggestions or ideas that you may have to help guide some of the gameplay.

Comments to any update post or to the Project Page are strongly encouraged.

P.S. You can find updates to the Roadmap on the project page. I'll get a description of the game there too since there is no dev version yet.

ttfn

Green Algae: Frontiersman Development Update

2016-09-14T18:31:00.001-04:00

Yay! We struck tree!

Things are moving a little bit after fixing up a number of things. Rearranging stuff implementing some additional stuff as well. Like being able to select objects on the map and get details about them.

Trees can be selected and designated to be chopped down. Currently only a single object selection is available. I'll put drag and drop selection on the roadmap of course.

So here's where things stand.

Terrain

~~finish tile-type transitions~~
add dirt (with transitions)
add gravel (with transitions)
add random stones

Player controls

~~map movement controls~~
~~object-selection and displayed details~~ new
designating actions for map items

~~chop/down tree~~
stockpile area designation

AI Simulated Character

~~add gender and age~~ new
add basic decision-based model
add crappy path-finding method
add hunger, starvation, and death
add actions and event, thoughts and memory

Save/Load

Test, test, test

Build Scripts and release checklist

Green Algae: Game Development Update

2016-09-11T23:12:00.000-04:00

Update: Tile transitions

Finally got transitions built between grass sand and water. I still think there are a few edge cases that need to be handled like one water tile surrounded by sand and other combinations of the same.

My first approach which quickly became a painstakingly brutal experience reloading map after map. Note to self create a small map test area. Was to have different tile types for each transition tile for instance a SAND_WATER_TOP_LEFT this became problematic when working with a testing tile types in the game logic. For instance player collision with water, and placing bridges. Not to mention that determining which transition to place was also difficult things kept breaking as more and more tile types were added. So I decided to use a slightly more subtle approach.

While rendering each tile the adjacent tiles are tested to determine which transition is to be used. This method short-circuits only testing each north, south, east, west, northeast, southeast, northwest, southwest, position in turn if any fail the test exits. These are mapped to the corresponding image for the transition changing which image is rendered.

Focus on gameplay

For the moment I think I need to focus on getting as many gameplay elements working as possible to actually have something that can be played like a game. Currently there isn't any real objective or goal so there really isn't a whole lot to do. Of course removing the movement controls from the player kind of eliminated an entire aspect of the game. Things are kind of slow going as I do not spend an incredible amount of time working on this project. I probably have too many at the moment which is why I do not have more updates. But if I can kind of get some semblance of a game going we might be talking more frequent updates.

Other mentions

Its subtle but noticed I have changed the title too. The gameplay is starting to develop a little more clearly in my head. Time will tell where it goes. But the name of the game is now 'Frontiersman' the game idea might be a bit obvious. You are controlling a family starting out in a new world trying to survive and discovering the dangers that lurk in your new world.

Roadmap updates

Terrain

~~finish tile-type transitions~~
add dirt (with transitions)
add gravel (with transitions)
add random stones

Player controls new

map movement controls new
designating actions for map items new

chop/down tree new

AI Simulated Character

add basic decision-based model
add crappy path-finding method
add hunger, starvation, and death
add actions and event, thoughts and memory

Save/Load

Test, test, test

Build Scripts and release checklist

Green Algae: Game Development Update

2016-08-29T14:32:00.001-04:00

Greetings

It's been a while since I have posted updates on one of my old game projects. It has been slow going. I was particularly blocked on building a save file format. Finally decided to implement saving and loading via the remarkably light minimal-json library. I also had to take the time to convert the project to gradle so it was easy to pull in the libraries auto-magically. Also realigned the trees into the each particular tile and adjusted the number of logs spawned after chopping one down although the math is not working very well. I get either 2 logs or no logs for smaller trees. That needs some tweaking.

Gameplay

I still have not decided what style of game It will be. I've only been really working on small insignificant details at this point. As you can see an incomplete update of smooth transitions between tile types which should be finished soon enough. I've been toying with the idea of moving more towards a Dwarf Fortress / RimWorld type of game. My map generation algorithm will need to become more sophisticated over time. I have been working on a few ideas to create a more versatile and generic system so that different types of terrain are possible. But first getting the terrain transitions to be generic and easily definable is probably necessary.

I have removed a little annoying gameplay element where by chopping down a tree required that you continuously collided with the tree by moving into it. This sort of mechanism was a bit confusing when not knowing you had to collide with it. Adjustments to log pickup will probably benefit from not having to be moving while colliding with the log hit box. Although these types of adjustments are secondary to figuring out which direction the game will take.

I am definitely open to ideas and/or suggestions even cries for a released version for anyone who still reads this blog. I've only really been working on the code for years now mostly a bit of a pass-time effort slowly but steadily trying to move it forward to a playable version.

Apparently the bridge building mechanic was broken with a few updates to map and world objects as part of building a save/load feature. But that could probably be fixed, though a quick mechanic test world would be cool since the map generation is not that quick to run, especially on my old laptop since it's only a dual-core.

But please feel free to leave your comments concerns etc. It'd definitely be nice to know if anyone is interested since it's really just a personal pet project at this point. Though I feel pet projects are where some of the most in-depth games come from.

Short-Term Roadmap

Terrain

finish tile-type transitions
add dirt
add gravel
add random stones

AI Simulated Character

add basic decision-based model
add crappy path-finding method
add hunger, starvation, and death
add actions and event, thoughts and memory

Save/Load

Test, test, test

Build Scripts and release checklist

That should be more than enough to focus on in the short-term. It might take a bit of doing to refactor the code to convert from a character based movement scheme to one of an overview and direction based one. We'll just take it step by step and see what happens.

Another idea I've been toying with is cutting the size of the tiles in half going from 32x32 pixels to 16x16 still keeping the base image resolution at 32x32 but simply scaling to half the size. Which might significantly break things but would be flexible after fixing.

Anyway that's it for this update. Just needed to write down some thoughts and try to create some semblance of interest as well as a place to hold myself accountable for plans.

Game optimization by space partitioning: Part II

2016-05-24T08:00:00.000-04:00

Reduce rendering calls

Note that last time we reduced the number of objects returned in collision detection using a bin-ing strategy from 10020 to just around 31 objects. But then after profiling the application we noticed that the most time was now being spent in the rendering loop. Upon examination both loops were largely inefficient they were in fact both performing loops on 10020+ objects each call which was happening at both 33fps and the updates were as often as possible.

Since the strategy existed already it was easy enough to figure out how a bounding box of objects to grab each time we render the screen and only render those objects since they are the only ones that are visible.

One problem that arose from this was the fact that the way the views work the actual objects on screen were significantly scaled.

Handle scaling

Screen size was 640x480 but each tile is 8x8 and is scaled. Blown up by a factor of 5. So grabbing a 640x480 section of from the SpacePartitionStrategy resulted in returning over 5000 objects.

If we take the inverse scale factor for the x and y directions which where 1/5 since each x and y was multiplied by 5. Then we get a grid size of 128x96 so instead of about 80*60 (4800) objects we now are only rendering 16*12 or 192 objects approximately. Of course it comes out to more like 200 or so objects based on bin boundaries and that will fluctuate when we add in smooth scrolling on maps.

The savings are incredible and give many many more benefits for future development.

Check out the commits

You can check out the diffs of the four commits created for these two posts.

Abstract partitioning scheme 32994afbc7d8bf2c34f4e3246473acb9eace8d7f

Space partitioning that does not work 4e09bed3aff2f03856ff282ec4c6e1d91ca6ed58

Fix integer bin partition strategy e62a1760dd9c59d6d8619b88f03a24f573c23e37

Reduce Rendering using Partitioning fb896ef2098972b6007bb1cb0b03d74e14f93ce6

Game optimization by space partitioning

2016-05-20T22:37:00.000-04:00

But first, a recap of LD#35

I participated in the last ludumdare competition. I love to participate in the competitions, they are an incredible challenge which forces me to focus and learn about how unprepared I am. Also how few public code I've actually released. Most of my entries I have started from scratch and each time I get a little bit farther than I did before, but still way behind where I need to be in order to actually make a game during the competition.

I tend to dive into writing a lot of boilerplate code that would already be written for me in an engine though I've never really found an engine I like. Though I am contemplating going back to SDL one of the few graphics libraries that actually provided all the necessary drudge work to write a game on top of. Otherwise I will stick with writing a game for ludumdare with the code from my last entry.

Pup8Bit an engine

So yeah I did not create a game I only created an engine and not the perfect one at that. It had a couple of bugs. Including no transparent images which was a huge time sync during the competition. Silly Java. Besides needing to make transparent images work, there was a huge issue with collision detection where the character movement code actually was checking it's current position instead of checking the next position for validity. But now that is working correctly.

Did some refactoring of the main Game object to off load all event handlers, updaters and rendering queues to game state objects.

Oh and this may be a little odd and out there but during the competition I added javascript support for scripting. Then quickly added coffeescript support after that. This uses Javas "Nashorn" javascript engine. And grabbed the javascript distribution from the github repo.

Long story short with that, I intend to use the coffeescript files in a resources/states directory as init scripts for game states so all your objects can be added to the game state via coffeescript. This will allow me to reload the game states and watch the file system for changes to the scripts automatically restarting the state if the script changes. There is already a game initialization script that is loaded right now and does all the keyboard input handling for the current test game.

Ok, the problem - Performance Profiling

So the project is moving along, I have already resolved a couple of major performance bottlenecks with the code, as in somebody (me) was generating new transformation matricies in GameView everytime an object was rendered. Obviously this caused some major gc issues. But that has been resolved storing the transformations efficiently. But there are still occasional pauses when moving about the screen. Using jvisualvm helped catch the last performance issue so lets see if it helps in this circumstance.

So most of the time is being spent in the GamePosition.isClose method. Though there really isn't much to optimize there which is, maybe in getBounds call which does instantiate a new bounding box when there isn't one already but that should not take up too much time after the first call.

Heres the code for isClose.

public boolean isClose(Renderable r) {
return distSq(r.getPosition()) < (r.getBounds().getRadiusSq() * 10d);
}
public double distSq(GamePosition update) {
double dx = (getX() - update.getX());
double dy = (getY() - update.getY());
return dx * dx + dy * dy;
}

Really not much we can do about optimizing the calculations like my previous post indicated through experimentation. So really we need to go a step above that to the either the GameState.isClose or the GameState.neighbors method.

isClose just purely asks an individual position if a renderable object is close to it

private boolean isClose(Renderable r, GamePosition update) {
return update.isClose(r);
}

So nothing we can do to optimize that except eliminate the function call. Definitely not our concerning code.

And then here we have it. Where all of our time is being spent.

public Renderable[] neighbors(GenericGameObject go, GamePosition update) {
Set nearbys = new HashSet(); for (Set rSet : byLayer.values()) { for (Renderable r : rSet) {
if (isClose(r, go.getPosition()) && r != go) {
nearbys.add(r);
}
}
}
return nearbys.toArray(new Renderable[nearbys.size()]);
}

So pretty ugly here we are going through each layer and checking every renderable object to see if its close to the position we care about. Oh and all the while doing a bunch of memory allocations in to boot.

What we need is to reduce the overall number of checks. Yes we could pass back a reference to the hashset or store a field for the hashset and reuse that clearing it every update cycle etc. Or some such non-sense but as long as the number of items that we are iterating over is small there isn't really anything wrong with this code. So we shouldn't try to do crazy abnormal optimizations in order to eliminate the memory allocation. I think our biggest way to identify why this is a problem set of code is to output how many renderables get iterated over in this check.

So I added in some code to found how many Renderables in the inner loop were called.

And got a whole bunch of the following

Iterating over 10020
Iterating over 10020
Iterating over 10020
Iterating over 10020

This is for a small map from Tiled. So the app then performs fairly well for doing all those iterations every update on top of rendering at 33fps. But we are kind of wasting vast amounts of cycles here.

We need those extra cycles for doing input handling, AI logic, handling particle movement, etc, etc. So lets get them back shall we.

Ideas...anyone...anyone...Bueller!!!!

Ok so how about we drop the byLayers and just have a separate collection for all 10020 objects. Then what if instead of just one collection how about we use small collections of objects that are close together position wise. I mean this is mostly a filtering out unlikely candidates to get to a small number of objects that significantly reduces the impact of the loops.

A lot of people like to suggest quad trees or other data structures. I on the other hand like to use a grid based partitioning scheme where lookup time is constant time and aggregation is O(n) where n is the number of objects in the area of space we are grabbing. Though on the flip side a quad tree would give you O(log n) lookup time where n is the number nodes in the quad tree you have to traverse but then there is no aggregation time if each node has a list of objects in that section of the tree. Otherwise you have to continue traversing and still build a collection. I might eventually implement a combined method using bins of a certain size but each bin is a quad tree and the quad tree has nodes that contain the entire list of objects in that space. Removal time might be a problem though so might need to keep non-static objects out of it.

Defining the space partitions

We will say out space partitions are 4 tiles wide by 4 tiles high. Can go in any direction and the spacial grid starts at 0,0 and goes to MAX_INTEGER/2, MAX_INTEGER/2 only positive values. We want to be able to add renderable objects to the partition strategy. And get all objects within any bounds, regardless of layer. We want to allow for negative positioned renderable objects so we'll put renderables centered at MAX_INTEGER/4, MAX_INTEGER/4 in our grid system. We will also want our code to handle any bin size. So we can optimize for our bins. Obviously with a quad tree system our bins would only be allowed to contain a maximum number of elements thereby helping make iterations and performance more constant. With bins though the bins can have any number of objects in them so it would be based solely on how many objects occupy that space. Good for top-down rpgs where the maps are pretty static and there are not going to get very busy in one section of the maps. RTS' might benefit from quad tree with an implementation that reduces insertion time an keep back-references to the node an objects in for updating purposes.

Game types to use with bins

Turn-based Strategy
Top-down RPG
Simulation Games
2D Shooters are ok
Platformer

I think all of the above should perform fine with binning as a space partition strategy.

Ok now it's time for....

Math

This ends up being our bin calculation.
private int getBin(int x, int y) {
return BIN_OFFSET + (y * BIN_COLUMNS + x);

}
We calculate the bin by taking a base number BIN_OFFSET adding the number of elements for the beginning of the row in the grid we are currently in so y * BIN_COLUMNS where columns are the number of columns in our grid. I actually made the size of the bin grid just the square root of the BIN_OFFSET

// just make the number of possible bins really large
private static final int BIN_OFFSET = Integer.MAX_VALUE / 4;
private static final int BIN_COLUMNS = (int) Math.sqrt(BIN_OFFSET);

This is still pretty large for game maps. It's 23170 elements.

Benefits of Space Partitioning

So here we go now what are the benefits of this strategy. Before we were iterating over "Iterating over 10020" each update loop

Now we are

Iterating over 31

So wow we dropped 9989 iterations.

Check Profiling

Now lets check the profiling to see if there is anything else we can optimize.

Looks like a lot of time is now spent in rendering. And that reminds me that we were looking at only the collision detection code and not the rendering code due to the most significant time user.

We could easily now use the abstract SpacePartitionStrategy and the methods on it to reduce the number of rendering calls the application is making every render which is now the most significant path.

I will let you know those benefits next time.

Quick distance checking!

2016-05-15T22:08:00.000-04:00

Recap

A while ago (ah hem 8 years ago) I made a post about how to implement basic bounding box coliision detection. I thought I would make a post about how to use a little short-cut method to determine if two objects are nearby each other.

The Problem

If we have a world full of objects, which are anything from the trees, and grass to the little particles racing around the screen we do not want to needlessly check every object with every other object if we do not have to. For instance, an object on the left side of the screen could not possibly collide with an object on the right side of the screen.

You want to eliminate as many of these expensive mathematical calculations as possible. Or perhaps you just want to see if two objects will affect each other anytime soon. There are a couple things we need to know about the objects in order to quickly make the determination if we want to check them. We might be currently checking collisions on objects that will never touch each other. Each time we can eliminate a future check it is can save us from wasting a check. Although not as big of a problem with modern day graphics if you use the GPU for rendering. Still it will help update cycles which that we run on the CPU and anything that is still prone to bottlenecks.

There may also be other areas where you want to quickly find all objects close or nearby each other. I plan to cover some partitioning strategies in the future that will help eliminate massive amounts of loops from being necessary.

The Math

We want to determine if two objects are close to each other. We need to at least have a radius around the objects in order to calculate whether or not they are within another objects radius. So we use the distance between the two objects which is calculated as

// SquareRootCalculator
double d = Math.sqrt( Math.pow(object1.x - object2.x, 2) + Math.pow(object1.y - object2.y,2));

We can improve the speed of this a little bit by short-cutting the math and applying some variables.

// SingleDiffCalculator
double diffX = object1.x - object2.x;
double diffY = object1.y - object2.y;
double distSquared = diffX * diffX + diffY * diffY;

No Math routine calls and eliminate the need to calculate difference twice. Although the compiler and JIT may not use a register for diffX and diffY they may instead decide to use the stack which is less optimal but probably negligent difference in performance. You can expand it out to be a long equation.

// DirectFromObjectsCalculator
double distSquared = (object1.x - object2.x) * (object1.x - object2.x) + (object1.y - object2.y) * (object1.y - object2.y);

And because I like to take things farther than they need to be here accessing the x and y variables may not be efficient enough since the objects were probably allocated on the heap and may not be in cpu cache lets force them to be put on the stack which is probably in cache still.

// DirectFromStackCalculator
double ox1 = object1.x;
double oy1 = object1.y;
double ox2 = object2.x;
double oy2 = object2.y;
double distSquared = (ox1-ox2) * (ox1-ox2) + (oy1-oy2) * (oy1-oy2);

Because I like to be thorough lets see if that matters at all lets put them into a utility class and use a Unit Test and get some output. And lets do it in an object oriented way.

Ok so there was not much of a difference or enough to be noticable between methods.

283 ms for 10000000 using DirectFromObjectsCalculator
263 ms for 10000000 using DirectFromStackCalculator
283 ms for 10000000 using SingleDiffCalculator
268 ms for 10000000 using MathCalculator
304 ms for 10000000 using SquareRootCalculator

Another run:

336 ms for 12000000 using DirectFromObjectsCalculator
347 ms for 12000000 using DirectFromStackCalculator
391 ms for 12000000 using SingleDiffCalculator
394 ms for 12000000 using MathCalculator
409 ms for 12000000 using SquareRootCalculator

These results did not change much on repeated runs and varied a bit between winners the only obvious looser was the SquareRootCalculator obviously.

So no need to go drastically changing your coding style use variables if you want to clean things up. Doing temporary calculations like the SingleDiffCalculator.

If you would like to fiddle with the code then you can find it here.

The Check

So the final piece which I should have mentioned before going into all that testing above, is the comparison of against the radius.

The calculation returns the squared distance so we need to see if the square of the distance from the objects centers is less than the square of the sum of the radii.

Something like

double radiusSquared = Math.pow(object1.radius + object2.radius, 2);
if(distSquared < radiusSquared) {
// objects could be colliding
}else{
// objects not colliding
}

That should be about it. Hopefully I will get some time to back fill that repo with examples from earlier snippets I posted.

Dungeon Crawler in Java

2016-03-26T00:15:00.001-04:00

I have begun building a dungeon crawler game. The premise of the game that I came up with is a little odd for a dungeon crawler but hopefully it will be interesting and you'll like it.

So the world is going to be made up of dungeons, yeah obviously. The dungeons will have been created from a simulation of AI dwarves starting from just two in a random area. I plan on creating some unique monsters that spawn in order to slow or stop the dwarves quest to build meaningful dungeons. Build in some magical items and of course hopefully some humorous history generated for NPCs, books, spells, and items in the dungeon crawl.

The world currently is all dirt except for a 5x5 area of grass where the dwarves will start out, need to add in minerals and rare metals etc. Also little hazards ;)

Tools I'm using:

Java 8
Eclipse
BehaviorTree
All current art done with Pixly for android

Heres a snippet from the Dwarves current behaviortree

public static AICreature createMaleDwarf(final World world) {

InOrderSequence root = new InOrderSequence<>();

SelectorNode isHealthy = new SelectorNode<>();

SelectorNode isDanger = new SelectorNode<>();

isDanger.addChild(context -> {

return world.findHostiles(context, context.getAwarenessDistance()).length > 0;

}, isHealthy);

Action attack = context -> {

return NodeStatus.FAILURE;

};

isHealthy.addChild(context -> {

return context.getHealth() > 80;

}, new LeafNode(attack));

LeafNode isBored = new LeafNode<>(context -> {

if (world.every(context, 0.3)) {

world.moveToRandomAdjacent(context);

}

return NodeStatus.RUNNING;

});

root.addChild(isBored);

root.addChild(isDanger);

return new Dwarf(root, world.zero());

}

Teaser

JRuby for game development

2016-03-10T21:38:00.003-05:00

So I have been pretty active in using Ruby for the past several years. I have found it a great resource for writing less code and producing more results. So why not use it for game development. Build some DSLs or better syntax for writing game logic code. So in this post I am going to run through a couple of ways to accomplish writing a game in ruby by using java for graphics and additional functionality.

So first we start off by needing to package everything up nicely in a single jar file so it appears as though we're just using java. Unfortunately this comes with a bit of a space cost. And that space is that of jruby the complete jar is ~20mb you can find them at http://jruby.org/downloads so no way to avoid this although you can do something like write an install script that downloads it and then puts your source into it afterwards.

Ok once you have the jar file you will add your code to it and it will become your executable from java.

Make a copy of the complete jar.

$ cp jruby-complete-9.0.5.0.jar mygame.jar

Create a file that jruby will launch called jar-bootstrap.rb

#!/usr/bin/env ruby
puts "Hello, I am jar-bootstrap.rb from inside the jar file"

Update the jar (-u) by first modifying the manifest to run a specific java class using option -e to override the Main-Class entry in the manifest already inside the jar.

$ jar ufe mygame.jar org.jruby.JarBootstrapMain

Then you can use the -u option to add files to the jar file or update existing ones.

$ jar uf mygame.jar jar-bootstrap.rb

Then viola:

$ java -jar mygame.jar
Hello, I am jar-bootstrap.rb from inside the jar file.

Ok we've entered the ruby~java land woot woot.

Now for lets rubify java to do our game-logics bidding!!!

Lets switch the jar-bootstrap.rb to load our game which we will start in a game.rb file:

jar-boostrap.rb becomes

#!/usr/bin/env ruby

require './game.rb'

Then we make our game.rb file with a simple example of loading a java swing window and rendering loop

game.rb is

#!/usr/bin/env ruby

include Java

import javax.swing.JFrame

import javax.swing.JPanel

import java.awt.BorderLayout

import java.awt.Dimension

class MyDrawPane < JPanel

def initialize

super

setDoubleBuffered true

setPreferredSize Dimension.new(800,600)

end

def paintComponent(g)

g = g.create

g.drawString 'Hello from ruby', 0, self.height / 2

g.dispose

end

class MyGame < JFrame

def initialize

super "My Game Window Title"

self.setLayout BorderLayout.new

self.add ::MyDrawPane.new

self.setDefaultCloseOperation JFrame::EXIT_ON_CLOSE

self.pack

self.setLocationRelativeTo nil

self.setVisible true

end

MyGame.new

And with all this we have a simple window to start from but now we can use the power of ruby to rule the world. Uh I mean we'll use the power of ruby to make games...

...to rule the world...

So this is all great but maybe we want easier iterations with our game development because updating the jar all the time isn't that fast. So for development just execute your game.rb file from jruby directly. You can use the original one you downloaded.

$ java -jar ../jruby-complete-9.0.5.0.jar game.rb

Or if you use rvm or rbenv then just execute the game script. And Q.E.D.

So many options, whats a game programmer to do

2015-09-13T22:30:00.001-04:00

This has been a difficult question lately with for all kinds of programming tasks. Its sometimes feels like the toss of a coin.

Delusional thoughts...

Do I go with Java and deal with the steep cost of over engineering. Or do I use unreal engine cause every professional game is made with it. Or perhaps Ogre3d to just take up so much time reimplementing or integrating c++ packages. Perhaps I should just stick with Unity its popular these days.

Anh! but the workflow for Unity involves nothing but hacking around and repositioning everything which i should probably just get used to, since that seems to be how all levels are made. I could try HaxeFlixel again that actually showed promise and was something different. It had my game state pattern built in which was cool.

I could go back to SDL with SDL2 but the setup was nightmarish to include all the necessary SDL pieces and kind of a bad fragmented experience. Or I could just use GameMaker its still around, of course Construct worked though they are in a monetizing phase and Construct2 didn't seem performant in the browser and the interface is not conducive to game design but gives me the feel of the old school drag and drop GUI editors.

...from fantasy island

Retrospectively I have failed repeatedly to make games with any of these. Usually its because i start and then reach some part of the process where I have to make a decision about what I do next and I cannot decide how to choose either the implementation detail or a game design choice. But in order to move forward I must choose.

desire for motivation

So it would probably help for me to state the problem and then come up with a solution. I have been trying to find the best way to motivate continuous change within software to push development forward and to not get stagnated. If successful I will be able to put aside my uncertainty and anxiety and move forward. It should help propel my projects forward.

The key to overcoming these adversities and focus on the task at hand and propel things forward is first to a release them and increase my public code presence. Which will help with my career and help get users who may need new features so as to add additional incentive.

Next is to know where each project is in its development, and roadmap the near and far future. The better the roadmap the easier it is to just pick up the project months down the road and get it to that next step.

What is truly need by ever programmer is to clearly identify what the next coding objective is whether it be to write an abstract game saving mechanism or to write a high throughput light calculation algorithm it remains the same, what do I work on next. Regardless of language or package we must remain objective in order to develop games.

Ok so not quite...back yet

2015-02-03T23:28:00.003-05:00

Been playing around with lwjgl and jogl a little bit lately. Ran into a slit issue as while attempting to get a project setup and running. First was that I wanted to use maven to grab the latest jars and ultimately natives. Each project does things in substantially different ways. I have to say that jogl is much simpler on the setup end for maven support.

Hey here is the pom.xml file:
https://gist.github.com/njd5475/4dc980d0a0ed8775bb20

And of course the lwjgl which was not so simple. Instructing maven to do the jar extraction for the natives was pain enough to find. There was also a necessity to put them in the root project directory in order to run in eclipse out of the box.

https://gist.github.com/njd5475/1109a01cec0afbd64b68

It was an interesting exercise along with updating an old JOGL 1.x project for JOGL 2 there were some basic differences that caused quite a few compile errors.

P.S. Yes I am on github here https://github.com/njd5475

Back and better than ever

2014-12-01T07:10:00.001-05:00

Its been far too long. So lets see whats happened. Well got let go of a job got another job, got sucked in to a mountain of work and just couldn't get out of it. Been working on some android game engine code for a while. A little on green algae here and there but thats like the pet project at this point.

You always have two projects, first is always your masterpiece and the monolith. The second project is usually your playground and the one you dont care about. Its always the one you don't care about that ends up succeeding where you fail at the other one. Its also the one you keep coming back to to work on after you learn new things.