Wednesday, October 3, 2012

What's up

So got a great job and loving ever minute of it. Extremely busy an endless amount of work to do. But I am still finding a few moments here and there to do some game development.

Don't have as much time as I used to which makes getting stuff done all the more important. So rather than spend time fiddling with a piece of code or trying to make some design changes I have found myself just going with the quickest and easiest approach.

Sometimes the code gets a little messy but for the most part I stick to the principles and style I've found work best. Like knowing when it's a good idea to move code into another function or create an abstraction. But yet with all that it's still hard giving people estimates making schedules and meeting them. Especially when you don't know what is going to cone up and you've only been doing the job for less than a year and of course this us the first time I've been in an environment like this.

I've been working with lwjgl a little bit very similar to other opengl wrappers. Which seem to take the simplest approach to design for an API. That can be good or it can be bad. To many static functions which breaks the use of an object oriented language. But then again I don't have the time to spend on making something better and abstract to manage all the interconnected gl states. One piece of advice I can give for when something isn't working is that you probably need to enable or disable something.

I was recently trying to use textures and draw line segments afterwards and the textures would show but segments wouldn't, if I didn't draw textures the segments showed up. The long and sort of it was I needed to disable texture 2d before drawing the segments and make sure textures were enabled before drawing them again. I'm yeah I either didn't know this or forgot if course I intend on moving away from immediate mode soon.

Alright that is all for now until next time. Btw I love challenges so if you want to challenge me to implement something you can't seem to figure it how to do if I can get it working I'll post how it's done with example code. You know help me to help you we both win I learn you learn.

Monday, August 6, 2012

Danger of Singletons

A comment posed the question about what is a singleton and why I recommended staying away from them if you can avoid it at least for the Keyboard Input Polling System. In some aspects it does come down to personal preference and whether you think it's a good usage of the design pattern So a singleton is a class for which there is only one instance in the entire program. Purists and API designers usually try to force the condition since creating two of them could break the pattern and usage of the class.

How I usually make a singleton in java is by removing the ability to instantiate another instance and providing only one instance to be used via a static method. This is easily done by changing the constructors visibility to private or protected, while making it protected allows for subclasses to be made which could break the rule where as private does not.

public final class Singleton {

 private static Singleton instance = null;
 
 private Singleton() {

 }

 
 public static Singleton getInstance() {
  if(instance == null) {
   instance = new Singleton();
  }
  return instance;
 }
}

In my opinion if you need to make a subclass of a singleton to override functionality then singleton is the wrong pattern. Also use of the final keyword will ensure there are no subclasses or anonymous classes can be made. Which of these you use depends entirely on the responsibilities and usage of the class. The core java package has a few singletons ones that come to mind are the Runtime, Toolkit, and Desktop. System almost seems like one as well, though it isn't instantiated so it's not a singleton and more akin to a C library in C++.

There is a lot of good material out there discussing the pitfalls and implementation issues associated with Singletons and their instantiation. But before I go into those I will answer why I recommend staying away from them. You first must be absolutely certain without any shadow of a doubt you won't need two of those objects. Secondly only use a singleton if there are variables that you are using to store data that is imperative to the objects behavior and needs to alter as time goes on, this I believe is referred to as saving state or containing state. Thirdly you have to think of threading since a non-thread safe singleton is paramount to suicide you will inevitably restrict any function that uses the singleton to not be thread safe (dangerous and limiting).Fourthly you are automatically granting access to the singleton to any piece of code that imports it which will create a binding contract with the singleton which is not good since most of the time you don't know what your overall end design is going to look like or what your going to add next.

The only reason for creating one is if you have your full set of requirements and features upfront and know 100% your not going to want two or more of them. Sometimes the singleton is used to create a set of library style functions or functionality that is really designed for more of a customized command type language in a generic object oriented language. Here are some resources to get you more answers on different implementation strategies of Singletons in Java.

http://www.javaworld.com/javaworld/jw-04-2003/jw-0425-designpatterns.html?page=6
http://stackoverflow.com/questions/137975/what-is-so-bad-about-singletons

If those fail resort to google.

The stackoverflow post gives a good concise explanation of the design problems around singletons. The alternative I use is more along the lines of simple dependency injection which is more flexible and forces you to define relationships between objects that need the would be singletons functionality and how to give them access to it. Singletons and Static methods in Java circumvent having to define relationships between objects by providing global access which in turn creates coupling where ever they are used unless you design your objects to use any instance instead of the one and only instance of the singleton. Example would be

constructor(Singleton s) {
// not globally accessed so singleton can be any instance
}
While this is still coupling it's more flexible than say this
constructor() {
Singleton.getInstance().use();
}
I hope this helps give some resources and explanation of singletons. Let me know the reasons or situations where you've used singletons even if you didn't know what they were. Each situation in coding has some level of constraints to it whether it be working with an existing system where you need to add functionality without redesigning a lot of code so Singletons were used as a way of circumventing necessary design activities or to reduce the amount of work involved in order to add unanticipated features, and I've seen this a lot in code where no solid unit tests exists so redesign causes significant risk to existing code so public global access to new features is easier than the redesign. Cheers!

Monday, July 9, 2012

Taking The Plunge

Sometimes during development you find obstacles or challenges you don't know how to tackle. Features you've never coded before or situations due to already written code that just make sense. You can count on a little bit of pressure here. You need to get the implementation done by Friday but you know it wouldn't take you that long if you only had done it before. Or there is a certain mysterious piece of code that somehow eludes you. Maybe the situation is one where you can't figure out exactly why a function isn't working the way you had expected or you had thought it did things that it does not do or handle situations that it wasn't written to handle. In these types of situations your best option is to just simply plunge right into trying things and looking at their result.

Many times API or programmers on your project simply overlook certain situations. There is always a reason why they didn't handle situation x or y. Usually it comes down to purpose they didn't intend the code to be reusable for a different purpose. This is can also be the reason for performance problems where the code was written using reusable principles and designed to be generic but it was never optimized for the situations that it allows. You end up either rewriting it altogether as a separate piece of code that looks a little similar or you deal with the ramifications of reusing it. This usually happens more often than not when the code is part of your project rather than 3rd party code. Though a lot of times its directly related to the misuse of 3rd party of external APIs where the programmer using those APIs didn't understand how to use the API the way it was intended.

Again just plunge right in attempt to use the code you have and look at the results. Almost all the time the code could use refactoring if it is to properly handle what you want but you must know that if  you decide to use it and not refactor it but instead use work-a-rounds to get it to do what you want rather than changing it you will inevitably be building performance or maintenance problems in the future. Reuse can be a crutch, more on that later, the main piece of advice I can say for productivity is to just start changing it find that better way swap out the current implementation for something that handles the existing situations as well as your new one.

Many times in programming you can feel trapped and get yourself into a loop of inactivity while you stew over how to hack around structural issues presented by poor design from the past. More often than not it is a lack of redesign activities which are causing your frustrations. Depending on which path you choose you could end up feeding the beast and mangling the code breaking consistency. It's usually readily apparent in any codebase to recognize learning code from real functional code. You can notice subtle programming mistakes brought on by unconstrained use of misinterpreted patterns. If you know what I am talking about and have witnessed coding atrocities feel free to recount your painful experiences here as each new situations presents the opportunity to learn ways to mitigate the overlooked risk of poor design.

Friday, July 6, 2012

Integration

Level and animation creator editor
application started back in 2009
I have a game engine project that I have been working on since 2009 it's gone through quite a few transformations and iterations. Multiple design changes and I hope it will actually become fully functional sometimes soon but I haven't had much chance to move it forward. This integration effort might help that.

So I was looking back at my old editor code that was written for the engine to do animations and level creation. I found some old bugs that I had never fixed and set about debugging and fixing them which took an hour or two. I also was working on some art in my newer "Pixel Painter" program which I created for drawing pixelated graphics. I've used that drawing program a lot since I started creating that last year. It's very useful and makes drawing images pretty quick but there are a lot of features it lacks including basic undo/redo functionality. Still need to work on that.

So I was testing some graphics out in the editor cause I wanted to see how they looked tiled and together and was desperately wanting the ability to simply edit the tiles I was testing with my drawing program and see the changes appear in the editor. Because of the way I had designed the drawing program I knew I could integrate the two very easily. In fact it was even easier and worked better than I had hoped minus a small piece of optimization code that got in the way.

I set about quickly adding a menu item to a right-click popup for "edit"ing the tile image. Created a new ImageController passing it the tile image after doing some extracting from the resource loader it was in, create my new drawing program class and called the createAndDisplay method giving it it's onClose instructions of JFrame.DISPOSE_ON_CLOSE so that it doesn't exit the entire program when I close the drawing window and viola I had the ability to get my tiles from my map program into my drawing program. Awesomeness!!!!

But when I went to try this out to see if the image would update in the editor with the changes made from the drawing program bang exception. Apparently my editor images were not exactly BufferedImages which is what my drawing program needed to be passed they were indeed SunVolatileImages I was like what the freaking hell. After about an hour of digging around the code tracing through things I came to the source of the problem inside my ImageResource wrapper class. Indeed I had done a little image optimization at some point and had this line in my resource class

image = AssetManager.accelImage(img);

Drawing application "Pixel Painter"
started some time in (2011)
That method turns the BufferedImage into a Volatile image if it's image capabilities say that it's not hardware accelerated. I had run into a problem with another game project that slowed framerates to a crawl because the images weren't accelerated and pretty much had rigged the resource to transform itself to be accelerated if it wasn't already. After making a toggle method where I could specify I didn't want them accelerated and skipping over the acceleration line I reloaded the editor popped some tiles in using drag n drop from my images stash and viola editable tiles in my drawing program that will update in the editor when changed and I could save them as separate files in either program.

There are a bunch of other integration's I want to do now for instance creating new tiles using the drawing program from the editor, editing animations and sprites. Creating tilesets from the editor and editing the tiles with the drawing program which if the above is any indication shouldn't be hard at all. And of course upgrading the editor, I don't have layer support or object placement support. So there is a lot to do there but it's definitely fun and worthwhile to do hopefully it will be able to support games in the future but for right now it's just a little testing tool.

Saturday, June 9, 2012

Still alive and still have no time

I am still here but at this point the only thing I am able to do is to think about game design and programming. The new job is going well but it is a lot of work. It's been a lot of fun and I am enjoying it even though it's not game programming. There are a lot of things that need too be done. It's good experience practicing my time management skills smoothing out some of the rough edges making sure I follow process guidelines that sort of thing.

Ok to the Blog. The next task is the sprite system which I think I now  will build a traditional sprite class in a single post then go about refactoring it and discussing some of the interesting design decisions. I have a work in progress uml but I think it morphed into needing other engine pieces not just the sprite system which I believe is a good thing.

What I am talking about is that in designing the sprite classes and removing some responsibilities putting them into other classes: for instance sprite movement and rendering. I removed those from the sprites responsibility in order to be able to encapsulate all sprite instances movement for performance, you'll see what I mean later down the road.

So I hope that I will be able to deliver at least a small sprite class implementation to work from this weekend. If not I give you permission to scold me nicely of course.

Friday, May 11, 2012

Sprite System Progress

Sprite System Work
Working on designing the Sprite classes, I am looking to optimizing for large numbers of sprites and being able to handle as many game type situations as possible. Making it easy for you to do some advanced things with it. I am thinking of animating the position and rotation over time. As well as being able to add several sprites to a group and animating them together or independently this will help you reduce the amount of artwork.

Creating Simpler Sprites
There a couple of ways to go about doing sprite animations. You could just have a single hand drawn animation for all your needs where each frame is animated according to what you need. However, that increases the number of images that need to be individually drawn by an artist. If you happen to be the artist this is time taken away from doing programming. So it helps to split an animated sprite into sections that can be animated using code rather than having to draw every frame for every animation.

It becomes almost impossible when you want to...say have a character with a large number of different weapons throughout the game, the artist would have to animate each animation of the character and manually rotate and manuever or even redraw or touch-up sections of the character with each weapon, then if you add different armor or cloths the permutations keep growing. These additional images will increases memory usage at runtime as well as distribution size of the game all the while taking a bit more time to complete. Whereas using a couple of images and combining them using hot spots like say the location and orientation of the hand and the weapon handle. You can draw each weapon depending on which one the character is equipped with under the character image and translate it to the hand position no extra images required other than the character and the weapon.

Benefits
This type of system works very nicely, you can also either define the rotation and position for each frame of the character animation where the hand moves position or interpolate the weapon position based on an overall path of the hand. Another benefit is being able to add post-processing effects using off-screen buffers to individual parts of an animation. The great part about that is you can animate the effects over time as well. For instance say you want to make a flaming sword but you want it to appear random and dynamic instead of pre-drawn. It is much easier to do when the weapon image is drawn separately than the character and not integrated with it. You can draw the sword in an off-screen buffer run your fire generation algorithm and then just draw the sword like normal. You can do heat warping effects and make the flame trail as the sword is swung etc.

Help Brainstorm
If you can think of any other types of animations or situations that you would want in a sprite system please feel free to comment. Always looking to design something that has as many usages covered as possible, since changing the code to accommodate new ideas after the fact can be hard if you don't anticipate them in your initial design.

Wednesday, May 2, 2012

Incognito

For a while now I've been focusing on my job more than anything. I get less time to spend on the computer at home than I have in the past. My job travel time is partly to blame in that it is actually an hour commute so that removes 2 hours a day from actual development time and blog time. Though I have had new responsibilities at home as well. I know there is little excuse for doing a 5 minute post and keeping things going I just hate putting up things that are uninteresting or that don't help you in your game programming and learning.

What's on the Horizon
But I thought I would take a moment to just start writing a few words to console you in your grief over the lack of posts. I am doing a rewrite of the Timed Animation putting splitting it into two or three posts:


  • Sprites - basic frame switching 
  • Advanced Sprites - collision objects, hotspots, rotations
  • Animations - starting/stopping, animations using hotspots, maybe automated reactions to triggers


I want the code to be a abstract and loosely coupled with the Java standard APIs so that they can easily be ported to Android or Java mobile APIs if anyone uses those anymore. The concepts are pretty simple, each sprite has a number of frames including the current frame. The rendering method and asset type (images basically) should be a bit abstracted away in order to allow for it to be extended to and reused in different types of situations such as using a Shape instead of an image or using some other custom type of renderable object.

This concludes the 5 minute update, any suggestions for things you'd like to see on here please don't hesitate to comment with what you'd like to see. I am always open to suggestions. Thanks

Friday, March 30, 2012

Update

Whats New
I thought I would just let everyone know that I am still alive. I was able to find a job and have been really busy getting started and figuring out the business. It's been a lot of fun.

Update Old Posts
I have a few ideas for new posts and recently there was a comment on the Timed Animation post that made me realize that some of the posts are in desperate need of updates and expansions. There is a lot that I haven't posted about how to do Sprites and Spritesheets, map file loading that might help people so I will do my best to make the time to work on those.

A Possible Repo
I have been looking into creating a git repo on github for the code here, that would allow for a place to store the code and allow others to contribute and collaborate. Potentially it could become an useful API, I am just deciding on what Open Source license to choose and how the folder and project structure will be laid out.

Call for Opinion
So what would be your favorite open source and version control system? And what you like/dislike about it?

Thursday, January 12, 2012

The Good and the Bad

So it's been a stressful week. I just lost my job recently which is bad news for me and good news for you. It means I have all the free time I want to create new posts and work on making games. Though I don't earn any money on this blog or on android so it's hard to say whether it's worth the time to invest in it. But don't worry I plan to devout time to creating posts and making games. So wish me luck, hope I find a job soon.

Thursday, January 5, 2012

Game Goals

Background
I've been working on some games of my own lately and I've fallen into the trap of "never-completing" a game. This is a bad position to be in, one that I have struggled with for years and I think it's intrinsic to game designers who want to make really good games. At the end of the day one finished polished product is thousands of times more valuable than having hundreds of unfinished products. Even if those products made it really far it isn't worth anything if it isn't finished.

Now we have to ask ourselves what is a finished game? I have seen a number of quotes that read something like this, "A game is finished when there is nothing left to remove". I want to say I fully understand this, however I am stuck with a mindset where I won't add anything to a game if it isn't going to be a part of the finished product. It seems like games are better suited to be developed by adding lots of features and then just weed out the unfinished or incongruous features polish whats left and then you have a game.

The Goal Line
I think one of the key things that I am doing wrong is probably a very important one. When I design a game I start from a blank slate which is good it allows pretty much anything that I am feeling or desire to enter into my game world. But then when I think about a game design I think in what seems to be a backwards sort of approach which is design a neat mechanic or think about an existing mechanic and design the game around that. I can tell you now this doesn't work.

The better approach is to come up with the goal(s) or challenge(s) the player has to overcome. This brings into play a major focus element for development and one of the most important aspects of any game. Whether the player actively asks themselves what goal they are trying to reach or not it's a fundamental aspect of game playing. This isn't saying anything about how to make great or even just good games. This is something I've struggled with when trying to make games.

Common Hinderances
I have found that I get too focused on how to reward the player in fun ways whether it be through feedback mechanisms that are very gratifying. Also whether or not a particular feature is frustrating. Both of these focuses are to be left for polish, and are secondary to coming up with a compelling goal or challenge. I believe that those two things the rewards and removing frustrations to be key elements of making "fun" games. Though if you don't have an major overall goal their just neat interaction systems without any real focus for the player and not very compelling.

As an aside an idea for a game is not even remotely close or good enough to make a game because when you go to test your idea most of the time you run into problems which you hadn't anticipated. This becomes easier over time after you've implemented your ideas. And I suppose your games will become tweaked and integrated versions of the mechanics you have experience developing.

Where to go from here?

Start with coming up with a major goal or challenge that the player must overcome and then add the fun bits such as new tools to help complete the challenge or reach the goal. Throwing in unique things to try and keep the player from their goal. Add in the little rewards like picking up items and such. Also a little note about the little things, particle effects or other types of graphical goodies are also rewarding to the player especially if their appealing to the eye. Some satisfaction is gained when a player receives "cool" feedback. Explosions are always a plus.