Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (515)
Games in Android Showcase (122)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Making a Static Free Engine  (Read 6357 times)
0 Members and 1 Guest are viewing this topic.
Offline gimbal

JGO Knight


Medals: 25



« Reply #30 - Posted 2013-07-11 14:33:42 »

...Whenever I realize a function does its job without needing other data than the one provided by the function call arguments...

In other words what I call 'stateless' Wink Agreed that then you CAN make it static. I'm never ever going to make any statement again about when you SHOULD do it because apparently that is sort of religious in nature.
Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #31 - Posted 2013-07-11 15:53:38 »

It was just an example of how static is useful to me, but your mileage may vary.

But when it is time to fix it, fix it or you will be in Static Hell.

So what you are saying is that... If you don't fix parts of your program that are not working right, you'll end up in trouble.


Really, all you just said could apply to any part of any programming language.  Clueless


Seems like you're picking on static because you personally have had trouble with it, to be honest.

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2013-07-11 18:05:59 »

I read the strangest things on forums sometimes.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Cero
« Reply #33 - Posted 2013-07-11 18:42:35 »

I like static :3

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #34 - Posted 2013-07-11 18:46:05 »

Static's great. We get games made using static data and classes and methods all over the place. At night, we sleep soundly*, safe in the knowledge that our static hell is keeping the roof over our heads.

Cas Smiley

* Thanks currently to temazepan but that's another story

Offline ralphchapin
« Reply #35 - Posted 2013-07-11 19:42:25 »

I use static all the time and it's great.  The problem is, it doesn't scale--in terms of numbers of classes and interfaces and the relationships between them.  As your program becomes more complicated, in the parts of the program that become more complicated, the static methods and fields start to get really awkward.

What I'm saying is use statics.  But when they start to get awkward in code you intend to enhance, pay the price to get rid of them rather than pile kludge on top of kludge.

This theoretically applies to any programing language, but Java handles complexity so well you're more likely to notice the problem there.  Everywhere else, when you hit static hell you'll be in so many other hells it will be the least of your worries.

And you can stick to simple programs, even in Java, and forget all this.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #36 - Posted 2013-07-11 20:29:09 »

Give us at least a example of your ""static hell"
Offline ralphchapin
« Reply #37 - Posted 2013-07-11 21:25:21 »

I try to avoid static hell so I'm not that familiar with it close up.  The usual problem I encounter is trying to stuff static methods into interfaces.  I pass an object that implements an interface to a method, and that method needs static (class) data.  The method to get it, in all classes that implement the interface, is, of course, static.  At that point, I rework the code.  If I kludged it, I imagine I'd be in "static hell", which I suspect is something like writing in Fortran or C, which I do not want to do ever again.

I have recently come across code where the data for 1000 "objects" is stored in a set of 1000 element arrays.  Game characters, for instance, with values for location, speed, health, etc..  This is no doubt faster than have a GameChar class with instances in one 1000 element array, but as the game gets more complex, the lack of GameChar instances to pass around gets awkward.  And the locking problems if multiple threads try to access individual characters will bring game execution and development to a halt.

There's nothing wrong with any of this.  Lot's of people frame nice houses with pine 2X4's.  But they know they're not going to put another 60 stories on top.  The problem happens when people come up with a simple solution for a simple problem, then try to stick with it when the problem becomes complex.

Offline Oskuro

JGO Knight


Medals: 40
Exp: 6 years


Coding in Style


« Reply #38 - Posted 2013-07-12 09:15:39 »

On the one hand, what you're describing is not a problem with static or whatnot... Is a general lack of proper software design.

You are aware that there are no truly universal solutions in software design? Specially with software as demanding as real-time applications (like most games are).

In essence, if you charge straight into implementation without devoting some time to making a decent design, you'll sooner or later hit a wall (depending on program complexity).

Keep in mind that, when you go to college to study software engineering, there are entire subjects dedicated exclusively to software design, where you don't get to see a single line of code (and, thus, I hated them with a passion  Roll Eyes)

So yeah, it's an important part of a complete breakfast.

On the other hand:

I try to avoid static hell so I'm not that familiar with it close up.

This is what's been bothering me since the start of the thread. All that rethoric about the evils of static data, and yet you don't have a few case studies to throw around?


I'm sorry if I'm too blunt, but this stinks, as I said earlier, of dogmatic zeal.

For whatever reason you've come upon the conclusion that static data is evil and have decided to spread the gospel like a regular door to door preacher.

And just like anyone who has internalized a belief, no amount of rebuttals will sway you from either having said beliefs or refraining from proselytizing them, as evidenced by this very thread, so full of perfectly reasoned examples as to why your position doesn't hold, which are being conveniently ignored.

Again, sorry for my bluntness, but is my experience that, for any debate to be productive, the participants need to be ready to learn, or, in other words, ready to accept their preconceptions might be wrong.

Anything else is just pointless dick waving that helps no one.

And yes, I'm guilty of those very same sins myself, and it revolts me to realize I'm close minded to0, that's why I devote so much energy to try and help people break out of that mindset.

Again, I'm not saying I "know" how you think, just saying how it feels from my perspective. I'm no mind reader either.

Jeez, so much rant so early in the morning. Need go code some more.

Offline Bob Strawn

Senior Newbie


Medals: 2



« Reply #39 - Posted 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.  http://eclipsetutorial.sourceforge.net/totalbeginner.html   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. 


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline HeroesGraveDev

JGO Kernel


Medals: 269
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #40 - Posted 2013-07-13 05:54:13 »

There is a huge difference between low-static and no-static.

The former is good.
The latter is stupid.

Also, your problem is not static. Your problem is bad code design. Pointing

Offline princec

JGO Kernel


Medals: 409
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2013-07-13 08:30:18 »

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.
That's not what we call a bug, that's a compilation error.

Cas Smiley

Offline relminator
« Reply #42 - Posted 2013-07-13 08:41:44 »

There is a huge difference between low-static and no-static.

The former is good.
The latter is stupid.

Also, your problem is not static. Your problem is bad code design. Pointing

Touché.

No-static proponents = walls of text.
Low-static proponents = 4 - 5 sentences of sensible arguments.

Let's drop Math from java!
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #43 - Posted 2013-07-25 12:28:13 »

Saying static is bad is like saying using new is bad, and threads, and nullable values, and using other people's code is bad.

If you don't know how to use it, you're going to have a bad time.

Offline jonjava
« Reply #44 - Posted 2013-07-25 18:43:41 »

Saying static is bad is like saying using new is bad, and threads, and nullable values, and using other people's code is bad.

If you don't know how to use it, you're going to have a bad time.

Using new IS bad! Well, it depends of course but what I'm trying to point out is the usefulness of factories!

Factories handle the creation of objects with the "new" keyword and also handles all their dependencies.

A crude example is if you want to create a mob in your game you'd need to do something like this without a factory:

1  
2  
3  
4  
5  
6  
{
  int x = 0;
  int y = 0;
  Mob m = new Mob(this, this.level, this.input, this.audio, x, y);
  this.level.entities.add(m);
}


With a factory you could do something like this instead:

1  
2  
3  
4  
5  
{
  int x = 0;
  int y = 0;
  this.level.entities.add(this.factory.newMob(x,y));
}

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #45 - Posted 2013-07-25 19:30:43 »

Saying static is bad is like saying using new is bad, and threads, and nullable values, and using other people's code is bad.

If you don't know how to use it, you're going to have a bad time.

Using new IS bad! Well, it depends of course but what I'm trying to point out is the usefulness of factories!

Factories handle the creation of objects with the "new" keyword and also handles all their dependencies.

A crude example is if you want to create a mob in your game you'd need to do something like this without a factory:

1  
2  
3  
4  
5  
6  
{
  int x = 0;
  int y = 0;
  Mob m = new Mob(this, this.level, this.input, this.audio, x, y);
  this.level.entities.add(m);
}


With a factory you could do something like this instead:

1  
2  
3  
4  
5  
{
  int x = 0;
  int y = 0;
  this.level.entities.add(this.factory.newMob(x,y));
}


I guess you've used 'new' for your factory somewhere, and I'm pretty sure those factories use 'new' too in some extra lines of code you didn't show Tongue
You can almost completely replace 'new' with for example an IoC framework, but that's imho rarely an advantage if all you want to do is release a small game.

I understand your point (factories are a useful pattern), but that's quite a sweeping statement.

Offline jonjava
« Reply #46 - Posted 2013-07-25 19:48:09 »

Of course the factories are using new somewhere. I just wanted to point out how simple factories (no need to import huge frameworks into your small games either) solves the problem that arises when opting to not use static methods.

If you're not using a factory, and not using static methods - then you're "stuck" manually inserting the required dependencies and references etc which is a huge pain that grows exponentially with project size.

In the crude example the missing factory code could simply be:

1  
2  
3  
4  
 Mob newMob(int x, int y) {
  Mob m = new Mob(this.main, this.level, this.input, this.audio, x, y);
  return m;
}

Offline gimbal

JGO Knight


Medals: 25



« Reply #47 - Posted 2013-07-26 12:15:49 »

Saying using new is bad is too black & white, I can't take such statements seriously and then as a result of that I can't take the person making it seriously to be brutally honest.

SOMETIMES a factory type solution makes sense. Sometimes a simple creation method is enough, no need to create new classes for such things. And sometimes just using new to construct an object is more than enough. And sometimes creating a singleton or using statics works.

Use the right tool for the job - that's the only pattern that applies always.
Offline ClickerMonkey

JGO Coder


Medals: 20


Game Engineer


« Reply #48 - Posted 2013-07-26 12:52:39 »

Using new isn't bad, but misusing it is (as in, you don't know when to use new and when to pool objects). That's my point. It all comes down to how large the object is, how expensive it is to instantiate, and how frequently you will be allocating temporary ones.

Offline jonjava
« Reply #49 - Posted 2013-07-26 15:02:25 »

Do people stop reading posts after the first sentence or paragraph and reply with their gut instinct?

I guess you've used 'new' for your factory somewhere, and I'm pretty sure those factories use 'new' too in some extra lines of code you didn't show Tongue

Of course, that's why I mention it in my original post.

Factories handle the creation of objects with the "new" keyword and also handles all their dependencies.

Saying using new is bad is too black & white, I can't take such statements seriously and then as a result of that I can't take the person making it seriously to be brutally honest.

I agree. A person who writes a review on a book based on the first sentence in the book is someone I also can't take seriously.

Use the right tool for the job - that's the only pattern that applies always.

I'm not so sure, sometimes using the tool that's already in your hand works just fine.

If you'd bother to read the whole post you'd realize it's about how useful factories are (especially in non-static environments) - not about not using new.

Using new IS bad! Well, it depends of course but what I'm trying to point out is the usefulness of factories!

Offline snacktime

Senior Newbie


Medals: 1



« Reply #50 - Posted 2013-08-04 20:01:21 »

Statics are often the only way to do certain things.  While I try to keep global variables to a minimum, sometimes the alternative is worse then just having a global.

The only architecture I've used that makes it easy to avoid any statics is something  like the actor model where everything is message passing.

Most of the time, statics in my code are reserved for thread safe variables that are used to share data across threads, such as thread safe queues or maps.  I also find that the need to use those  patterns shows up more on the server then the client.

I think a better overall goal to shoot for that will also give you very few statics is making your code thread safe.   There are a lot of advantages to being able to reuse chunks of client code on the server (game logic especially), and not being thread safe makes it a real pain.
Offline gimbal

JGO Knight


Medals: 25



« Reply #51 - Posted 2013-08-05 07:33:04 »

I'm not so sure, sometimes using the tool that's already in your hand works just fine.

I'll agree with you there for the sake of the argument.

Quote
If you'd bother to read the whole post you'd realize it's about how useful factories are (especially in non-static environments) - not about not using new.

Then why oh why did you have to muddy the waters by opening up with that statement? Because where I come from what you say first matters the most to you, the rest is to backup the statement you're making.

You can't blame me for misunderstanding you, you did it all by yourself. Thanks man.
Offline jonjava
« Reply #52 - Posted 2013-08-05 07:33:55 »

;'<

static variables aren't thread safe. You need to do things in synchronized {} blocks or use things like AtomicInteger and or use stuff from the java.util.concurrent package (like concurrent queues and maps etc)

http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html#package_description

Offline Danny02
« Reply #53 - Posted 2013-08-05 08:09:39 »

everytime someone posts in this topic a little kitten dies, sad day, sad day ... Emo
Offline ags1

JGO Wizard


Medals: 67
Projects: 3
Exp: 5 years


Make code not war!


« Reply #54 - Posted 2013-08-05 08:16:58 »

everytime someone posts in this topic a little kitten dies, sad day, sad day ... Emo

Not if it is a static final kitten... :-)


Offline HeroesGraveDev

JGO Kernel


Medals: 269
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #55 - Posted 2013-08-05 08:18:34 »

everytime someone posts in this topic a little kitten dies, sad day, sad day ... Emo

Not if it is a static final kitten... :-)



Not if we implement a kill function...

1  
KITTEN.kill();

Offline ags1

JGO Wizard


Medals: 67
Projects: 3
Exp: 5 years


Make code not war!


« Reply #56 - Posted 2013-08-05 08:19:46 »

True, but a static final kitten should be immutable.

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #57 - Posted 2013-08-05 23:42:19 »

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

One of the reasons why Eclipse (and any other IDE/engine) is lousy at tracking static variables is because doing so is a problem whose complexity grows exponentially.  I work for a static analysis company (not to be confused with static variables) and if you think about it, Eclipse is compiling the method behind the scene and then running through hypothetical execution scenarios to determine possible problems e.g. null pointer dereferences.

Static source-code analysis can easily track local variables because what can access that instance is limited to the current execution thread.  Static global variables, on the other hand, can be written to by any thread at any time!  Hence no assumptions can be made about what value it contains at anytime.
Pages: 1 [2]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

TehJavaDev (31 views)
2014-10-27 03:28:38

TehJavaDev (26 views)
2014-10-27 03:27:51

DarkCart (40 views)
2014-10-26 19:37:11

Luminem (21 views)
2014-10-26 10:17:50

Luminem (25 views)
2014-10-26 10:14:04

theagentd (31 views)
2014-10-25 15:46:29

Longarmx (61 views)
2014-10-17 03:59:02

Norakomi (57 views)
2014-10-16 15:22:06

Norakomi (46 views)
2014-10-16 15:20:20

lcass (43 views)
2014-10-15 16:18:58
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
java-gaming.org 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‑gaming.org
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!