Hi there JGO community!I just started working with a team of friends on a 2D RPG.We only have about a years worth of experience in Java in our College/University.So far we have written everything from scratch and haven't used any external libraries (everything is in javax.swing)Before we get any further than we are now, I'd like to stop and ask questions to see if we are on the right track,or if we are failing horribly and need to do things differently. The only things currently working are the map loading to the screen, and character movement. No collision yet.

A) The game is currently running as an applet. If the game doesn't turn out as horribly as we think it might, we will considermaking the game available to the public. Is this a viable way of putting the game out there? Or are there better solutions?

B) The map is stored as an array of ints. Each int corresponds to a tile in a switch statement. We currently only have about 10 tiles... but with any more I KNOW this will turn out bad. My idea was to have a tile class and work from there. Does that work?

C) When holding down a movement key, java starts to read the input about as fast as you can type in a text file by holding down a key. Is there any way to limit the input so the movement becomes "fluid"? It currently turns out as one step in any direction, followed by a slight pause, then the character will take off sprinting in that direction.

D) We were probably thinking too far ahead, but we tried making a save method. It gets called when a button was clicked on the applet, just as a test. It then exports the character position into a text file using PrintWriter, which could be loaded later on. Doing so would completely freeze the applet. My professor mentioned that the applet doesn't have permission to write on the C drive, and that may be why the applet freezes. Is this just a hindrance on our applet choice again? If not, are there ways around it?

E) As I mentioned we are only using java strictly and currently do not use any external libraries. Is there any merit at all to writing the game this way?Or should we start from scratch using something like slick2D? We are doing this as a learning experience and hope to be professional game developers someday. Is it worth it trying to "reinvent the wheel" so to speak and design the engine the way we are now? Or would we be better off implementing the things others have already figured out?

F) Probably the most important thing in my opinion to learn well at this level: ORGANIZATION. I feel as if we are doing too much in the Game class, and not enough in classes like Player, etc. How much should be done in the actual Main program? How much should be handled elsewhere? I know most organization is a matter of taste, but what has worked for you as far as doing things, and where you do them. The most typical error that I keep encountering is making a static reference to a non-static method/value which usually pushes me to write more in the main and less in outside classes.

Sorry for the extended noobness, but even the questions I thought would be simple on these forums turned out to be quite ahead of where I think we are as developers. Any help or ideas would be greatly appreciated (and also gets JGO in the credits when we finally finish a project )

EDIT(added (F) and this-->) FYI if anyone wants to see the abomination that is our current source code, feel free to ask. Your eyes may burn from looking at it.

Hi there JGO community!I just started working with a team of friends on a 2D RPG.We only have about a years worth of experience in Java in our College/University.So far we have written everything from scratch and haven't used any external libraries (everything is in javax.swing)Before we get any further than we are now, I'd like to stop and ask questions to see if we are on the right track,or if we are failing horribly and need to do things differently. The only things currently working are the map loading to the screen, and character movement. No collision yet.

A) The game is currently running as an applet. If the game doesn't turn out as horribly as we think it might, we will considermaking the game available to the public. Is this a viable way of putting the game out there? Or are there better solutions?

B) The map is stored as an array of ints. Each int corresponds to a tile in a switch statement. We currently only have about 10 tiles... but with any more I KNOW this will turn out bad. My idea was to have a tile class and work from there. Does that work?

C) When holding down a movement key, java starts to read the input about as fast as you can type in a text file by holding down a key. Is there any way to limit the input so the movement becomes "fluid"? It currently turns out as one step in any direction, followed by a slight pause, then the character will take off sprinting in that direction.

D) We were probably thinking too far ahead, but we tried making a save method. It gets called when a button was clicked on the applet, just as a test. It then exports the character position into a text file using PrintWriter, which could be loaded later on. Doing so would completely freeze the applet. My professor mentioned that the applet doesn't have permission to write on the C drive, and that may be why the applet freezes. Is this just a hindrance on our applet choice again? If not, are there ways around it?

E) As I mentioned we are only using java strictly and currently do not use any external libraries. Is there any merit at all to writing the game this way?Or should we start from scratch using something like slick2D? We are doing this as a learning experience and hope to be professional game developers someday. Is it worth it trying to "reinvent the wheel" so to speak and design the engine the way we are now? Or would we be better off implementing the things others have already figured out?

Sorry for the extended noobness, but even the questions I thought would be simple on these forums turned out to be quite ahead of where I think we are as developers. Any help or ideas would be greatly appreciated (and also gets JGO in the credits when we finally finish a project )

Welkcome to JGO!First of all with an applet you can easily show it from a webbrowse, where as a application is more for standalone purpose (this is what i know). For releasing it to the public, depends on what end. You mean selling? Or just freely distribute?

secondly, sure thats fine to do. Just think that it will save the images in the ram as you load them. So unless you are going to load huuuuuge maps at once, it should be fine. Look at one of my previous posts, i explained how you can easily set up a tile based map (Like what you are doing).

thirdly, i have had this problem as well, had to change a bit of my code to change it. Do you mind posting your movement code? So that i can help better with that.

for your savequestion, i have no clue. It should have acces i believe (i can easily store text documents and such) what are you using to save it?

And the library, i have not much information about this, but i believe that the original java libraries are more then fine, if you are not planning to use image scaling and transparancy (because this is supposed to go 'slow').Also, if you are looking for another member, id love to join . Programming in a group is so much more fun then doing it alone. Im currently making a rpg as well. Which is going quite alright (Finished inventory, scrolling map, movement engine, movement) so i think im able to help you guys out! ^^

ALso @ReBirth, i do not believe in this myth, its one of the best ways of learning to develop games in my opinion. Since youll have to look a lot up. And rpg covers many of the basic game principles.

Welkcome to JGO!First of all with an applet you can easily show it from a webbrowse, where as a application is more for standalone purpose (this is what i know). For releasing it to the public, depends on what end. You mean selling? Or just freely distribute?

secondly, sure thats fine to do. Just think that it will save the images in the ram as you load them. So unless you are going to load huuuuuge maps at once, it should be fine. Look at one of my previous posts, i explained how you can easily set up a tile based map (Like what you are doing).

thirdly, i have had this problem as well, had to change a bit of my code to change it. Do you mind posting your movement code? So that i can help better with that.

for your savequestion, i have no clue. It should have acces i believe (i can easily store text documents and such) what are you using to save it?

And the library, i have not much information about this, but i believe that the original java libraries are more then fine, if you are not planning to use image scaling and transparancy (because this is supposed to go 'slow').Also, if you are looking for another member, id love to join . Programming in a group is so much more fun then doing it alone. Im currently making a rpg as well. Which is going quite alright (Finished inventory, scrolling map, movement engine, movement) so i think im able to help you guys out! ^^

1) Awesome! We plan to freely distribute it depending on how it turns out.

2) I will definitely give your post a look. That should solve most of our problems with thinking the map will be too big. I'm assuming we would need some sort of event upon entering a door or such that tells it to load the map of the building, etc?

Ignore the test messages, I added those to see if the applet properly kept track of which keys were down/released.

4) We were trying it using print writer. My friend took care of that portion because I haven't personally done any file IO in java, only python in an intro programming course.

5) I think that would be great! :] We're trying to get more people on our team, ideally all in person so we can meet up and actually work for a few hours and not slack off on our own! If you have any extra time on your hands though, I think that would work out. I need to run it by them first though, or else we'll end up having another 10 people with access to our DropBox and that could get messy

What exactly do you mean by:"Do you have any input on items A-F at all, or anything else to add?"?

Next, I think you'd be better off rewriting everything a bit. Wat you are doing will be fine for small games. But it will be really chaotic if you make a bit bigger game. I suppose you have 1 class in which you both handle the movement, and the drawing?try and make it more like this:Draw class, in this you will draw everything.Player class, will handle movement and collision detection.In your player class youll need 4 funtions, 1 to handle the keyrelease, one to handle the keypress, an update function (So your player actually moves) and a draw function)I would love to explain it in detail, but my next lesson is starting soon. Ill explain it in detail asap (that is today, and when nobody has done it yet)

What exactly do you mean by:"Do you have any input on items A-F at all, or anything else to add?"?

Next, I think you'd be better off rewriting everything a bit. Wat you are doing will be fine for small games. But it will be really chaotic if you make a bit bigger game. I suppose you have 1 class in which you both handle the movement, and the drawing?try and make it more like this:Draw class, in this you will draw everything.Player class, will handle movement and collision detection.In your player class youll need 4 funtions, 1 to handle the keyrelease, one to handle the keypress, an update function (So your player actually moves) and a draw function)I would love to explain it in detail, but my next lesson is starting soon. Ill explain it in detail asap (that is today, and when nobody has done it yet)

Forgot to quote ReBirth on that post haha, whoops!

No, I perfectly understand what you mean. The code I posted was from the Main, so it looks like I'll be doing a lot of work today on the other classes, and calling them from Main to see if it all works But if you want an idea of how chaotic it would have been...all the drawing, movement, tiles, etc were all in the Main. The only thing I called from the Player class was the coordinates LOL.

Yes i used to have it all in 1 class as well in my first game (which was written in c++). Then the same in java.But its rather hard and chaotic to work with yes, plus the fact that all has to be done in 1 class, and without OOP (Object Oriented Programming) for which java is made for (to work with objects, same with c++).Plus the fact that you wont be able to multithread very easily (I can see it being done, but with a lot of effort and redundant code).I can help with FileIO . pm me your skype name, msn adress, email or whatever you prefer to comminucate.

A. That's up to you bro. I'm still figuring that out myself. Getting your name out is difficult to do.

B. The basic idea of what you're doing is right, it just comes down to how you do it. If you stick with an int[][] then you might consider an additional int[][] for each map for collisions to mark each matching tile as solid (So if you have a 8 x 8 tile number array, have another 8 x 8 array full of 1s and 0s to say what tiles are solid). It's a pain to update changes later on, but it's fine for your 1st game.

C. I know what is wrong here. It basically has to do with how the AWTEvent threads are managed and called. It's easy to correct though. Instead of increasing x or y in the keyPressed() method, set an xVelocity or YVelocity variable to the speed you want to move at (negative number to go left or up), then, wherever your player's updating code is done, simply say x = x + xVelocity (or x += xVelocity, same thing) and y = y + yVelocity. Just don't forget to reset your velocities to 0 if they release the key!

D. Your professor is mostly right. You can't have your applet write and read files on a person's computer (potential viruses and stuff) without signing the applet, which is a pain. The only other option that I know of is to use the JDBC library for reading and writing to databases. Since you're still learning, I'd recommend just doing an application for this one. Later on though, you'll probably want to write binary files but for now, .txt files are OK.

E. Most certainly stick to vanilla Java. Until you're at the point where you've written it a hundred times and it is just becoming leg work, pleeeeease write it yourself. You'll become a much better programmer that way.

Look up object 'serilization' for save games, and signing applets to store files on the clients computer if its going to run as an applet. Ive heard signing is annoying to do at first but it gets easier once you've done it once.

For the key input I use several boolean variables and if a key is pressed it changes that variable to true, and released it changes it to false. Then somewhere in the gameloop I have a method that just goes through those boolean variables and if one is true then do stuff. For example,

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

publicvoidkeyPressed(KeyEvente) {intk = e.getKeyCode();switch(k){caseKeyEvent.VK_A:game.keyPress[0] = true;break; ... // check other keys// then elsewhere in a method called from the gameloopprivatevoidcheckForInput(){if(keyPress[0]){player.setDX(-player.getRunSpeed()); }else{player.setDX(0); }// so on, so on

Look up object 'serilization' for save games, and signing applets to store files on the clients computer if its going to run as an applet. Ive heard signing is annoying to do at first but it gets easier once you've done it once.

For the key input I use several boolean variables and if a key is pressed it changes that variable to true, and released it changes it to false. Then somewhere in the gameloop I have a method that just goes through those boolean variables and if one is true then do stuff. For example,

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

publicvoidkeyPressed(KeyEvente) {intk = e.getKeyCode();switch(k){caseKeyEvent.VK_A:game.keyPress[0] = true;break; ... // check other keys// then elsewhere in a method called from the gameloopprivatevoidcheckForInput(){if(keyPress[0]){player.setDX(-player.getRunSpeed()); }else{player.setDX(0); }// so on, so on

This seems to get me nice smooth movement

I wouldnt say that is the best way to do it. After you update your game often and expand it a lot, what the hack is game.keyPress[0] then? and what is 1?I would just do it with 4 booleans, up down left rightThen pressing a, will set left. releasing a will clear left.Then make an update function, which goes trough all the possibilitys so in pseudo code:

I rather use the method me and embedded use. What is the advantage of yours over ours?Ours is easier to read, easier to implement and doesnt require another class. Doesnt need .getPlayer.All i need is this in my drawing class:

The player isnt actually moved it just changes his velocity. I do it this way becuase then its easier to implement stuff like gravity exct..He moves when the player.moveX() and player.moveY() methods are called, (there seperate for collision detection purposes)

The Controls should have its own class for modularization anyway and oftentimes there are commands that don't directly affect the player (like the pause button or the open inventory button). All keyboard Input goes in Controls and someone (including me) can take one look at Controls and can see how it works. Not to mention that if you throw GameStates in the mix (like a main menu gamestate where the arrow keys now select a menu item and don't move the player anymore), you'll regret not having it separated.

Keyboard Input doesn't belong in the Drawing class--drawing code should be in there.

My way only requires two descriptive variables that essentially handle themselves, where 4 booleans are involved in yours which is harder to read.

The getPlayer() should already be here because there will likely be other classes asking for the player. Seeing as how each part of the game stems from Game, it makes sense to have one place where it can be accessed.

The Controls should have its own class for modularization anyway and oftentimes there are commands that don't directly affect the player (like the pause button or the open inventory button). All keyboard Input goes in Controls and someone (including me) can take one look at Controls and can see how it works. Not to mention that if you throw GameStates in the mix (like a main menu gamestate where the arrow keys now select a menu item and don't move the player anymore), you'll regret not having it separated.

Keyboard Input doesn't belong in the Drawing class--drawing code should be in there.

My way only requires two descriptive variables that essentially handle themselves, where 4 booleans are involved in yours which is harder to read.

The getPlayer() should already be here because there will likely be other classes asking for the player. Seeing as how each part of the game stems from Game, it makes sense to have one place where it can be accessed.

Sorry i was mistaken, i meant to type that it is in my game class instead of my drawing one.Also i guess it goes down to own preferableness as well. I like having it in my player class. Since the player has to move with the keys, inventory from the player. Also how would you handle animation? just curious.And what is the advantage of using .getplayer() instead of making a static class where you make the player in?

And i disagree with the booleans. I dont see how this is harder to read in the slightest.

It isn't that it's more complex, it's more like it doesn't flow too well. This is how I see code:

The higher level of your code (main), should be as high level as possible. So, pretty much just start().

The next level should the design of the game and should be like 90% calling other methods. This is basically just your loop and input/output.

Next level is something like a player class where there are still method calls, but there's a lot more logic here. More like behavior.

Etc., etc., but it's definitely a tier system (to me anyway).

I think that at like tiers 1-3, the code should read as close to english as possible. (ie if (player.isAlive()) player.draw(g)

For animation I'd have an Animation class (in the Entity/Player class) that held an array of images and kept track of what frame it was on, and every paint(), player just asks the animation what frame it's on and draws it. Animation would be tier 4-ish.

You could do that as well. That just depends on how you want to keep track of entities. You could have an EntityManager or GameManager class that keeps track of that stuff. Either way, more or less all of your class-level variables should at least have getters.

Hi there JGO community!I just started working with a team of friends on a 2D RPG.We only have about a years worth of experience in Java in our College/University.So far we have written everything from scratch and haven't used any external libraries (everything is in javax.swing)Before we get any further than we are now, I'd like to stop and ask questions to see if we are on the right track,or if we are failing horribly and need to do things differently. The only things currently working are the map loading to the screen, and character movement. No collision yet.

A) The game is currently running as an applet. If the game doesn't turn out as horribly as we think it might, we will considermaking the game available to the public. Is this a viable way of putting the game out there? Or are there better solutions?

B) The map is stored as an array of ints. Each int corresponds to a tile in a switch statement. We currently only have about 10 tiles... but with any more I KNOW this will turn out bad. My idea was to have a tile class and work from there. Does that work?

C) When holding down a movement key, java starts to read the input about as fast as you can type in a text file by holding down a key. Is there any way to limit the input so the movement becomes "fluid"? It currently turns out as one step in any direction, followed by a slight pause, then the character will take off sprinting in that direction.

D) We were probably thinking too far ahead, but we tried making a save method. It gets called when a button was clicked on the applet, just as a test. It then exports the character position into a text file using PrintWriter, which could be loaded later on. Doing so would completely freeze the applet. My professor mentioned that the applet doesn't have permission to write on the C drive, and that may be why the applet freezes. Is this just a hindrance on our applet choice again? If not, are there ways around it?

E) As I mentioned we are only using java strictly and currently do not use any external libraries. Is there any merit at all to writing the game this way?Or should we start from scratch using something like slick2D? We are doing this as a learning experience and hope to be professional game developers someday. Is it worth it trying to "reinvent the wheel" so to speak and design the engine the way we are now? Or would we be better off implementing the things others have already figured out?

F) Probably the most important thing in my opinion to learn well at this level: ORGANIZATION. I feel as if we are doing too much in the Game class, and not enough in classes like Player, etc. How much should be done in the actual Main program? How much should be handled elsewhere? I know most organization is a matter of taste, but what has worked for you as far as doing things, and where you do them. The most typical error that I keep encountering is making a static reference to a non-static method/value which usually pushes me to write more in the main and less in outside classes.

Sorry for the extended noobness, but even the questions I thought would be simple on these forums turned out to be quite ahead of where I think we are as developers. Any help or ideas would be greatly appreciated (and also gets JGO in the credits when we finally finish a project )

EDIT(added (F) and this-->) FYI if anyone wants to see the abomination that is our current source code, feel free to ask. Your eyes may burn from looking at it.

A. Applets are mostly fine on Windows but they are quite unreliable on Linux and Mac. As beginners, it is best to stick with applets, indeed you get more feedback here in the forums if it's an applet

B. How will it turn out bad with more tiles? A Tile class that stores the 2D array should be good enough and dynamic enough for any tile map.

C. As others have pointed out (and ehm argued over ) the problem is with how keyboards work. Do you notice how when typing it only prints out 1 letter instead of many letters? This is because the OS only sends 1 initial event, followed by a slight pause, then if the key is still held down it delivers a continuous stream of events until the key is released. What you do is simply set a boolean flag (only useful if you have few keys you need to monitor) or better yet is to use an array so that the game loop polls the flags if the key is pressed or not.

D. Your professor is correct. Applets are limited in function due to security. They cannot save any files and cannot read from the user file system. They can only read from their current directory (the website) and their JAR. They also cannot connect to any IP address other than the website that hosts them. To enable these functions, you need to sign your applet, a relatively simple procedure that requires user permission for the applet to run.

F. Most would say that as long as you understand the code and can get something running quickly then that is best. Others would say that you need to stick with conventions, strict rules, and certain "traditional" game designs. I am in between. You should not get caught up in making these pretty and super organized but you should also not be slacking off and putting everything in your main class. Separate logic logically (hehe pun intended ). Code that controls the Player should not be in Game. Code that controls the Level should not be in Player. Most importantly, Logic should not depend on Rendering. Your render code should only depend on the available data.

Your error about using a static reference to a non-static method/value is most likely due to bad design. What I do is visualize the game design in your head. Think about the intended job of every piece of code. What does it control? Who calls it? Where does it make most sense to put it? If you have a hard time visualizing things, draw it out. White boards or a pen and paper are best for this. In fact, I absolutely recommend a white board to just brainstorm before you write a single line of code. Trust me, it will help.

About what ReBirth said considering "RPG as your first project", I do agree with that statement. An RPG is way too large for a first project. The probability that beginners give up in frustration due to unmanageable code, not enough understanding, and/or complete frustration is most likely 99%. Even though elamre pointed out that RPGs contain many basic game principles, usually it is too late to modify the entire code in a new way since it has become huge. Starting small and slowly getting bigger is always the best solution, in programming and in real life.

Wow so many replies! I see a lot of good things that will help me rewrite my mess of a program Medals for everyone! I'm still open for more input; it's likely that I'll try everyone's examples that they posted and see which one will fit bestwith the way my team wants the game to feel.

I'm still in shock that everyone has been so helpful and noob friendly. I think I'll be spending quite a bit of time here as I develop my java skills

And I guess to cut back on spam, I'll just continue to use this thread in-case I need help with anything! :]

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