Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (512)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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] 3
  ignore  |  Print  
  Game Internal Organization?  (Read 12120 times)
0 Members and 1 Guest are viewing this topic.
Offline divxdede

Junior Duke





« Reply #30 - Posted 2012-05-10 06:21:15 »

I can't stress enough how important a proper amount of sleep is: developing is 80% debugging*, and with enough sleep, you write fewer bugs, find the remaining ones faster, etc.
I completely agree. There have been numerous instances where I've rage quit and gone to bed because I couldn't fix a problem....only to have a EUREKA!! moment as soon as I woke up Smiley

my EUREKA time becomes often in the bathroom...
Offline ra4king

JGO Kernel


Medals: 350
Projects: 3
Exp: 5 years


I'm the King!


« Reply #31 - Posted 2012-05-10 07:11:24 »

O_o are you saying that you spend most of your time in the bathroom or the...peculiar environment of the bathroom causes your mind to go on overdrive? Shocked

Offline 65K
« Reply #32 - Posted 2012-05-10 07:15:01 »

I may also be considering adding multiplayer co-op, seeing as I can just send the Seed for the dungeons to each player and just have an entity list sync. Which shouldn't be too hard in theory, but please feel free to enlighten me.
A multiplayer architecture should definitely planned from the very beginning. Adding it later means writing a new game from scratch.
Implementing a good real time multiplayer mode I would call one of the hardest tasks of all.

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

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #33 - Posted 2012-05-10 07:36:48 »

Lately I find game development is 90% playtesting and then twiddling something to try and make it more fun :/ I am so utterly sick of the sight of Ultratron. Two solid months so far on a game that looks like it took two days to make. I have no talent whatsoever.

Cas Smiley

Offline ReBirth
« Reply #34 - Posted 2012-05-10 07:44:50 »

After deliberating for 2 pages, not a single rule about this was fixed~

Offline tom
« Reply #35 - Posted 2012-05-10 08:51:31 »

Generally stay away from the Static key word.
Static data is bad. Static functions with no side effects are good.

Btw, interesting read: http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/

Offline Roquen
« Reply #36 - Posted 2012-05-10 08:53:46 »

Quote
Static data is bad.
Overgeneralization is bad.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #37 - Posted 2012-05-10 08:56:36 »

I use static data all over the place. Win!

Cas Smiley

Offline jonjava
« Reply #38 - Posted 2012-05-10 09:04:34 »

Yeah, I wanted to be a super programmer so I never used statics. Then I got lazy and now I use a few static classes/data when appropriate. There's really no reason for me not to use a few static classes/data for my own shitty small games Tongue

However, in bigger projects methodologically cutting the static data use gives super cool superpowers and actually cuts debugging time tremendously. (I've no first hand experience of this but I think it's true, it makes sense).

Offline delt0r

JGO Knight


Medals: 27
Exp: 18 years


Computers can do that?


« Reply #39 - Posted 2012-05-10 09:10:57 »

I gave up on avoiding statics. Its just easier to get the job done. And its not difficult to read. If the use case changes, it  is not hard to change. 

I have no special talents. I am only passionately curious.--Albert Einstein
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #40 - Posted 2012-05-10 09:54:23 »

As soon as a static becomes a problem, the Refactoring Fairy waves her magic wand and the problem magically disappears.

Cas Smiley

Offline jonjava
« Reply #41 - Posted 2012-05-10 10:02:48 »

Refactoring fairy?? o.O

Offline Damocles
« Reply #42 - Posted 2012-05-10 11:06:00 »

Theoretically static data is bad.
But theoretically a bumble-bee can not fly too.

Somehow it works, and is obviously practical.

And gamedevopment is not the same a business-process imlpementation.
The designpatterns try to cover the more corporate oriented approaches (wich is needed)

A game has other qualities, and other types of teams and development cycles (and payment   $$ vs $$$$$$$)

Offline gouessej
« Reply #43 - Posted 2012-05-10 11:15:28 »

Imagine that your girlfriend or your boyfriend becomes extremely ugly, I assume you won't want to spend any time with him/her.

Shocked
Ok I was a bit rude but that was a kind of joke, this remark should not be taken as a face value. Anyway I don't want to spend any time in unpleasant code except with a compensation (money). Actually, that's what I often already do at work  persecutioncomplex

Offline loom_weaver

JGO Coder


Medals: 17



« Reply #44 - Posted 2012-05-10 13:05:14 »

So, I'm rebuilding my game engine for a slightly fresh start; I'm going to use all of my resources and what-not so that the game will be back to where it was in a week or two, but this time I want it to be pleasing to open up.

Just avoid second system syndrome.  I did that once with an online registration system for karate tournaments.  The first attempt took me about two weeks using servlets and a little JSP and I had something working.

The second time I used JSF (even wrote a custom component), put in localization (that I didn't need), and 2 months later the database schema and codebase turned into an unholy design-pattern tower of Babel.

I've learned my lesson.  Now whenever I code:

1. Add something new
2. Get it working while disregarding all design patterns
3. Refactor until you can stand the code-smell
4. Goto 1

If you ever find yourself blocked, then get lots of sleep and go for a walk while mulling it over.
Offline davedes
« Reply #45 - Posted 2012-05-11 00:36:46 »

Quote
A multiplayer architecture should definitely planned from the very beginning.
Yep, multiplayer should definitely not be an afterthought.

Other than multiplayer, these should also be considered:
- Who is your target audience?
- What is your target platform? i.e. Android support should also not be an afterthought.
- What's the art style and how it will affect development?

Offline SwampChicken
« Reply #46 - Posted 2012-05-11 03:09:21 »

Carry around a notebook to scribble down ideas.
(I always get the best game ideas at worst possible times, like sitting in a dentists chair)
Offline ReBirth
« Reply #47 - Posted 2012-05-11 04:36:24 »

That Static thing again? static is good.

Offline Roquen
« Reply #48 - Posted 2012-05-11 04:49:37 »

The Refactoring Fairy doesn't get enough love.  "Hey! Let's spend a bagillion man-hours writing abstractions to deal with extremely hypothetical future problems!"  Screw-that. Love the fairy.
Offline 65K
« Reply #49 - Posted 2012-05-11 05:24:54 »

Refactoring... yep, one of my favorite activities. One point why modern IDEs are such an important part of the whole development process. And one of the few advantages when you're on your own cause you don't bother no one with constant renaming, moving and the like.

Static... well, use it when it makes sense, naturally. Only that more often it doesn't. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #50 - Posted 2012-05-11 05:47:43 »

Static... well, use it when it makes sense, naturally. Only that more often it doesn't. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

So far in my *cough* "games" *cough* I've been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images
  • .
Is this a bad way of going about this?
Offline davedes
« Reply #51 - Posted 2012-05-11 05:49:48 »

Quote
Static... well, use it when it makes sense, naturally. Only that more often it doesn't. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.
Quote
So far in my *cough* "games" *cough* I've been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images

Is this a bad way of going about this?

In my opinion, we're talking about two types of programming here: practical and theoretical.

Practical programming means getting shit done. If you save a week in the long run by scrapping your large object-oriented entity system and replacing it with tons of static references, then by all means have a field day.

Theoretical programming means doing it the way you would, say, if 100 professional Olympian game programmers were all assigned to create a video game on a 10 billion dollar budget over the course of seven years. Object-orient the shit out of that.

Both ways are important to learn, neither should be discouraged, and the best indie games generally strike a balance between the two.


Gjaller:
My last game did something similar, although using a hash map so I could access the images by name. Let's just say, during the game's public exhibition, none of our users noticed, cared about, or even understood our code. Grin

Offline sproingie

JGO Kernel


Medals: 202



« Reply #52 - Posted 2012-05-11 06:10:29 »

You want a singleton, learn how to use Guice or PicoContainer.  You really think it's ivory-tower egghead abstract theory just to avoid using static?  How about just the most basic ability to test things?  That's practical, right?  I get the feeling like most advice is being handed out by people who just don't understand the alternatives or won't even bother to learn of them.
Offline 65K
« Reply #53 - Posted 2012-05-11 06:11:23 »

Static... well, use it when it makes sense, naturally. Only that more often it doesn't. For everybody interested in really learning OOP, I strongly recommend against it. It just leads to bad habits, and in the worst case, in an arbitrary mixture of static and non-static. Also good to learn the annoying parts of todays OOP.

So far in my *cough* "games" *cough* I've been using a single class as an image-loader and put all the loaded images in a public static BufferedImage Array. So every class can easily access the sprites through ImageLoaderClass.images
  • .
Is this a bad way of going about this?
What does static actually mean ? In your example, it means that all image loaders share the same set of images. Is that correct ? Very likely not. If you say you only need one image loader anyway, then maybe use a static image loader, but static images inside the loader is not bad but wrong design.
And making it public is the second broken encapsulation here.
Static breaks encapsulation because members are no longer private to specific objects.

Encapsulation is really, really important to keep software maintainable and stable.

Offline ReBirth
« Reply #54 - Posted 2012-05-11 06:27:21 »

Quote
Static breaks encapsulation because members are no longer private to specific objects.
Public is, not static. FTFY.

Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #55 - Posted 2012-05-11 06:29:02 »

This might almost be a little thread-hijack, sorry about that, but now I'm really curious about what is bad about this code.  Grin
Yes, I'm still quite the newbie.

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  
package loaders;

import java.awt.image.BufferedImage;

import javax.imageio.ImageIO;

/**
 * Ist für das Laden der Sprites zuständig.
 */

public class ImageLoader {
   
   /**
    * Speichert Sprites für die Achsen und den
    * Start-Bildschirm.
    */

   public static BufferedImage[] image = new BufferedImage[4];
   
   /**
    * Läd sämtliche Bilder aus dem "resource" Ordner und speichert
    * sie im BufferedImage Format.
    */

   public ImageLoader(){
     
      image[0] = loadImage("title");              //Title "S.T.E.P.S."
      image[1] = loadImage("deco");      //Deco für Title-Screen

   }
   
   /**
    * Läd die einzelnen Sprites.
    *
    * @param title Titel/Name des Sprites.
    * @return Gibt das zu ladende Sprite zurück.
    */

   public BufferedImage loadImage(String title){
     
      try{
         BufferedImage image = ImageIO.read(ImageIO.class.getResource("/resource/" + title + ".gif"));
         return image;
      }
      catch(Exception ex){
         ex.printStackTrace();
         return null;
      }
   }
}



Just ignore the javadoc. That code is part of my diploma and I had to comment everything nicely.
Thanks in advance  Smiley

edit:
Then I create an object of this class when the user starts the program, so the images get thrown into the BufferedImage Array.
And then I simply use it in other classes like so...

1  
g.drawImage(ImageLoader.image[0], x, y, null);
Offline ReBirth
« Reply #56 - Posted 2012-05-11 06:35:58 »

These's not all, but here some points:
1. You use magic constant in indexing the array
2. If you won't do anything to them except be drawn, use Image
3. It may be no sense but try change it to singleton

Offline Gjallar

JGO Coder


Medals: 13
Projects: 1


Follower of Nurgle


« Reply #57 - Posted 2012-05-11 06:41:56 »

These's not all, but here some points:
1. You use magic constant in indexing the array
2. If you won't do anything to them except be drawn, use Image
3. It may be no sense but try change it to singleton

Sorry, it might just be the fact that it's quite early in the morning but i hardly understood anything of that.

1. magic constant? do you mean that the size of the array is 4? i deleted some of the code, it actually does store 4 pictures
2. Use Image instead of BufferedImage, I guess I understood that. but why?
3. Singleton  Huh
4. Sorry and thank you  Smiley
Offline 65K
« Reply #58 - Posted 2012-05-11 06:55:28 »

Quote
Static breaks encapsulation because members are no longer private to specific objects.
Public is, not static. FTFY.
Don't know what you actually mean here.
In the example, encapsulation is broken twice: by using public fields and by static, because image loaders do not hold their own private encapsulated images, but share them with other loaders.

Offline davedes
« Reply #59 - Posted 2012-05-11 06:56:21 »

1.
An array is a poor way to store your images. What if you have 40 images after some more work on your game? How will you keep track of them all?
HashMap at the very least would allow you to store them by name.

2.
You should definitely encapsulate your methods (getImage/setImage/etc). Don't use public fields unless they are final.

Quote
1. magic constant? do you mean that the size of the array is 4? i deleted some of the code, it actually does store 4 pictures
2. Use Image instead of BufferedImage, I guess I understood that. but why?
3. Singleton  Huh
4. Sorry and thank you
1. Magic number = Value with little meaning that should be replaced by a constant or some other means. i.e. If you have 40 images, using number 25 for the "player walk forward" image is arbitrary and poor design, whereas you could have used a final static int called PLAYER_WALK_FORWARD. The latter will lead you to less errors and easier debugging in the long run.
http://en.wikipedia.org/wiki/Magic_number_%28programming%29

2. This allows you to use ImageIcons and VolatileImages without needing another list, as they all rely on the Image class for rendering (ImageIcon through getImage).

Following the same logic, let's say you have a method that looks like this:
1  
2  
3  
public void hide(JFrame f) {
  f.setVisible(false);
}


Since all you need is setVisible, you should use Component instead (which is where JFrame inherits that method from):
1  
2  
3  
public void hide(Component c) {
  c.setVisible(false);
}


Later on, you can then use that method for any component that extends Component. It makes your code more flexible for yourself and others.

3. I'll let you google that.

Pages: 1 [2] 3
  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.

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

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

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

lcass (35 views)
2014-10-15 16:18:58

TehJavaDev (65 views)
2014-10-14 00:39:48

TehJavaDev (65 views)
2014-10-14 00:35:47

TehJavaDev (55 views)
2014-10-14 00:32:37

BurntPizza (72 views)
2014-10-11 23:24:42

BurntPizza (43 views)
2014-10-11 23:10:45

BurntPizza (84 views)
2014-10-11 22:30:10
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!