It has been a while since I studded this but here is my take:

Relationship generally refers to inheritance ie the cat class inherits attributes from the mammal class thus the cat class is a child of the mammal class. However most of the time you don't need such complexity. Unless you are using Controller as some sort of basic template from which all objects in your game inherit you don't need item to be a child of it. Instead make the values of the Item class you want visible "public" or use accessor functions.

Remember hiding information from the player doesn't mean you need to hide information from yourself.

[Guns of Icarus Online]

Guns of Icarus Online
I play because I like bossing people around. The game relies heavily on in game voice communication to communicate between a 4 person crew on an airship. The person at the helm is designated the captain and is generally accepted as the one calling the shots. Since success or failure of the team depends heavily on the captain's decisions most people don't like being captain, but I love it. I love telling people what to fix and who to shoot at with my voice while my hands maneuver an airship. It is like playing two games at once, and is really exhilarating if I do it right. Also doesn't hurt that the game is more about planning ahead than twitch reflexes.

I like the idea but I don't like how you presented it. The bundle implies you are cutting people a deal by combining things together. It would look better if you put it forward like a magazine or newsletter. Instead of selling other people's work, sell your own work as a reviewer/hidden gem finder. There is a lot of freeware games out there. Ludum Dare churns out 1000+ every few months. There is too much noise for the average person with a job and other hobbies to seek out good freeware games. I would be happy to fork over a few dollars/put up with some banner adds to have some one else wade through the tons of freeware games out there to find hidden gems. That way I could be the first one in my group of friends to "discover" something interesting.

Edit: Oh and post screen shots, lots of screen shots. Many freeware games are uploaded without any thought of presentation. If you do this, you would be making a pre download presentation for the developers.

If you are looking for like minded people in your area I find Meetup.com to be a useful tool.

http://www.meetup.com/

Just don't expect to meet 5 year industry veterans who can show you how to turn your dream into a reality. Most of the people I have meet through Meetup.com are hobbyists with less game development experience than I have.

Designing for the tools you know is always a good idea. Further more designing for what you can make is what separates designers from day dreamers.

As for the menu system I have experimented with a few different techniques. If the game engine I am working with does not natively support a menu system I like to have one Master menu class which toggles between the currently active screens, and one class per menu screen. A static function in the master class can be called by the menu screen classes to toggle which screen is active.

The camera lag statement isn't true is it? The lag comes from the processing time, not the time it takes light to travel to the machine. If we do faster computers, software, we win!

While the camera lag may be resolved by faster processors the human lag issue will still be present. The actions of many video game characters are super human, trying to do a 1:1 interface between an actual human to a superhuman character will result in a very clumsy play session.

Think for a moment of the random flailing of "Star Wars Kid" compared to the game play of any street fighter game.

There's a lot of requests for information regarding the design document so I post the disclaimer so that you know where are stepping.

A design document is intellectual property as an art piece is, or any other work that you develop, I show a part of a under development project, that does not mean i giving up the game copyright's to ta discuss forum, blog or any kind of public forum entity or agency,  or individual person, private or public corporations. All rights are  reserved!!!

I think you worry too much about people stealing your ideas. Unless you are some creative genius a design document isn't worth very much on its own. Also throwing around legal terms while asking for help will drive the people you need away. If your project fails (as most of these internet collaborations do) any one who works with you will have to worry about you suing them should they have any success in the future.

Big companies can get away with non disclosure agreements because they are paying their developers upfront. Most programmers and artists are ok signing away the opportunity to make a similar game some time in the future if you promise to pay their rent and feed them in the now.

The interest in your design document is mostly academic. We want to see what kind of designer you are. We want to know how you think a user will interact with your game world. Most importantly we want to know how well you can communicate some thing as nebulous as the "feel" of a game.

I am of the philosophy that realism and actual physics should take a backseat to fun and interesting mechanics. We call things plasma guns because "plasma" sounds cool not because we are interested in heating and compressing matter until it reaches the 4th state.

With that in mind here are some suggestions for different gun/weapons that can break up the normal point and shoot dynamic:

Two part explosive gun:
Has two components: a "water" balloon launcher and rapid fire ice crystal shooter. Ice crystal shooter acts like a normal bullet, however if you "prep" and area with a "water" balloon the ice crystals result in minor explosions. Works of the principle of a two part explosive, where two inert chemicals become unstable when joined.

Mono filament nail gun:
Gun shoots paired bullets connected by monofilament wire. The bullets embed into walls. The ensuing web of monofiliment acts as area denial since mono filament is very hard to see and cuts through whatever tries to pass through it.

Constructive interference sonic cannon:
Useless by itself but when multiple teammates are using the gun and focused no the same target the guns synchronize to make a constructive interference wave pattern which causes the target to vibrate until it shatters. Vibrations represented as motion blur applied to the target object, or from the target object to the rest of the world. The more sonic cannons align on a single target the faster it shatters.

Bio-swarm gun:
Gun shoots a sticky pheromone pouch as its primary fire. Secondary fire opens up the doors to a wasp nest carried as a backpack. Wasps will swarm attack anything that has a pheromone pouch stuck to it. Pheromones have a limited duration and when there are no more pheromone pouches active the wasps return to the nest. The more pheromone pouches active in the game world the less the wasps will concentrate on one target. Wasps may have a limited life span and are bread in the nest.

I once made a platforming game with WASD and mouse free aim. It turned out pretty bad. While unrealistic, confining the users aim direction to horizontal or some fixed angles leads to more challenging game play.

You should pick the control schema that works well with the game dynamics you are trying to create. Sometimes less is more.

I have not played Bioshock Infinite or The Last of Us, but I hear those games are very much centered on an NPC. The player still gets to be the main hero but I hear the stories revolve around the main NPC not the player themselves.

I was also thinking Brock Samson from Venture Brothers as a non title character whose roll in the story is to violence things up.

Then again "Enslaved Odyssey to the West" was built on a similar mechanic and was largely disliked for it.

I think a good game to build off this mechanic is some sort of detective mystery where the player is Watson to an NPC Sherlock. You can assist with the investigation by pointing out clues that Sherlock would eventually find, but your main roll would be to beat up the thugs trying to prevent Sherlock from finding the truth. One of the big problems with Mystery games are players and developers not thinking along the same lines of what is obvious and what is not. By adding an NPC whose main job is to resolve the mystery the writer can build a more complex narrative without worrying about players who don't get it enough to advance the plot.

Many games these days try to convince the player that they are the hero and that their decisions matter, even as they railroad them down a linear plot. What if instead developers embraced medium's linearity and made the player the sidekick to the story's protagonist?

Important dialog between the protagonist and antagonist would occur outside the the player's control. Thus negating the dissonance one feels when their imagination of their character's motives do not jive with the dialog the developer's created.

There will always be a mission giver and a tutor in the NPC main hero. Since the Sidekick hero relationship is always a subservient one; there will also be less of the "I am trying to save the world, why am I running fetch quests for you?" or "My character is a highly trained secret agent, why do I need you to explain how do this simple task?"

Often people imagine themselves into the roll of the sidekick because the protagonist is too strange or unrelatable. Dr Who is an excellent example of this. The Doctor is a 1000 year old alien with almost unlimited knowledge of every civilization and alien in space and time. He has eccentricities that make him fun to watch but hard to predict.

Most people image themselves in the roll of one of his human companions who learn about the universe through him, fight the monsters, and help the doctor escape when he is captured. The doctor, in game terms, acts as the ultimate NPC; he gives quests, opens doors, and serves as exposition for some of the more nonsensical parts of the universe. Where as the companion is very much the player. They have to learn the rules of a world that is strange and new to them. They carry out the physical tasks the doctor is unable or unwilling to perform.

I am not proposing any particular game or universe with this post. Just the idea that it is easier to push a narrative along in a game if the player is not directly controlling a key actor in that narrative. Having the most relatable character not be the protagonist is well established in other mediums as the companion or sidekick.

I am in for the jam. Some of my non game development friends are tired of me talking about Ludum Dare and say they want to help. If the theme permits I will take a series of digital pictures of them against a green screen and turn them into game sprites. Perhaps involve them in level design too.

Take the next logical step and make them swappable characters in a team rather than pieces of equipment.

There are already games like that, Baulder's Gate and Mount&Blade come to mind. The sentient equipment idea has merit as it would allow for dialog and character development without the need for friendly NPC AI. Also it would lead to hilarious in game dialog.

*player takes hit*
Armor: Who do you think you are? You can't touch this boy!
Sword: Ugh... so little class
Armor: I don't see you keeping the main man safe
Dagger: At least you two get some action, last foe I skewered was yesterday's chicken dinner.
*player throws dagger*
Dagger: I take it back. I take it back. I take it back.

Back in the mid to late 2000's before the rise of massive game jams there was this game development community based around the allegro C++ library. This community would hold game development events similar to Ludum Dare, but with different rules. One of my favorite was Xmass Hack. It was a cross between a game jam and a secret Santa gift exchange.

Participants would submit three game ideas to the contest. There would be a brief voting period where participants would vote on the game ideas they would like to do. After that the event organizer would assign each participant with the idea wishlist of another participant. Once you had the wishlist you had to make a game that satisfied at least one of the requests. The games would be made public Christmas morning.

I participated in the '06, '07, '08, and '09 events, creating a simple game each time. I also received 2 games made from ideas I submitted. The event has not been run since '09 and I miss it. I wanted to share this nostalgia with the rest of TIG Source. I know there are some old Allegro.cc members lurking around here.

Below is the link to Xmass Hack's main page:

http://xmashack.wasyl.eu/

[Delivery Wars:]

I don't have the time, money or, resources to make this, but for kicks and giggles I am posting the general idea:

Delivery Wars:

Elevator pitch:
Delivery Wars will be a team based combat driving game about two rival fast food delivery services attempting to put the other out of business. Play occurs in a sprawling metropolis complete with NPC pedestrians and traffic. Players have two objectives, deliver orders from restaurants to people's homes as fast as possible, and prevent the other team from delivering their orders with guns and ramming. Successful deliveries will result in money and increased market share. Money can purchase upgrades for the players, while market share will determine the frequency of delivery orders. The Goal is to acquire 4/5's of the market share.

Game Mechanics:
Situated through the play area are restaurant franchises of the two competing chains. A map will flash when a franchise has a delivery pending. When the player reaches the delivery pickup point they get a new icon on the map indicating where the delivery needs to be taken. A timer is also started to indicate how much time is elapsed on that delivery. A delivery may be canceled if it takes too long and extra money is earned if the delivery is extra prompt. If the player is killed on the way to the delivery, the package is dropped where they fell and any one else on the player's team can pick it up and finish the delivery.

The opposing team will also be making such deliveries at the same time. If a player encounters a member of the opposing team trying to make a delivery the player can attempt to kill them with guns or ramming. The player can not destroy the delivery order but can camp it, picking off any opposition attempting to finish the delivery (until the order is canceled).

Successful deliveries earn both the player and team money. Collateral damage to NPC pedestrians and vehicles will result in a trivial penalty to the player's money. Killing members of the opposing team will not result in extra money, but will indirectly increase market share which will provide more opportunity to make money.

AI delivery drivers may be provided to make up for a lack of players.

In game money is persistent only for the game play session. It can be used to buy better vehicles, upgrade the current vehicle, or buy intelligence on the other team.

Multiple vehicle types will be available to support different play styles. Such as zippy motorcycles, powerful interceptors muscle cars, and lumbering heavily armed defense mechs.

Upgrades can increase a vehicle's speed, armor, and weaponry.

Setting:
The theme of this game lends itself well to the Dystopian future setting like that of Blade Runner or Judge Dread. There will be a clear divide between the wealthy who live at high above street level and have everything delivered to them, and the poor who the player may accidentally run over on their way to serve the wealthy. Bill boards and huge video displays will show advertizements for the competing companies, as well as other futuristic products. There should be a certain tongue in cheek humor prevalent in the whole setting. The players are after all just delivery boys.

this just might do the trick, If I need to refactor the states to separate classes, how should thoese classes look like?

That depends on the functionality your program will need. I like to have a base screen class and inherit off of it. This way you can have an array of base screens in your Class manager and refer to them via index.

For now each of the refactored classes just needs a "public void Paint(Graphics g);" because that is the part you are refactoring out. As a rule I like including an onLoad, and onUnload function for each class. Depending on what java makes available you may also need onKeyDown and onMouseDown.

Also you need to look up how to do Update or onTimer if you are going to do anything non turn based. I don't know what the equivalent is in Java so I can't advise you further.

Note "refactor" is a fancy term for removing part of the code of one function and sticking it into its own function for readability sake. If you are serious about game development the amount of code to manage the project will get way too big for you to work with in just one file.

Full disclosure I am not a Java programmer and may get some terms wrong.

Also, to make things clearer-heres my main class code, If I make a state and extend the main class, will I be able to remove the paint in the main class and write separate paint methods in the state???

I think you are confusing terms here, at least I am confused by your terminology. Here is my best response to what I think you mean:

You can make a separate class for state management, you can call it what ever you like. It doesn't "extend" the main class so much as it is called from inside of it. ("Extend" is an OOP concept where you use inheritance to create a new class that adds functionality to an old class, not what you are doing here). You must keep the "main" class's paint method because that is the entry point for your drawing.

Here are some modifications to your code:

Code:

package dualWielded;
import java.awt.*;
import javax.swing.JFrame;

import dualWielded.Gui.GuiElement;
import dualWielded.Item.Item;
import dualWielded.Pickup.Pickup;
import dualWielded.Player.Player;

@SuppressWarnings("serial")
public class Main extends JFrame
{

//gameplay important objects
public static Item loadItems=new Item("Loader",-1,0,0,16,16);
public static Screen s= new Screen();
public static Graphics g;
private Image dbImage;
private Graphics dbg;

public static Collisions cm=new Collisions();
//ingame things
public static GuiElement newGameButton=new GuiElement("New Game Button",0,0,0,179,47);
public static Player player=new Player(20.0F,10.0F,0,0,0,0,0,0,64,64,300,300);
public static Pickup pickup=new Pickup("GoldPickup",0,0,32,32,150,150);
static Rectangle r1 = player.getBounds();
static Rectangle r2 = pickup.getBounds();

// modified
public static StateCtrl myStateCtrl = new StateCtrl();
// end modified

public static void main(String[] args)
{

// call all inits

loadItems.init();
newGameButton.init();
player.init();
pickup.init();
DisplayMode dm=new DisplayMode(800,600,16,DisplayMode.REFRESH_RATE_UNKNOWN);
Main m = new Main();
m.run(dm);

}
public void run(DisplayMode dm)
{
addKeyListener(new ActionList());
setBackground(Color.BLUE);
setForeground(Color.RED);
setFont(new Font("Arial",Font.PLAIN,24));


s.setFullScreen(dm,this);


}
public void paint(Graphics g)
{
dbImage=createImage(getWidth(),getHeight());
dbg=dbImage.getGraphics(); // I assume this is the double buffer
// modified
//paintComponent(dbg);
myStateCtrl.Paint(dbg);
// end modified
g.drawImage(dbImage,0,0,this);

}

// not needed any more
public  void paintComponent (Graphics g)
{
g.drawString("Health:"+Float.toString(player.health),10,20);
//g.drawImage(newGameButton.guiSprite,200,200,null);
g.drawImage(player.currentImage, player.x, player.y, this);
g.drawImage(pickup.pickupSprite, pickup.x, pickup.y, null);
cm.detectEM();
g.drawRect(player.x, player.y,player.WIDTH, player.HEIGHT);
g.drawRect(pickup.x, pickup.y,pickup.WIDTH, pickup.HEIGHT);
repaint();
//revalidate();
}
// end not needed



}

Code:

package dualWielded;
import java.awt.*;
import javax.swing.JFrame;

import dualWielded.Gui.GuiElement;
import dualWielded.Item.Item;
import dualWielded.Pickup.Pickup;
import dualWielded.Player.Player;

@SuppressWarnings("serial")
public class StateCtrl
{
  public static int curState = 0;

  public void Paint(Graphics g){
    switch(curState){
      case 0:
        DrawMode0(g);
      break;
      case 1:
        DrawMode1(g);
      break;
    }
  }

  /// this is just an example, ideally when these get too big you
  /// refactor them into their own classes
  private void DrawMode0(Graphics g){
    // draw something to g
    // check for user input like mouse up on button
    if(checkbutton()){
      curState = 1;
    }
  }

  private void DrawMode1(Graphics g){
    // draw something to g
    // check for user input like mouse up on button
    if(checkbutton()){
      curState = 0;
    }
  }
}

There is a drop down on the Unity Manual that changes the examples given from Java to C#. It took me a while to realize this, and I spent many frustrated hours trying to figure out why the sample code did not work (when it was a Java/C# translation error).

So can you make a single screen with buttons to click on and text that reacts to those buttons?

Also the timer thing will be necessary later when you want the program to do things on its own without waiting for player input to trigger an action. Animation, real-time updates, and a slew of higher level features are dependent on a function that is called on a regular basis. Most programmers call this function Update(). There are two ways to impliment the Update function.
1) Put the Update() function inside of a endless while loop, and record how long it has been since the last update.
2) Schedule a timer callback to the Update() function a few times a second.

I am not really a java programmer, what I posted was how I handle a state driven screen manager in pseudo code.

If you are learning from tutorials your probably have quite a few more tutorials to watch before you can do anything useful. Before you can make even the most simple game screen you need to be able to do the following:
Create a window (which your current code already does)
Output text to the window (Hello World)
Compile a project with more than one file
Check for mouse or keyboard input to that window
Initialize a timer call back
Load an image from a file
Draw that image onto the screen at a specified coordinate

Until you learn to do these things in the language you intend to use, thinking about higher level concepts like state machines is some what meaningless.