Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
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  
  Avoiding redundant code at all cost?  (Read 3895 times)
0 Members and 1 Guest are viewing this topic.
Offline Kryel

Senior Newbie





« Posted 2012-11-15 18:48:47 »

Mainly a subjective question (a bit similar to my previous thread)

Let's say that I have a 2 classes : Player and Background. (it's just an example, I don't have them that way)
Eventually, I'll have to render them on the screen so they will, at least, both have :
- int x, int y, int w, int h (position) (or a vector, doesn't matter)
- float a, float r, float g, float b (color)
- more things (...)
There are lots of way to solve this, but what would be your approach? Make an intermediate class that will hold the values? Extend it? Integrate it as a parameter in both classes? Or simply copy'n'paste all those type of variables in all classes?
Even tough it's supposed to be good practice to avoid redundant code mostly for performance and/or evolution issues, we're just talking about int & float in modern applications here so does it really matter?
Besides not using an intermediate object makes it easier to access the value from an instance: pl.getX() instead of pl.getPosition().getX() for example. Using intermediate objects for redundant values seems the good way, but somehow when you start to have lots of classes, you just end up calling an intermediate value from another intermediate object from another intermediate object again.

One other thing, are you using interfaces a lot to implement common methods? What I mean by that is, most of the time, I find it easier to just make a Factory/Builder or whatever "Checker" class with statics methods to do the job. I don't know, for some reason I just enjoy making a pattern where I have ONLY values left, and ONLY methods right, not both in the same class, but is this really a good thing?
For example, instead of implementing an interface that would make my Player class have an "update" method, I'd just create an Updater static class (which will virtually be able to manage all kind of 'updates' needed for the game) that will make different things depending on the method I'm calling and with what parameters, like for the print :
- public void update(Player player)
- public void update(Background background)
I just don't like to have that "@override" method in my Player class, I'd rather have it hold important values only.

-----
Oh and on a side note : HOW THE HELL ARE YOU PROGRESSING IN YOUR PROJECTS?
Most of the time, I just take too damn much time thinking of things like the ones mentioned in this thread, even though I know it's a bad thing, but I can't stop  Angry
I seriously need to kill that part of my brain...
Offline sproingie
« Reply #1 - Posted 2012-11-15 19:49:49 »

In Scala, I'd tell you to use a trait, like Positionable, Colorable, MoreThingable Smiley  Java will have something similar in 1.8, but since we're looking for solutions now...  For your position/color/more-things needs, your implementation will depend on how generic you're trying to make your internals.  For most games, you can just stick the common code on an abstract GameObject base class and be done with it.  

If you're looking to keep those responsibilities orthogonal, then you're either going to have to put them on interfaces and copy the implementation to each, or delegate to another object.  In fact, even if you use an abstract base, it's still not a bad idea to still use interfaces and just make the base implement them.  The other approach as I mentioned is to delegate to some other object: a lot of game engines separate the Player/Mob/Item/Whatever class from the entity on the map by having them refer to a separate object it calls a "Puck" or a "Pawn".  

There's certainly nothing incompatible with using interfaces and factory/builder classes.  In fact, Java's Service Provider Interface, used in JDBC among other places, tends to work like that (in that you ask the DriverManager for an instance, you don't create a Driver yourself).  What you're talking about with your Updater class has little to do with factories and is basically procedural programming.  With enough discipline, that can be a sound methodology, but Java isn't ideally suited for that style.  Further, I'd keep away from all that ad hoc overloading, which doesn't enforce any kind of common contract of types or invariants.


Offline RobinB

JGO Knight


Medals: 37
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #2 - Posted 2012-11-15 19:59:04 »

It seems you like to scatter the class data in loads of other classes to avoid redurancy.
For small things this can be smart and stuff, but for bigger projects i would not recomment it.
I dont know how experienced you are with OO pragramming, but you should read some more about it, what you are doing looks more like C programming.
Object should hold their own data, if they share a lot with other classes, then use an extend or interface.

Singletons / Static classes should only be used for common functions like getFileData or loadFile.
If you have an project with 100 classes with all their own draw functions, how are you going to find the right function inside the (static) drawing class if you want to change one?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Kryel

Senior Newbie





« Reply #3 - Posted 2012-11-15 20:05:59 »

procedural programming.

Huho, I didn't think about it that way. Makes sense, I always used to code like that, maybe it's why I'm having an hard time figuring out things.

Well, It's not like I don't understand the point of having methods in a precise class (logic), but for some reason I always end up wondering : "Wait, what if I want that method to do more things? Receive more parameters? Or simply use it from another class?"
Mainly, this is why I'm using lots of "Updater" classes, since I just have to modify it and it won't have any kind of impacts on my existing classes. I'm sort of looking of a "safe" way to code, maybe. Usually I like to delegate actions to others objects, in the end I have LOTS of objects (or a big object doing all the things), it's just easier for debugging, I think...?

Funny, I did think about having a big "GameEntity" abstract class, which would be the mother class of all my others game objects, but then I realized that would be just "doing Java in Java", and thought I was just trying to reinvent some sort of wheel, which is a bad thing. Maybe I should have kept this solution.


It seems you like to scatter the class data in loads of other classes to avoid redurancy.
For small things this can be smart and stuff, but for bigger projects i would not recomment it.
I dont know how experienced you are with OO pragramming, but you should read some more about it, what you are doing looks more like C programming.

*Sigh* - Seems so, even though I actually never started a project in C or C++, that's the joke. (but with lots of language like it I admit)
Offline Cero
« Reply #4 - Posted 2012-11-15 22:41:16 »

game programming is a lot of hacking and getting things done

if you have an algorithm dont have it twice obviously
if two different things both have x and y, it would kinda overkill to create a class just for that

between that do whatever seems practical, understandable, and easy to handle - now and in the future

Offline Damocles
« Reply #5 - Posted 2012-11-15 23:13:45 »

redundant code can have its advantages

-when its very unlikely to get changed later
-when its used in complex specific behaviors that would take
a confusingly complex contruct to generalize it
-when there is a performance problem in a heavy loop (repeating the same instruction without looping back
can save some cycles)
-when it has to be edited a lot for specifc small changes (writing it like a cinematic script)


Also, not everything is a natural hierarchy. So dont overstrech the code to somehow
build an inheritance model if you talk about totally different elements.

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #6 - Posted 2012-11-16 04:00:53 »

-when there is a performance problem in a heavy loop (repeating the same instruction without looping back
can save some cycles)

I didn't realize people still manually unrolled loops.
Offline Damocles
« Reply #7 - Posted 2012-11-16 13:28:49 »

Ok, simple hacked testcode here to show the performance difference
while having the same outcome.
The unrolled loop runs about twice as fast as the normal loop on my JVM.

(observe the bytecode)

Did not check that with the Java 7 compiler though.

Unrolling the loop (partly - like a chunk of 5 to 10 repetitions) can make a huge difference when doing very heavy looped calculations.
Such as particle animation or pathfinding that actually impact performance.



1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
67  
68  
69  
70  
71  
72  
73  
74  
75  
76  
77  
78  
79  
80  
81  
82  
83  
84  
85  
86  
public class LoopUnrolling
{

   public static void main(String[] arg)
   {
      long time=System.currentTimeMillis();
     
     
      int a=11;
      a+=1;
      int counta=0;
     
      //rolled
     for(int i=0;i<1000000000;i++)
      {
     
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
      }
     
      //unrolled
     /*
      for(int i=0;i<100000000;i++)
      {
     
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
         
         a+=i;  
         if(a+i==a+i-a) a++;
         a-=i;
         counta++;
      }
      */

     
      System.out.println(a+"  count: "+counta);
     
      System.out.println("ms:"+(System.currentTimeMillis()-time));
     
   }
   
}

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #8 - Posted 2012-11-16 13:50:07 »

Manual loop unrolling can indeed have significant performance differences, even in real world code. It's good to also keep in mind that the JVM does loop unrolling itself already. I found that after 4 manual repetitions, there was barely any speed increase. But that was with vector processing code. In the end, the smaller the loop-body, the more you'll gain by manually unrolling it.

TL;DR: don't do it. persecutioncomplex

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Damocles
« Reply #9 - Posted 2012-11-16 13:54:43 »

Its a simple quadratic function.

The amount of saved loop-comparrisions decreases per more repeated functions.

So lets say 5 repetitions should be enough, after that it improves not much.

I would save this loop unrolling to the end of development, when you want to suqeeze some
performance out of it, and dont change this part of the code anymore.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2012-11-16 13:55:40 »

Didn't you notice that I agreed with your findings? Why explain it further?

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Damocles
« Reply #11 - Posted 2012-11-16 13:57:43 »

I like to brabble  Roll Eyes

Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #12 - Posted 2012-11-16 20:36:49 »

Regarding manual loop unrolling, it is really a last resort and you should never ever do it too early.
While it can make a noticeable difference in isolated code, in my experience it can actually hurt performance in larger projects quite a bit.

To give an example: Many years ago I developed emulators. The CPU emulation and rendering loops in particular were performance heavy parts, and quite early on I noticed that I could gain a bit of performance by manual loop unrolling, inlining code and huge look-up tables. I tried every low-level optimisation trick that I could find. Redundancy everywhere, making it difficult to maintain and debug, and making the code huge.
Not that long ago I tried to create another emulator, attempting to make the code as small as possible and avoiding as much redundancy as possible. The CPU emulator was less than about 1/3rd of the size of the old one. Everything was calculated on the fly (no lookup tables for flag registers and such). That code turned out significantly faster than the old code base, and was more accurate to boot.

Also, years ago I even created a generator of a 68000 CPU emulator that generated the code for every single instruction in an attempt to minimize branching and to make every instruction as fast as possible. The generated code was huge and optimal in theory if you consider the individual bits of code that emulated the CPU instructions. I'm pretty sure if you'd profile the individual blocks of CPU instruction emulation code, that it was probably as fast you could get.
In practice however, it was fantastically slow.
Another (hand-written) 68000 emulator that a friend wrote was an order of magnitude faster, so the 'optimal' generated CPU was abandoned and replaced by his.

I'm guessing that there are a few things that have caused this slowness:
1) A JVM has a difficult time deciding what to optimize if the code is huge and uniformly slow/fast. It might just decide not to compile anything if there are no hot-spots or if code blocks are huge.
2) Huge code might cause cache misses.
3) Branching code is not always as expensive as you might expect (perhaps a modern CPU often seems to do a pretty good job at branch prediction)
4) A JVM might usually be better at doing low-level optimisations than yourself.

The morality of this story: Stay away from manual loop unrolling and inlining and such. At least until your project is done and you've done your profiling. It's *very* difficult to tell what you have to optimize without seeing the big picture.
There are probably much smarter ways to optimize your program than to resort to low level tinkering. It will just leave you with huge blobs of difficult to maintain code.

Online Roquen
« Reply #13 - Posted 2012-11-16 20:59:02 »

Unrolling loops can also have a negative impact: increase i-cache requirements, blowing branch predictors, trace-caches, etc.
Offline erikd

JGO Ninja


Medals: 15
Projects: 4
Exp: 14 years


Maximumisness


« Reply #14 - Posted 2012-11-16 21:47:57 »

Roquen said in 1 sentence what I needed wall of text and years of messing around for  Grin

Offline BoBear2681

JGO Coder


Medals: 18



« Reply #15 - Posted 2012-11-17 04:46:49 »

Indeed, and hence my original statement.  Figured it went against the "write dumb code" mantra.  The JVM is supposed to be smart at optimizations these days, and surely loop unrolling is one of the simplest tricks it's got up its sleeves.
Online Roquen
« Reply #16 - Posted 2012-11-17 15:14:40 »

Back to the original topic:  data driven + design by composition = win.
Offline ctomni231

JGO Ninja


Medals: 71
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #17 - Posted 2012-11-18 09:13:07 »

I think all programmers go through a period where they question code redundancy. In Java, though, class structure and code redundancy is pretty common place. If we were to do true OOP, every single class would have getters and setters, and each class would be able to be taken from the main program without braking it critically.

I think actively trying to stop redundant code while writing the program is a lot of trouble. It is a lot easier to find redundant code when you are re-factoring and trying to find a better way to write it. Your thinking process should first be trying to get the code working before you even think about how redundant it is.

Even with everything that has been stated here. You are bound to have a bit of redundancy between classes to pass values from one class to another, and also one function to another. Trying to design a game perfectly is a great goal, but one that someone should strive for in timely steps.

Getting projects done is all mental. Like any good book, or game, or outside activity... I have to be in the mood to do it. I try not to force myself to program if my body (or brain) does not feel like it. It prevents me from getting frustrated, and usually when I'm doing other tasks a bolt of inspiration comes to me. At that moment, I try my best to it down somewhere so I can use it the next time I program.

My programming is a lot more productive, and I feel a lot better about myself. It was a lot better than staring at the computer screen for 5 hours with a pencil in my hand trying to solve that 1 bug. If you are not on a deadline, why work your brain and body out like it is? Relax and give yourself time to work out the problems.

Offline 65K
« Reply #18 - Posted 2012-11-18 09:41:19 »

In Java, though, class structure and code redundancy is pretty common place.
Code redundancy is common in Java ?

If we were to do true OOP, every single class would have getters and setters, and each class would be able to be taken from the main program without braking it critically.
Getters and setters are a characteristic of true OOP ?

Offline ctomni231

JGO Ninja


Medals: 71
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #19 - Posted 2012-11-18 10:15:18 »

Haha... well a representation of true OOP, yes. I was poking a little bit of fun at the fact that classes are supposed to be 100% modular. Therefore dependencies on other classes would be 0% and each class would therefore have to each hold its own variables accessible by getters and setters.

If you want to see Java code redundancy, then imagine how our each class would look if you couldn't write the "extend" clause. Every "Object" has the exact same functions... pretty redundant if you ask me.

It is amazing how many teachers I've seen teach it this way both in Java and C++.

Do I follow it? No way. Once you leave the confines of the classroom you realize that always following convention results in ridiculously slow code and Java Heap Space errors.

Offline 65K
« Reply #20 - Posted 2012-11-18 10:37:30 »

Haha... well a representation of true OOP, yes. I was poking a little bit of fun at the fact that classes are supposed to be 100% modular. Therefore dependencies on other classes would be 0% and each class would therefore have to each hold its own variables accessible by getters and setters.
For OOP, hopefully each class holds its own variables and hopefully they are not all accessible by getters and setters as that would break encapsulation and expose class internals.

If you want to see Java code redundancy, then imagine how our each class would look if you couldn't write the "extend" clause. Every "Object" has the exact same functions... pretty redundant if you ask me.
Then you would even more build an architecture from object composition instead of inheritance.
Can't see the relation to redundancy here, maybe I just don't get what you mean.

Do I follow it? No way. Once you leave the confines of the classroom you realize that always following convention results in ridiculously slow code and Java Heap Space errors.
I don't know any convention leading to heap space errors or generally slow code.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #21 - Posted 2012-11-18 10:53:29 »

I think the only thing that is to be avoided at all cost is *gasp* that the paying user/player runs into a bug.

Anything else affecting your code should be avoided, but never at all costs. Trying to refactor an existing codebase into a better design, over and over again, is exactly the reason the developers on this forum are barely productive. We have so few finished game releases per month that it's a bit shameful. Sometimes not having a fancy IDE is what makes you productive, because you simply have to move on with what you have and you just want to get it over with. The next game will have a better design, not this one.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline concerto49

Junior Member





« Reply #22 - Posted 2012-11-18 12:00:37 »

I think the only thing that is to be avoided at all cost is *gasp* that the paying user/player runs into a bug.

Anything else affecting your code should be avoided, but never at all costs. Trying to refactor an existing codebase into a better design, over and over again, is exactly the reason the developers on this forum are barely productive. We have so few finished game releases per month that it's a bit shameful. Sometimes not having a fancy IDE is what makes you productive, because you simply have to move on with what you have and you just want to get it over with. The next game will have a better design, not this one.

+1 to this. There's always a better way of doing something. It's an endless cycle. Where do you stop?

High performance, fast network, affordable price VPS - Cloud Shards
Available in Texas, New York & Los Angeles
Need a VPS Upgrade?
Offline Kryel

Senior Newbie





« Reply #23 - Posted 2012-11-18 12:34:30 »

I think the only thing that is to be avoided at all cost is *gasp* that the paying user/player runs into a bug.

Anything else affecting your code should be avoided, but never at all costs. Trying to refactor an existing codebase into a better design, over and over again, is exactly the reason the developers on this forum are barely productive. We have so few finished game releases per month that it's a bit shameful. Sometimes not having a fancy IDE is what makes you productive, because you simply have to move on with what you have and you just want to get it over with. The next game will have a better design, not this one.

+1 to this. There's always a better way of doing something. It's an endless cycle. Where do you stop?

Seconded.

As suggested earlier I've just stop trying to make it "pro" and start to use THE, or more like, MY easy way to code things, mainly to have at least different steps working for the game. Let me tell you that it works like a charm, not really a professional code but meh, it works, and more importantly I start to have fun again while coding.

( that awkward feeling of being stuck... I almost missed the time under Game Maker at some point, things seems more "easy & fun" to code script )
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #24 - Posted 2012-11-18 12:40:43 »

Regardless of your skill, you'll always look back at three year old code, and wonder what the hell you were thinking. Striving for perfection should be postponed indefinitely. Now get back to writing code making games, folks!

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Online Roquen
« Reply #25 - Posted 2012-11-18 12:52:01 »

I look at code I'm typing and think: "This is the worst thing on the planet...oh well, next".
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 605
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #26 - Posted 2012-11-18 13:16:27 »

I admire your discipline.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ctomni231

JGO Ninja


Medals: 71
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #27 - Posted 2012-11-18 18:15:33 »

...

If you want to see Java code redundancy, then imagine how our each class would look if you couldn't write the "extend" clause. Every "Object" has the exact same functions... pretty redundant if you ask me.
Then you would even more build an architecture from object composition instead of inheritance.
Can't see the relation to redundancy here, maybe I just don't get what you mean.

Do I follow it? No way. Once you leave the confines of the classroom you realize that always following convention results in ridiculously slow code and Java Heap Space errors.
I don't know any convention leading to heap space errors or generally slow code.

When I started with Java, I think it was on Java 1.4. I thought the class structure was awesome and attempted to solve every by just using Objects. However, when you go crazy with the idea and try to make simple things, like each car in a busy street, its own object. You end up with 1000 objects and code that ends up breaking down at the seams.

My definition of redundant code is variables and functions within a class that are written over and over if you can obviously use a loop, or functions that repeat from class to class that are not conventionally used. I like inheritance and extending code a lot, but it ends up a lot of times giving me functions with empty brackets.

I think you have a valid point Riven.

However, the people who come looking for help in a gaming development forum come for ideas on how to make their game code better. The most interesting part about JGO is that it is one of the best Java development forums even if you are not doing gaming. Eventually, they will end up trying the code that makes the code run better, and head toward re-factoring perfection.

I believe the community should strive to help users within the confines of the framework they are in. If a user in working in Java2D, help him/her make the program in Java2D. Don't try and tell them to convert to Slick2D or LWJGL. Same for those users working with Slick2D, we shouldn't try to convert them to LibGDX. If they had a problem grasping the concept within Java2D, changing to a new framework (or language) is going to cost them even more time. The saddest part is the problem they had in the first place will just follow them to the new framework. (It is the same reason why it doesn't make sense to fix a bug by changing from Java to Python.)

Creating games is another layer of difficulty beyond just being a good programmer who is using the right tools. We really have some really powerful tools when it comes to game development on this forum. However, the key to building any structure is knowing what tools would get the job done. Do you need 1000 FPS and 3D graphics to develop Pong, for instance? Probably not, so why over-complicate it.

I realize all programmers are good at building tools. We like to have classes that do specific tasks and do them well. Somewhere in all of that, we lose the ability to convert the tools we write into games. We feel that since we spent "X hours" on this tool, it has to fit in the game somewhere. We never sit down and ask ourselves, "What is the core idea of this game? What is my game about?"

If we did that more often, we'd realize that our code is expendable. That we don't have to use every single tool we write (or every framework we come across). We would realize that trying to fit a square peg into a round hole is a big waste of time.

You write code to build your game. You don't write games around your code.

Building games is the ability to realize that your code isn't perfect. You will have to dump code to get your game running. If your code looks like an unreadable jungle, keep going and hacking away at it. No one gets it right the first time. As a gaming community, I wish that this notion was the defining factor... but, I think we are just way to preoccupied for writing the best tools to get any real games done.  Tongue




Offline Kryel

Senior Newbie





« Reply #28 - Posted 2012-11-18 20:13:38 »

I wonder if it isn't that which is slowing game developers? Or at least hobbyists.

I mean, so far, I've been struggling to make several tools, supposedly to help me building my engine, supposedly*2 to make the game easy to create in the end.
But I may admit that sometimes, you're just not motivated.
Having a tool isn't necessarily a step in the game creation, so when I'm stuck on on I just feel like I'm not progressing and start to lose interest gradually over it.

Well, since I already went over that part using Game Maker (still, making the tools was funny because it was like creating a game for a game), I know that this kind of pain is definitely worth it. But sometimes, the motivation is just not here, so you just end up browsing JGO or playing games instead of making them  Grin
Online Roquen
« Reply #29 - Posted 2012-11-18 20:47:39 »

I admire your discipline.
Not discipline...self awareness.  The vast majority of the time the temptation to re-write, do fancy stuff, etc, in my case would only serve the purpose of proving to myself how clever and/or knowledgeable I think I am about coding.  SO, instead I do nothing and pat myself on the back for how clever and/or knowledgeable I think I am about about getting stuff done.  Scratch the same-ish itch in a different way and in less real-time.
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.

xsi3rr4x (12 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (24 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
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!