Yes, I'm definitely thinking on the smaller scale that you and Riven mentioned, rather than the more epic world/exploration ideas.

Personally I'd like to go for something that's similar to Animal Crossing at it's core (small random village, random villagers, house) but expanded so instead of being just another villager you're more like the village founder/mayor. So you'd be in charge of landscaping the village (clearing scrub land, marking areas for buildings, planting trees) as well as the farming aspects. I'd like it so that a player can basically start with nothing but bare scrub land and eventually completely transform it into a vibrant and busy village.

Thoughts?

Well there are kind of two options:1) The world is built by the player from bare land. The player places the forests, beaches, houses, ...2) The world is given by the game and the player can explore it. You learn to know where the caves are and which animals lurk where. You learn where the dangerous places are and only return with your weapons at hand.

Personally I think that option 2) would allow the game to have a lot more personality. There would be places and people that you would discover that you could really become fond of. I think it'd be cool if you discover a cave with a bunch of freaky animals that bite you - "I wonder what else lives in this world?".

This kind of exploration and discovery doesn't really hapen in 1) as you know what everything is - you made it. Do we want this kind of discovery? (I do, but you?)

I just like the idea of the game world being given so that the player can explore it. It doesn't have to be gigantic and the player can definately still have an input on how his house is laid out etc... but I think the "natural" element (trees, beaches, caves, mountains, creatures) of the game should be given (even if you go buy an axe and cut a few trees down, or kill off a particular species of animal).

I would like to ask the question: How much personality/ traditional adventure game elements should we have in the game? IE how much story and conversation should we have? (Probably very little story and if any it should be told through the artwork and conversations). I think good conversation between NCPs is a must for all the errands/ jobs (which is the main part of the game if I am not mistaken?).

It is of course very possible (certain) that I am imagining a game totally different to everyone else so... thats my opinion... any more?...

I was very much in mind of it being a sandbox, where you could do a large variety of jobs. Some of these might involve killing animals - for skins or something, but combat/level/exp etc wasn't what I thought this idea was about.

Yes I don’t think the whole RPG magic points/ experience/ levels are for this game although you could have a very basic health points thing for the people, animals and monsters to see for example... whether they need to be healed in some way.

Use a gun/ sword to kill an animal just as you would use a spade to dig for treasure, a fishing rod to fish with and a torch to brighten a dark cave. Just objects you can use to explore and for your job.

The "Sandbox" element to the game is... well for me it would be that the world is a living world where you can just go explore, talk to the strange and wonderful people you find and get your self a job (Maybe you can even get by without a job in this world - You may end up in jail if you steal though ! (*)). Then you can spend the money that you earn on a variety of other fun things you can do in the world (and to buy food).

(*) Just gave me an awesome idea for a job - police officer. Catch criminal NPCs who steal items/objects belonging to other NPCs, stick em in jail !

My remark about the mud was just in response to the note above I have never played Animal Crossing or Harvest moon, so just basically ignore my views on what I sandbox this should be. I'm pretty clueless.

I don't think you guys are too separate in your ideas. It seems to me that (eventually) the best thing to have would be a combination of the 1 and 2 that irreversible_kev posted above. Essentially, it will be most interesting to have a giant starting world, but the player should really be able to modify it in absolutely any way they want, given a variety of tools. A certain super spade could make new cave openings, for instance. And a net object allows you to capture absolutely any animal you see in the wild, then allowing you to potentially populate your own land with this type of animal. So you might go exploring some crazy cave that has a weird Batboy in it, and then you can capture it, and given you have a Batgirl (unless we want everything to be asexual, which I could see the advantage of), you can start a population of them in your own local cave that you build yourself.

So basically this will make completing a lot of the jobs easier (say you need to get some Batboy milk for a mission - originally it's ultra-rare but because of your cave zoo you can get it easily), and also gives the player the enjoyable task of creating their own zoo and having the sort of Pokemon gotta catch em all element, in a way. So rather than just have cows and chickens, the player can theoretically domesticate any animal they find given they have the right food, equipment, and environment for the animal to live.

But all this mentioned, once again it comes back to the fact that really what we need to focus on is creating a world that is incredibly modular and very very easy to add on to. Because once we have that engine working, we can easily pump out a gigantic world built upon the same tools that the player will be able to use.

The purpose of doing that is so that the whole world is treated with the same sandbox properties. If we built the world before we did the sandbox stuff or even while we did it, then undoubtedly there would be a lot of special cases ("why can't I mine that rock?" "why is that tree out of reach" etc.). So it makes sense to me that we establish the tools and the rules, and then from there think about making an extensive world using them, and only them.

I'm thinking that we could do everything if pretty much all of it falls into two base classes.

Job - Describes any specific thing you can do. Has prerequisites and potential rewards. Resource - Any collectible item. So, even an Animal would probably be a type of Resource.

Any Entity can give you a Job, but Resources can only be given as the rewards for a Job. A Resource is a subclass of an Entity (so you can drop it and make it exist in the World, etc.). So, a Resource can even give a job.

Every timestep, all relevant Entity's loop through their jobs to see if the job's starting prerequisites are met. Probably any Entity that exists in the world can check its jobs based upon distance from the player. The player's Resources should also check their jobs, and they should do it every timestep. This is important for tools, which are also resources. So a sickle's job activates if the player is standing on some tall grass and is pressing the action button.

Pros:- Incredibly simple and completely modular.- We could probably make every part of the game with it.- Should be very easy for multiple programmers to work together on.- Infinitely expandable.Cons:- Will result in a lot of classes that are subclasses of Resource and Job.- Will also have the potential to be incredibly slow; if we have too many entities with a lot of possible jobs and the prerequisite checks are complex, it could be unacceptably laggy.- More difficult to follow: instead of saying "if I press space and my current tool is a shovel, cut some grass," there is instead this sort of overly intricate job organization going on.

So really overall I think the big pro of this is that we can do anything with it very simply, and the big con is that it gets pretty convoluted and is almost always an indirect way of doing things. However, because the point of this game is to allow the user to do anything and because we're only going to very loosely organized, I think the evils of the approach are more than acceptable. Thoughts on that?

Examples:Job: Cut grass with a sickleGiven by- The Sickle resource contains this Job.Requirements- Requires a sickle resource.- Requires that the player be standing on top of some tall grass.- Requires that the user press the action button.Results- Gives the player a grass resource.- Changes the Entity below the player's feet to short grass.

Job: Catching an animalGiven by- An Animal running around the map gives this Job.Requirements- Requires a net resource.- Requires that the player is nearby the giver of this job (i.e. the animal).- Requires that the user press the action button.Results- Gives the player a Squirrel resource (or whatever).- Reduces the player's net count by one.

Job: Digging a caveGiven by- The super shovel resource contains this Job.Requirements- Requires a super shovel resource.- Requires that the player is standing on earth that can be dug out.- Requires that the user press the action button.Results- Creates a hole that is a link to new area.

Job: Sit in a chairGiven by- Any Chair Entity.Requirements- Requires that the Player collides with giver of this job (i.e. the Chair).Results- Plays the player's sitting down animation and moves them onto the chair.

In hindsight, it might make more sense to use Event instead of Job, but that's unimportant at the moment. Really though we can do anything with them, including bad stuff (like walking on a certain tile causes a rockfall), so I think it's a good way to go.

Oh, and a lot of these could have the same result done with multiple methods of implementing them.

Like for example the Tall Grass entity could be the one who gives you the cut grass Job, but only if you have a sickle and are colliding with the grass. The disadvantage to that implementation is that it's more costly (every single grass object is doing its own check) and that you need a different job for each tool, so the number of jobs being checked increase exponentially.

Similarly the catch an animal job could probably be confined to the Net resource, and it only works if you're nearby any animal. The disadvantage of doing it that way is that animals that can't be caught have no way of telling the Net that this is the case, unless we hard code that into the Net object for every single animal that can't be caught.

I think you could argue either way, but I think that generally it makes most sense for the tool to be the one doing the job, because that will be a lot cheaper if we've got tons of animals or grass or whatever on the screen. I don't think it should be confined to tools, however, because then we lose a huge amount of potential (like having switches you can step on, or maybe just a random key combination at a specific location, etc.). But, I think we need to give serious thought to the best way to implement each of these jobs before we do so.

I do agree that alot of the "create your own world" can be implemented over the top of the existing world using various tools. I just thought I would say that personally I wouldn't want it to be too similar to a "map-editor" or "world-editor". If all world editing by the player can be done using various tools that he buys/finds then it does sound perfect to me. In addition it would be nice if the way in which the tools are used is "realistic" in the sense that you cant just wipe out the 50x50 tile block of land that had various buildings on - that's what I mean about being "map-editor" like. Maybe for the more extreme changes, relevant NPCs come along to do the work for you and it might take a few game-time days. These are fairly minor points anyway and at the end of the day we will use what works best.

I agree with Demonpants. Should we now think about what kind of rules govern the game's world? Some concrete examples would be useful when evaluating how the world would work.

In terms of progressing and discussing the rules of the game world do you think the following might be useful?

1 Work out what you can do in the world as an overview1.1 Jobs/Errands (A core element)Shall we think up a bunch of jobs? Then we can think of all the objects (animals, flowers, shells, loot, people, ...) that the job would require and what the player would recieve for accomplishing it. Having a nice list of game world objects might help us focus on the particular places in the game world where they "spawn" or exist.

1.2 Fun activities other than your Jobs - Minigame style (Great for multiple developers?)Simple rally/ car/ boat racing game where the vehicles are bought/ found in the game world and can perhaps be customised.Simple combat game vs NPC. Okay it might be too RPG-like but, a small 1vs1 RPG style fight with very limited weapons/moves. Zelda kind of combat (With only his basic sword)

That Job system does look quite flexible. What happens in the following cases?1) There are a variety of different resourses that you can use to capture an animal (Different nets/ some kind of trap)2) Interrupting, restarting, modifying, failing and commenting on the current progress of existing Jobs the player has taken on.and that overhead problem will need to be looked at to see if it is at all an issue.

For your TreeJob class in the code you posted on googlecode:How do we update the image and state/ health of the tree as determined by the current progress of the job? I guess the initial hitPoints value won't always be 10 depending on if you leave the tree half cut and continue to cut it down at a later stage.

These aren't the best of comments but i'm tired and I already started my post :/. It needs to be discusses further.

Nice work.I'm not certain I've understood correctly, but are jobs exclusive to player controlled entities? If not, then some other ideas for non-human jobs to keep in mind:Rust- performed by: metal tool- requirements: wet- effect: update own properties

@irreversible_kev: Yeah, I agree that I don't want at all for the game to seem like a glorified map editor. I want all changes to be done tile by tile with your character using various tools (of course super tools will do more tiles at once, like in Harvest Moon). And I like the employee idea a lot. I was thinking about how AI could work, because I think it would be a great thing to add in. Like you can give them a simple task ("harvest all the grass" or "dig a trench") and then they would go about doing it just like a usual character. If we have something in the sort of job format we've got above, that should be pretty easy, where they simply have on tool, a simple "sight" preceptor to find nearby grass or whatever, and then they go about doing it. Just replace the prerequisite "action button is pressed" part of these jobs with "wants to do an action." You get the idea.

But yeah sometimes you might need to hire people to do certain work that will be outside of the realm of the sandbox (like upgrading the size of your house), but I still think that if there were any possible way that we could make it possible to do on your own, but stupid to do so (as in it will take a very long time), then just have the character hire like 10 AI characters to do it for you, that would be cooler. Similarly certain AI characters would have their own resources and whatnot, so part of the time requirement might lie in acquiring wood versus hiring people who already have it, etc.

@Jackal: I don't think I necessarily like the idea of battles or mini games. Seems like all 3 of these community projects have the potential to devolve into a big cluster of mini games, and of the 3 of them I think this one has by the far the most potential for enabling multiple developers to work independently without needing to rely on mini games. Instead you can spend a lot of time making inventive quests, like maybe something as crazy as someone asking you to carve the equivalent of an NES Mario sprite into the ground or something. The sky's the limit in that regard, but if we put in battles or space invaders or something it's just going to stick out.

@Jono: Great additions. I agree "Jobs" should be useable by any Entity in the game, not just ones being controlled by players. This is probably a good reason to stop calling them Jobs (bad original idea on my part) and call them something else like Event or Action or something. But in the end it's all aesthetics anyway.

I think it's far, far too early and would be a big mistake to start thinking on a code level right now. We need to get a good handful of use cases for the basic game play and actions first before we even think about class structure etc.

However the cut grass/capture animal are a promising start on use cases, so that's good. I think we should figure out a core set of tasks we want to have for the basic gameplay (covering aspects other than jobs as well), then break that down into four or so milestones where the result of each is something tiny but playable. Once we've got to the end we can step back and see which bits (both code and gameplay) are working well, and what direction (and functionality) to add in the next phase.

To give you an idea as how big I'm thinking, at the end of this first phase I think we should aim for: - Single, small landscape (say, 256x256 tiles) - Single controllable player character, with basic flip-book animation which can walk around the map with collisions. - Two or three basic actions (eg, pick up/drop object, dig hole, chop down tree) - Some kind of house the player can enter and exit. - A single, non-talking NPC (a dog or something) which wanders around.

I think it's far, far too early and would be a big mistake to start thinking on a code level right now. We need to get a good handful of use cases for the basic game play and actions first before we even think about class structure etc.

+1

When two or three activities have been implemented, then the architecture will have evolved such that adding more activities will require only minimal changes to the core classes. Before any code is executing, the probability of getting the code design right is very low.

At first we could implement one activity such as milking a cow, which in turn has prerequisites of for example feeding the cow. So this activity can be divided into at least the following actions:

- pick up a sickle- use sickle on long grass- pick up the cut grass- place the cut grass in a stack- wait for the grass to dry up and become hay- pick up hay- bring hay to the cow- wait for the cow to eat hay and produce milk- pick up a bucket- milk the cow into the bucket (to make the cow produce more milk, you might need to milk it at the same time daily and sit on the same side of the cow - http://www.ehow.com/how_7437_milk-cow.html)- take the milk in the bucket to a shopkeeper/milkman/your own storage (milk doesn't last too many days, so you might want to process it in some way)

Or if it's still summer, you can leave the cow outside in pasture, and the cow will by itself eat grass from the ground. But for the winter you should collect some hay into your storage house. At this point we could also implement the four seasons, to see how the milking activity works all year round.

Ooo, I quite like the "miking a cow" sequence as a goal for phase 1, it's a nice self contained bit of functionality and touches on a few core areas that we'll need to start on (landscape interaction, object interaction, npc interaction).

I guess along side this we'd have a simple landscape which could be just flat grass and dirt, plus some obstacles (rocks or trees) for collision purposes. Should we also have a basic house (just one you can enter and walk around in, maybe drop tools there)? That would force us to take into account multiple tile maps but a character and objects that moves between them.

Houses may also be left for phase 2, since they are not critical for milking to work. It would be best to keep the scope of each phase very small, like the 30 day sprints in Scrum.

Some features related to houses:

- A home where you can sleep in a bed and cook food.- A toolshed for keeping the tools (sickle, milk bucket, axe, spade etc.).- A cattle shed for keeping the cow inside during the night and in the winter. Otherwise the cow may get sick and you need to give it medicine.- Fences to prevent the cows and other animals from walking away to dangerous areas. If you have many cows, you might need to bring them every day to a different pasture, or the pasture will eventually run out of grass. When cows are in a pasture, they eat grass, sleep and walk randomly - fences are needed to prevent cows from walking away, or otherwise you might sometimes need to go search for the lost animals. Also the personality of some cows may be so that they like to walk much, whereas others are more calm and stay in one place. (You can learn much about cows by watching the Katri, Girl of the Meadows anime. )

I think you guys are right that we should think of use cases, but I don't think the cow milking use case is broad enough on its own (which I guess it pretty obvious). I'm just really worried this is all just going devolve into a Harvest Moon clone. If we make milking a cow that complicated, then the player is going to have a lot less time to do other things, effectively reducing the amount of "sandbox" we can have in this game. In my opinion, the actions should be a lot simpler than that.

i.e.Milk Cow- Go up to cow.- Press Action button.- Get milk, do whatever with it.- Cow can't be milked again for 1 day or X minutes or whatever.

Cow Dies- If cow doesn't get food for X days, cow dies. Or potentially, the amount of milk it gets is directly related to how much food it gives, or whatever.

I realize the potential hypocrisy of what I just said - I told you our game is too much like Harvest Moon and then suggested a cow milking thing that almost mirrors what's already in the game.

But that's not my point. My point is that actions should be simple so that you can do lots of them, and that we really should not put the player on a farm. They should have a house in a giant open area. If they choose to till the soil, they can plant stuff. But similarly they could build fences in their land and build a zoo out of it, then charge admission or something (I know that's hairbrained, but you get the idea).

Just starting this out with the idea that we should code cow milking I think is going to influence our final product too much in that direction.

And to expand on my other point: if we make any action too complicated then it immediately loses its appeal and/or the game itself loses its appeal. Like if you've got to spend 6 minutes milking each cow and you need to memorize 10 different steps, not only will that be much more hassle to code but also the players will either not do it at all (if its rewards aren't valuable) or they will be forced to do it and almost nothing else (if the rewards are valuable). I think the fun should lie in the staggering amount of variety you can do things with, rather than the depth of each specific action.

Similarly doing stuff like requiring crop rotation or giving cows different personalities I think is also going in the wrong direction, at least for now. If we begin to go to this level of complexity on the farming part of the game then that's all it will be.

But that's not my point. My point is that actions should be simple so that you can do lots of them, and that we really should not put the player on a farm. They should have a house in a giant open area. If they choose to till the soil, they can plant stuff. But similarly they could build fences in their land and build a zoo out of it, then charge admission or something (I know that's hairbrained, but you get the idea).

Just starting this out with the idea that we should code cow milking I think is going to influence our final product too much in that direction.

I'd agree with that. And I'd be happy with your simplified cow use cases to be the target for phase 1.

So the revised list of functionality for that would be: - Single, small landscape (say, 256x256 tiles) - Single controllable player character, with basic flip-book animation which can walk around the map with collisions. - Wandering cow NPC (with "milk cow" and "cow dies" use cases).

Questions:1. Any objections to the above?2. Is that enough for phase one or should we add anything extra (perhaps some crude inventory and/or hud work?)3. Should we extend that to include multiple cow NPCs rather than just one (should be small amount of extra work for IMHO quite a major gain in feel-good factor).4. Should we think about outlining phase 2 as well, or should we leave that until we've finished phase 1?

Assuming we're all happy with the above then maybe it's time to start talking about the specifics of technology/libraries/design etc.

2. That should already be enough for phase 1.3. Let's support multiple NPCs. For example two cows with slightly different AIs, so that we could see how easy it would be to add more different kinds of NPCs.4. Let's leave that later. When phase 1 is finished, we'll know more about what is important to do next.

3. Let's support multiple NPCs. For example two cows with slightly different AIs, so that we could see how easy it would be to add more different kinds of NPCs.

Could you expand on that a bit? Any cow AI I could imagine would be so simple that variations would just be different weightings (ie. how far it likes to walk before a rest, etc.) for the same AI code. If you're suggesting different behaviour then would it perhaps make more sense to go straight to having another NPC for phase 1 (perhaps a dog or some other smaller animal that you can't interact with yet).

I suppose you are right. Dog sounds good. A dog's AI could for example be such, that it likes to run around and play with things that it sees, but when the dog's owner (the player) walks away too far, then the dog quickly runs after his master and follows him (until when the owner again stays long in one place and the dog gets bored).

We could also add some interaction between the cow and the dog. When the dog barks at the cow, the cow walks or runs a little bit in the opposite direction.

I suppose you are right. Dog sounds good. A dog's AI could for example be such, that it likes to run around and play with things that it sees, but when the dog's owner (the player) walks away too far, then the dog quickly runs after his master and follows him (until when the owner again stays long in one place and the dog gets bored).

Sounds good.

Quote

We could also add some interaction between the cow and the dog. When the dog barks at the cow, the cow walks or runs a little bit in the opposite direction.

I'd be tempted to put that off until phase 2, otherwise we might be adding a lot of NPC code all at once rather than incrementally. I think you're right with your earlier mention of keeping the phases/sprints short like in Scrum.

Right - I was also thinking along these lines and imagined that when the game starts the player would have to choose between about 3 different locations he could live in (essentially 3 different bed locations). One small village near the beach, one nearer the forest and perhaps one in the caves. I don't know how the choice would be made. If you want to be a farmer then the first thing you need to do is purchase some land.

So in terms of not being forced to be a farmer - what else can we be?

Here’s one idea: Village Security OfficerEvery now and then some raging beast will come along from the forest into the village. He might hurt some NPCs and they may end up in hospital/ village doctor house. Hope that he doesn't injure the local shopkeeper as then you will not be able to use the shop until he recovers! (IE you care about the NPCs)

Anyway, as security officer you need to make sure that the village is not vulnerable to these attacks and you will need to set up barriers and alarm systems to ensure this. In addition to the raging beast we could have criminal NPCs who might steal objects (I don't know about stealing Cows but...) that belong to other NPCs and yourself (from your shed) and may also injure NPCs in the process.

You can try to capture these criminals who might live in an arbitrary cave somewhere. But this will be a dangerous task so plan it carefully (whatever that means - bring backup officers, weapons). It might be easier to catch them red-handed as you see them enter someone’s house or something. This adds a bit of variety to the role so that it isn't boring. Obviously they would have to respawn somehow if they are caught.

On the flip side I guess you could be the criminal - maybe that’s what happens if when you start the game you choose to live with some criminals in a cave (lol).

This is just one idea but if we are really serious about the not-only-a-farmer idea I think we should think of a list of real alternatives that are comparable in gameplay and complexity. Also is it a good idea to be able to be both a farmer and a security officer?

Talking about the different roles can be done in parallel to continuing the discussions on phase 1.

Kev, I think that rather putting the player in as a security officer / farmer / fisherman etc., we should just have the player be a "human" . What I mean by that is that really you should just be plopped down into the world and then you can do anything you want there. So then what should happen is that we have the capability to make crops, and we also have the capability to catch fish, and we have the capability to catch criminals, etc. Essentially imagine yourself being given a plot of land in the countryside where you've never been before, and you have no job experience of any kind, nor do you know anyone in the village. You need to make your way so you can survive, and you'll do this whatever way seems right. Similarly even during recreation time, if you wandering around in the forest and you see a gecko, perhaps you would catch it. Or if you're swimming at the beach and you see a pretty shell, you'd pick it up. On that end we get closer to Animal Crossing, obviously, but I like the idea of having a lot of options that differ from day-to-day rather than choosing one job at a time.

In response to what was posed above:I think all that sounds good. In conclusion: One simple tile-based map with collisions in it, 2 different types of NPCs and multiple instances of them, with no interaction between the separate NPCs.

In response to what was posed above:I think all that sounds good. In conclusion: One simple tile-based map with collisions in it, 2 different types of NPCs and multiple instances of them, with no interaction between the separate NPCs.

Sweet! I guess we should start on some technical decisions:

1. Graphics style. Personally I favor doing something in isometric 2d, a bit like wakfu. Top-down 2d (like the SNES Harvest Moon) would be another option but I think isometric will look more modern (and allow us to have some proper depth/layers.

2. Graphics API/Libraries. I'd suggest Slick because it's reliable and fast, plus it's very easy to pick up so it'll be easy for everyone to get up to speed quickly.

3. Target hardware/resolution. I'm actually not sure we need to decide this now, I think we'll be keeping it simple to start with so we can leave this till later.

1. Graphics style. Personally I favor doing something in isometric 2d, a bit like wakfu. Top-down 2d (like the SNES Harvest Moon) would be another option but I think isometric will look more modern (and allow us to have some proper depth/layers.

Yeah I definately agree with an isometric view.

If it were implemented in 3D it could give us more flexibility (resolution independent graphics, cut scenes and zooming towards things when necessary) and more opportunity for modern graphics effects.

The downside of course is that 3D might be harder than 2D in terms of content - but I think it could be worth it and will push the impressiveness up.

While I agree that 3d would look more impressive, I think the difficulty and time consuming aspect of making art and content would kill the project. Past experience tells me that we'd end up messing around with annoying 3d quirks rather than adding gameplay, and we'd end up with a world based on boxes and spheres. Eventually everyone gets disallusioned because they're spending a lot of time on something that looks like crap, and because it's 3d no good artists can be found to make it look better. Everyone drifts off and we're left with a buggy, unplayable heap of crap that's not going to impress anyone.

I'd much rather go for 2d where we can start by making some serviceable art ourselves to start with, so it at least *looks* like a game while we concentrate on gameplay. Once we've got something that's interesting and fun to play we can start bringing in artists to make it look pretty. It'll be much easier as a whole to keep the motivation up and so we'll have a better chance of actually finishing something.

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