@memonick: Try to think more in objects:
Your quests need a place to be hold. So create a class for them. (For example: QuestData)
[java]
class QuestData
{
List<Quest> _questList = new ArrayList<Quest>(); //or a Hasmap.
//getters’n setters
}
[/java]
Now you can create an object of QuestData in the game-initialisation.
Your control-object needs access to the questData. So give it a reference.
[java]
Control
{
QuestData _questData;
public void setQuestData(QuestData questData)
{
_questData = questData;
//_questData and questData are still the exact same objects. Changes in _questData will also be visible in questData
}
//all the other stuff
}
[/java]
Now you have two “components”. If you instanciate them and “wire” them together (which means in this case, call the setQuestData-Method), your control-object is able to get access to your quests. (Just keep in mind never to re-create the QuestData-object or the reference in your control-object will be useless)
[java]
Main{
QuestData _questData;
Control _control;
//…
simpleInit()
{
//init your components.
_questData = new QuestData();
_control = new Control();
//wire them together
_control.setQuestData(_questData);
}
}
[/java]
Als always this is not the holy grail, but I think it shows the idea.
edit: If you now add quests to your questList, the control will also be able to see them.
A very simple example would be using a method in your Main.
[java]
public Quest getQuest1() {
return q;
}
public quest getQuest2() {
return p;
}
[/java]
Etc. But that’s far from ideal. Actually, that’s not recommended at all. Main shouldn’t contain that kind of stuff. Nothing says you CAN’T, but you shouldn’t.
In the real world you would have some kind of “manager” that would contain a list or whatever of quests the player has and you would query that manager with something along the line of:
questManager.getQuest(questID);
I would highly suggest you learn more about Java programming. This is part of the basic stuff. 
@ceiphren, Got it to work. Thanks a lot. I won’t lie, I still find some things confusing since it’s my first time using ArrayLists and Lists. But some more studying should absolutely do the trick.
@madjack, I studied until Intermediate level, and will continue to study at Advanced level next October, but I never learnt any of these things 
Sorry, and thanks for helping me.
I will use this system then. Thanks for all your help.
@memonick said:
I studied until Intermediate level, and will continue to study at Advanced level next October, but I never learnt any of these things :/ Sorry, and thanks for helping me.
I will use this system then. Thanks for all your help.
Yeah, that's the sad thing. What you learn in school isn't bad, but they can't teach you everything. Besides, if you're doing a game you will definitively outgrow what's being taught in your courses. This is not a bad thing in itself; others will look at you with awe. ;)
Good luck.
To top it off, in Malta, it’s mainly theory. About 90% of the exam is theory, and while theory is important, I believe that practice makes perfect.
Thanks.
@ceiphren, you wrote: “Changes in _questData will also be visible in questData”. Does that apply vice-versa?
@memonick said:
"Changes in _questData will also be visible in questData". Does that apply vice-versa?
Its a reference (something akin to a pointer but its not exactly the same) to the same object, so yes. Really, try to wrap your head around the object thing, else everything yo do will be kind of pointless. You should hear a firm "click" in your head when you get it ;)
@normen said:
You should hear a firm "click" in your head when you get it ;)
Often referred as having an Eureka moment or having an (why do I have "apoplexy" in mind? O_o) epiphany.
My fault, sorry ^^ I was taught Pascal at school, and in case you don’t know, in Pascal this code:
[java]i := f;[/java]
means that i is a new ‘instance’, a copy of f. If you modify i, f doesn’t change; and vice versa.
@memonick said:
My fault, sorry ^^ I was taught Pascal at school, and in case you don't know, in Pascal this code:
[java]i := f;[/java]
means that i is a new 'instance', a copy of f. If you modify i, f doesn't change; and vice versa.
And that's true in Java, too. But you've mistaken a reference for the object it points to.
In Java:
[java]
float f = 123;
float i = f;
f++;
[/java]
i == 123 and f == 124
Even in pascal if you had a pointer to an object then changing the _FIELDS_ of that object will be changed from the pointer's perspective and from the regular object's perspective. That's pretty standard. In Java, everything except primitives is a "pointer", ie: a reference.
[java]
Object f = someObject;
Object i = f;
f = someOtherObject;
[/java]
i == someObject, f == someOtherObject
But if you leave them both pointed to someObject and modify the fields of f then i sees those too because it is still referring to the exact same object.
Let me see if I get this straight. Let’s say f is an object, formed from a Quest class with its variables. I code i = f;
If I modify f’s fields, i’s fields are modified to stay the same; and vice versa.
If I modify f to make it point to something else (Quest > Inventory Item, for example), then i won’t be changed.
Is this how it works?
If you could provide some links/keywords to search on Google, I’d appreciate.
Yes, that’s how it works.
It’s not really hard. Any variable is just a value, whether float, int, whatever. In the case of an Object variable, think of the value as a pointer to some location in memory. No matter how many pointers you have to that same location and no matter how you modify the contents of that memory, they are all still pointing to that same chunk of memory.
If you change the value of the pointer (by setting it to something else) then it doesn’t point to the same chunk of memory anymore. Changes to the old chunk of memory are not visible to the reference to the new chunk.
This stuff is pretty fundamental.
@normen, thanks. I’ll read the Classes and Objects.
@pspeed, I get it now. It’s like having synonyms, which have the same meaning, right?
@memonick said:
@pspeed, I get it now. It's like having synonyms, which have the same meaning, right?
I still think you are over-complicating it. It's not "like" anything. It is exactly that you have variables that are values. Some values are numbers you can see. Some values are references to blocks of memory (conceptually). In C or C++, that is precisely what it would have been but it's more explicit.
I'm really not sure how to explain it any simpler.
Pretend you carry little slips of paper around. They are only big enough to write a long number on or to write "page ###" referring to a page in your notebook. So maybe you have some slips of paper with 123 on them. If you want that slip of paper to have a new value then you erase the old one and write down a new one. This is what "=" does.
mySlipOfPaper = 123;
mySlipOfPaper = 456;
...now your slip of paper says '456' when it used to say '123'.
Now, on three different slips of paper you have "Page 12" that refers to a page in your notebook. No matter what you write in your notebook on page 12, following any of the slips of paper that say "page 12" will look at that same information. If you change one of the slips of paper to say "Page 13" then now it is looking at a completely different page.
The slips of paper are your variables. The pages in the notebook are "objects" or chunks of memory.
I get it pspeed. Thanks a lot for your patience
@ceiphren said:
@pspeed: This is maybe one of the best examples to explain the reference-theory.
Thanks! :)
The example I’ve always used for references is houses and addresses.
If three people have someone’s address then if they go there they will see the house. If the second visitor changes the colour of the front door then the third will see that change.
If the third person changes the address they are going to then they will see whatever colour that house door is - which is unrelated to the first house’s door.
Great example too zarch!