Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Discussions / General Discussions / Re: Your feeling on discovering that your game is uncannily similar to another game? on: 2013-08-17 18:04:41
Ages ago, I wrote a combat card game suitable for use as a combat system in an RPG.   About a year into my designing and play testing, a brilliant and edgy game called, Lunch Money, was published with a fairly different play mechanic and a very similar attack/defense mechanic.  It was  so close that most of the cards in that game can be used to play my game and a lot of my cards would work for that game.   The attack defense mechanism is fairly common in wide range of card games, but it is much more obvious in two combat games side by side.

So I tried Lunch Money out as as one shot RPG and it worked quite well.  Had much more mood than my game, but was not going to grow broadly or flex well.   The built in unfairness in that game also complemented the mood, but would not do well in an expanding and flexible game.  I prefer my mechanic as it is much more level, adds quite a bit of dynamic and results in more play in less time.   So I still had good reason to continue with my project despite finding a game that was finished, similar and in some ways superior to my own.

Having compared the two, I found places to improve my own.   Since my goal and direction is quite a bit different, the other game helped me to see how to get closer to my own ideal.     

My game is now much less like the other game, and is a better game because of it.  I still love the game Lunch Money and consider it one of the best beer and pretzel games written.

2  Games Center / WIP games, tools & toy projects / Re: Hexboard generator / factory on: 2013-07-20 20:05:49
Superb!  Thank you for sharing!  I have been thinking about doing hex for the longest but keep getting distracted from it.   Looks like you are planning a space game!
3  Discussions / General Discussions / Re: Eclipse Kepler 4.3 on: 2013-07-17 05:55:00
Syntax highlighting seems to be working fine.  The default color of the highlighting is way to subtle however.  Subtle as in nothing, no color, just a frame.   Fortunately that is resolvable, if you go to Window - Preferences - Editor - Text Editors - Annotations - Occurrences, you can change to color to something a bit more apparent.   

While I was in the area I made a few more changes, the defaults err strongly in the 'use mature colors and avoid distraction' direction.  While I prefer a gentle touch to color use in editors, I also like clear indication. 
4  Discussions / General Discussions / Re: Eclipse Kepler 4.3 on: 2013-07-16 16:00:41
I have now tested kepler in 64bit and 32bit windows environments.  Not extensively, but so far I like it.  The hop from indigo to juno was not painless and not worth it.  The hop from juno to kepler is pretty clean. 

I am including links just for convenience, here is my update process;

I downloaded and installed the latest JDK for windows, not the EE version.
I downloaded Kepler, the EE version.  I have no real clue what is the best version for me so I went with EE.
I copied my various workspaces to a folder labeled Juno Workspaces. 
I started up Kepler on my nastiest biggest worst kludged workspace and ran my worst project.  Seemed OK, no real issues.
I highlighted the project and did a Source-Cleanup on it.  I looked over and accepted a rather large chunk of changes and ran it again.  Faster startup, and smoother.
I ran source-organize imports, sort members and finally format.  Code runs fine.
the auto suggest seems solid, control-z and control-y are fine.  Control-F seems to pop up faster.

I have not yet imported anything but I played a bit with the build paths and it seemed smooth enough.  So far, I like Kepler a lot more than Juno.   
5  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-13 05:13:11
My issue with static is pretty simple.  While coding every so often I manage to create a bug.   Most bugs I make cause immediate visible issues in Eclipse.  Eclipse will suggest a viable repair to the problem half of the time.  Probably one in four, Eclipse either gives me a better way to code what I am trying to code, or gives me a correct example of the parameters I am trying to pass.  This is great.   After I run the program, most of the remaining bugs  quickly show up and I can even see what the line of code that blew up is.    If I run the code in debug mode, I can explore some objects and values set.

So when I do create a bug, my programming environment almost always catches it.   The remaining bugs, the ones that got through the sieve, are usually fairly simple.   The are also usually flaws in program logic.   My bad!  I fix them and the problem is gone.   Sometimes the bug fix requires altering a parameter or creating a int somewhere in another class.   Rarely does this involve more that three object needing adjustment.  Sometimes a bug is worse.

Sometimes I lose a day of programming joy to a long day of frustration while first having to find the cause and second having to adjust a hundred or so objects after finding the bug.  In every case so far, these bugs, these horrid bugs that set me back and make me do a huge rewrite, have been static.   In every case so far, when I have created the same bug without static being involved, Eclipse has caught the error for me.   I don't know much about other SDKs.  Eclipse does not seem to error check static as well as it does Enum (which is a type of static, but I love me some Enum's.)

Static is not great for unit testing, it may be the same qualities that make static instances a pain to work around for unit testing, make static instances hard for the basic system tests.   For me using static, is like working without a net.   If I am walking on the ground, or a thick path, static is fine.  If I am on a high tight wire, I need a net.  So when the code gets complex, I don't trust static.  

I have but two lights by which to guide my feet, the light of experience and the light of experts experience.   When I went out to look for examples of how to reduce my dependence on static, I discovered quite a bit of help.  Good code examples and good methods.  While I had testing using JUnit I really did not have enough grasp of testing to see the holes in my testing that static variables introduced.  This was I admit a bit blind of me but since my tests were simple and based on the Eclipse and Java for Total Beginners tutorial videos.   I must confess, that my tests are still pretty simple and only approach quality when I am troubleshooting an issue.

While researching that help, I found quite a few brilliant coders who has strong issues with the use of static.  Google, 'Java static evil,'   and you will find slews of much more advanced Java coders than I, that speak fairly freely about the use of static.  There are a few static apologists out there as well, and while their arguments in defense of static seem sound enough, they are still couched carefully and they advise limited use of static.

Looking at the arguments for and against the use of static, it does appear that code that is low static, is more likely to be transportable and reusable.  Tests of code that is low static are generally simpler and more thorough.   Examples of low static code are going to be better examples of object oriented programming.  From my experience and from the experience of many others, static bugs can be nightmare fuel.    When a bug moves from being one created by poor syntax, math, or logic to being one created by compilation logistics, bug hunting expands the required understanding and attention to minutia by a rather large factor.  

Additionally as I started to embark on writing with as little static code as I can, I found another rather huge advantage to reducing ones dependency on the use of static.  The ability to make more than one functional instance of an object.   My original player object was brim full of static variables.  A lot of these did not need to be static, but I figured that static variables might take less clock time for the final code so I left them that way on purpose.  It was also loaded with a rather large share of static methods.   I could reproduce the player object, but since the player object interacted with just about everything, static was everywhere.   The very thought of trying to introduce a functioning second player was horrific.  My weak attempt involved copying the player class and making the secondPlayer class.  This was bad however since half the critical data in the game was passed by public static variables or methods.    After making my code static free, my poor planning for the future was not really an issue.   The only complexity was getting the control inputs to control the correct player and that was easy enough to resolve.

As a clarification, what I mean by low static is no static except where I have not come up with a reasonably elegant and clear way to not use static at all.  By my best understanding this is a positive step toward writing much better code.  It has already made my coding easier. 

6  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-11 07:16:20
Any bug that survives Eclipse, Compilation and basic testing I consider a bad bug.  The ones that stop you dead in the water and make you start thrashing your code in order to find it, is the type of bug I fear.  

One nasty type of bug is the bug that is there all along but works fine  initially, is always a horror.   Instead of being in the code you just wrote. it is in other code hiding and waiting until the conditions are right or your code has snowballed enough to blow up.   By this time your code is big enough for a bug to hide.

Another nasty bug form is the type that exists because of a perceptual understanding that does not match with the actual function of the beast.

My worst static bugs have met both of these criteria.   The problem with perceptual understanding of static is subtle.   When static creation and dependency gets complex, the order of creation can become critical.  

As a simple example here is a class Widget used to build widget objects.   It has two errors concealed in the code waiting to blow up as you expand the game.  

One error is that using a byte to reference an array of 256 objects is going to work fine until you half fill the array.    The game is going to be fairly complex before you reach the level where this is going to break.  

The second error I have already stuck in.  It is a static error that could not be found without thinking about what static really is and how the java compiler is putting things together.  

The second your character trys to place a preSmoggle in the Factory, you are going to get an error.  The problem is that the static preSmoggle refers to a smoggle that was defined after the preSmoggle was defined.   It is hard enough to find this sort of error when you just added it and it blows up consistently and the issue is laid out in a straight row.  If this same sort of issue is spread over several objects, good luck finding it quickly.   Even when you know exactly what is blowing up with a null and you know where the offending code is, when the order of the compile can alter the results, the bug can turn into a nightmare.

import java.util.Random;

import com.badbadcode.example.stuff.materials;
import com.badbadcode.example.stuff.products;
import com.badbadcode.example.render.render;
import com.badbadcode.example.Screen;
import com.badbadcode.example.Factory;
import com.badbadcode.example.Player;
import com.badbadcode.example.Entity;

public class Widget {
   public static int clock = 0;
   private String destinationFile = "";
   protected Random random = new Random();

   public static Widget[] widgets = new Widget[256];
   public static Widget fneed = new FneedWidget(0);
   public static Widget glonger = new glongerWidget(1);
   public static Widget wonkafier = new WonkafierWidget(2);
   public static Widget smocker = new SmockerWidget(3);
   public static Widget preGlonger = new selfMaker(4, glonger);
   public static Widget preWonkafier = new selfMaker(5, wonkafier);
   public static Widget preSmoggle = new selfMaker(6, smoggle);
   public static Widget smoggle = new Smoggle(7);

   public final byte id;

   public Widget(int id) { = (byte) id;
      if (widgets[id] != null) {
         throw new RuntimeException("Duplicate widget issue!");
      widgets[id] = this;

   public boolean mightShock(Factory factory, int x, int y, Player p) {
      return false;
   public boolean use(Factory factory, int x, int y, Player p) {
      return false;
   public boolean mightNeedKicking(Factory factory, int x, int y, Player p) {
      return false;
   public boolean mightSprayGrease(Factory factory, int x, int y, Entity e) {
      return false;
   public boolean mightBlowUp(Factory factory, int x, int y, Entity e) {
      return false;

Every issue is a newbie issue but if you are trying to push your coding skills, Java is huge enough to always provide a new area where you are a newbie.  Otherwise solid programmers create eventually obvious but elusive bugs when they found themselves using simple code that they rarely use.   Since I usually trying to write code several levels above my skill set, avoiding methods of coding that can sneak compilation issues into the code is just smart.

After I had dealt with the previous bug, I had a bug like this that would work fine one game and blow up the next.   I suspect it was the order that the objects were called during game play that made the difference.   I finally gave up on finding the bug.   I deleted a slew of classes and rewrote them avoiding static.  Even with the learning curve of figuring out how to do stuff without static, it took me way less time to recode the classes than I had already spent trying to find the bug.  

7  Discussions / General Discussions / Re: Making a Static Free Engine on: 2013-07-09 03:02:44
I am really going to see just how far I can get without static.   I am usually pretty good at debugging things, but the tangled mess I recently created has left me trembling in fear.

 Random numbers are no biggie. SimpleRNG produces a fairly sweet set of random numbers.    I rather like pseudo-random generators anyway.  With the same seed you get the same result.  This allows me to examine a random game setup and replicate the ones I really like by using the same seeds.  It is quite possible to save a world map by saving two doubles.   Most RNG's show their flaws in a multi-thread system.  Either they are not thread safe or they end up producing enough of a pattern for you to start guessing what comes next with reasonable odds.  once you figure out how to keep cranking numbers between zero and 1, you can make a slightly different generator for each thread.  Done well, this can make pseudo random numbers seem pretty random. 
Pseudo-random generators can be useful in testing as well.     Best hidden program change detector I ever saw was based on a random number check.   If you want real random numbers record the interval between a players key press events while starting the game and adjust a seed with that result.  You can keep measuring user timing to adjust your seeds.  This does create a potential testing flaw.  Live use is more random than test events.

Guice looks like a a good anti-static laundry sheet for Java.   I have no experience with it, but it look pretty sweet.   JUnit I love, I just need to use it more.  It makes me twice the programmer I would otherwise be. 

As far as constants go I rather like using enum so I guess I am avoiding the word static and not all static instances. Enum can be used to give code clarity so I rather like it.  Enums don't work well with the word new, but the implicit error checking that goes along with the word enum seems to prevent my doing really stupid things with them that won't show up till much later.

While I am going to make a serious try at being static free, I got over my dependence on philosophical coding limitations years ago.   At one time there were two new languages that were neck to neck in competition, C and Forth.  I picked Forth.   Part of the Forth philosophy was no floating point.   It made sense at the time.  By keeping important values as a ration of two potentially very large integers you could avoid the rounding errors caused by division until it was time to output a final number.  You simply multiplied divisors with the divisor to effect division without having to do it.   This was all well and good, but it was a pain when you just wanted quick and dirty and didn't really care that you might be off by a ten thousandth.   This was a particularly sad thing since no language before or since has been as good at doing quick and dirty.  Forth coders implemented floating point stacks, but floating point was never part of the approved standard. 

I have been using static as a way to provide simple access to data that I did not mind being global.  Now I only use static if it absolutely has to be global.  So far the only thing that has had to be global is the main method.
8  Discussions / General Discussions / Making a Static Free Engine on: 2013-07-07 20:44:35
I just escaped static hell after way too many hours of frustration.  I write this as a map to help you escape static hell much easier than I did.   As I am far from being a java guru, if you see a better way or have an issue with my methods, by all means pile in.    

Because your Java program starts execution with a block something like, 'public static main(String args) { }' , Java sets you on the road to static hell.   The experts will give you philosophical reasons why static variables and methods are wrong.  I am not an expert by any means, so my reasons are plain and simple.  The first reason why static is evil is static creep.

Static creep happens when you get an error that wants to to change a variable or method to static in order to resolve an error.  Static is an addictive state in Java.  The first two 'public static int whatevers' were free, but then you had to have a getter or a setter and suddenly you are on the road to static hell.  Every change or addition wants to be static and when you finally try to make a constructor, you find that the word 'new' and the word 'static' don't play well together.   So you try to reduce the static and you discover the real catch, static cling!

Static cling happens when you try to fix your static filled code from the bottom up.  You fix stuff until the code saves without error and then it blows up with a null from nowhere when you run it.   If you are not real careful, you can easily thrash your code into meaningless gibber while chasing down and trying to comprehend where you went wrong.   If every other line in your code resembles 'system.out.println("it got past this part and x is now " + stupidValue)' you know exactly what I mean.   Once you figure out where you need to inject a proper linkage to avoid the null, unless your initial source for the linkage is clean, static creep sets right back in.

Here is a game engine example of how to escape static.   This game engine consists of 6 objects; Game, GameEngine, Play, Canvas, GameLoop and GameContext. They key to escaping static is the GameContext object. is how we escape from static hell. contains all or most of the variables and methods that would have been static. It also has all the appropriate getters and setters.  The GameContext method can initialize objects and set this.whateverObject = whateverObject so that the initialized object can be referenced later. Your game might be better organized with GameContext divided out into a few similar objects but the function remains the same and the core context object can initialize and provide links to the other context objects. is the central object passed to methods in order to link the various processes. Game has the main block in it.  Game calls GameEngine.Java and passes itself and a new Play to it.
'GameEngine.start(new Play());.'  
By creating and passing Play in this manner, we have now excaped the static realm and everything else can be free of static. sets up the canvas and starts the game loop passing itself and to extends and is where the engine becomes personalized to the game.  If you keep the modifications and expansions of your engine as generic as possible, you can reuse it for other games you write.  Ideally Play and GameContext are the two parts of the engine that bridge between the basic engine functions and your game.  As you extend your game, alway keep in mind that generic additions might be more useful if added to the engine, and specific additions should remain outside the engine.  Since extends, generic functions can be maintained in and can have the same function personalized with a '@Override' in front of them. has the generalized methods for render and update that should probably point to render and update objects.  Updated properly, Play is where drastic changes to the game can be made and reversed with relative ease. is the graphic object and starts with 'public class GameCanvas extends JComponent implements ComponentListener {.'   Canvas has all the listeners so Canvas is not only the object to refer to for display, it is the object to go to for interaction with the display. calls all of the background processes that make the game run.  GameLoop calls a routine in to redraw everything and a routine in to update game status over and over again.   A good primer on game loops can be found here,

Now to string it all together all the classes that need it have a 'Game game; defined and set by either a setter or by having it passed as a parameter and set with the line ' = game;.'   The Game class has the line 'Context context = new Context();.'

Since Play extends Game, when play runs the line 'context.setPlay(this);.' game.context.getWhatever()' and 'game.context.setWhatever()' can pass to any objects that have the parameter game and ' = game;' as part of the construct.

If the object you are working on is going to be large the line 'GameContext gc = game.context;' can make it pretty easy to access the pool of variables.  Writing something like gc.getDataYouWant() to call up a value is pretty easy and an entire range of potential static errors can be evaded.   All this and the Guru's will tell you that you have avoided the slew of security, testing and philosophical issues that static variable present.
9  Game Development / Articles & tutorials / Re: Game loops! on: 2013-06-21 22:15:28
Thank you, Eli!

This entire discussion has resolved quite a few of my timing  issues.   What I have been using for a loop trusted sleep time, which has caused me to personally lose sleep time more than once.     

Ironically, the fixed timestep version listed has the potential to leave a copy of gameLoop() running.    If you have a menu system start the Loop Test Demo for example and the user starts it and then closes the frame by X-ing out of the window, the loop will still be running despite the lack of visual update.  The thread started has no dependency or test related to the closure of the panel.


Pages: [1]
DesertCoockie (54 views)
2018-05-13 18:23:11

nelsongames (86 views)
2018-04-24 18:15:36

nelsongames (76 views)
2018-04-24 18:14:32

ivj94 (761 views)
2018-03-24 14:47:39

ivj94 (93 views)
2018-03-24 14:46:31

ivj94 (645 views)
2018-03-24 14:43:53

Solater (104 views)
2018-03-17 05:04:08

nelsongames (187 views)
2018-03-05 17:56:34

Gornova (428 views)
2018-03-02 22:15:33

buddyBro (1088 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!