Alright guys, I'm just completely stumped. I can't make up my mind about my first game and I keep switching projects and it's really just annoying me at this point, I guess it's because I don't really know what I want to make. I keep getting ideas that I like and trying to make something out of them. I'm trying to decide right now between making a platformer or an top-down 2D game. I don't know which would be better. I want a game that people will enjoy playing in the end. I understand that the time and effort that goes into making a game is a substantial amount, but I just want to make something that others will appreciate.

I find it hard to encorperate a story-line in a platformer game, and that was my original idea, to have a story-driven platformer, but now that I've actually got the basics down for the platformer, I can't think of any ways to implement the story, but this isn't my only issue. It's the same with with topdown, I don't know how to implement it.

Perhaps my main problem is that I don't really have a story. I can't create one.

I think that's what is really throwing me off. I don't have a gameplan to stick to, I'm just making something, and once "something" is made, I don't really have anywhere else to go. I have never really invisioned a completed product.

This is where I'm turning to you guys.

Can you guys help me create a vision for a completed product? Even if it's simple. I haven't even completed my first game, because every time I have the "Engine" written, or the "Basic Necessaties", I don't know where to go with it, so it just sits on my computer until I erase this. This has gone on for years.

Help me get an idea. Help me create a vision. Help me finish something.

It's not about not having the dedication to do it, I sit infront of my computer for hours, ludum dare style every time I get an idea in my head, but then once I get the basis down for it, I contemplate it, think of other ways. It's never set in stone.

Story is, often, the hardest part of a game. Especially figuring out a way to include it that does cause a shoehorning or railroading sensation in the player. This is, perhaps, one reason why games like Minecraft and Terrarria are so well liked. They don't provide a story beyond "Go forth and survive". That said for platformers/top-down games implementing a way to put in a storyline is mostly a task of adding in event regions that cause the normal 'gameplay' engine to be superseded by the 'story engine' which is what pops up the dialog, plays the animations, etc. Neverwinter Nights used a system like this and several others did. They basically had a special type of 'invisible' collision object that when entered would cause these events.

All of that said, how to create a complete game and release it? I know, given my own track record, that I shouldn't be the one saying all of this (Though I now have two relatively complete and playable games that I need to polish and upload here), but the best way to do it is to set in stone what you want. Create a document, some sort of contract with yourself, that states what it is you intend to do, the features you want to include and the like. Write it up as best you can, even if it's just a general description of the UI, the gameplay features and all of that. Then stick to it. If you think you might have come up with a better way to do something or a better mechanic write it down then look back at your document. Will the new gameplay mechanic require you to rewrite the rest of the game? Then put it down in an idea folder for a later incarnation of the game or for another game entirely.

This is why so many games have a road map or upcoming feature list. It's so that they can focus on one idea long enough to get it working. Later on, you can look back at your code, refactor it and decide whether the fantastic idea you had while you were working on it would actually improve the game in anyway. If it can, then you write up another document/contract with yourself defining the scope of the changes you're going to make. Google the idea of a 'Game Design Document' and read up on it a bit.

This is coming from a person who feels your pain when it comes to changing gears in the middle of coding. The only game that I've manage to write to a playable degree is one that I wrote for a class (I WAY over did it) and I only managed to get it done on time because I laid down the mechanics prior to starting to code it and (almost) every time I thought "The game would be better if I did this" I said "Yes, but that'd require me to rewrite other mechanics and it won't be the game idea I defined earlier". Every other game I've attempted to write has sort of crashed and burned because I got too deep into the "Oh, this would be a great mechanic, why don't I add it" until I was too bogged down with them and went "Screw this, I need a break... Oh, that's a great NEW idea'.

Story is, often, the hardest part of a game. Especially figuring out a way to include it that does cause a shoehorning or railroading sensation in the player. This is, perhaps, one reason why games like Minecraft and Terrarria are so well liked. They don't provide a story beyond "Go forth and survive". That said for platformers/top-down games implementing a way to put in a storyline is mostly a task of adding in event regions that cause the normal 'gameplay' engine to be superseded by the 'story engine' which is what pops up the dialog, plays the animations, etc. Neverwinter Nights used a system like this and several others did. They basically had a special type of 'invisible' collision object that when entered would cause these events.

All of that said, how to create a complete game and release it? I know, given my own track record, that I shouldn't be the one saying all of this (Though I now have two relatively complete and playable games that I need to polish and upload here), but the best way to do it is to set in stone what you want. Create a document, some sort of contract with yourself, that states what it is you intend to do, the features you want to include and the like. Write it up as best you can, even if it's just a general description of the UI, the gameplay features and all of that. Then stick to it. If you think you might have come up with a better way to do something or a better mechanic write it down then look back at your document. Will the new gameplay mechanic require you to rewrite the rest of the game? Then put it down in an idea folder for a later incarnation of the game or for another game entirely.

This is why so many games have a road map or upcoming feature list. It's so that they can focus on one idea long enough to get it working. Later on, you can look back at your code, refactor it and decide whether the fantastic idea you had while you were working on it would actually improve the game in anyway. If it can, then you write up another document/contract with yourself defining the scope of the changes you're going to make. Google the idea of a 'Game Design Document' and read up on it a bit.

This is coming from a person who feels your pain when it comes to changing gears in the middle of coding. The only game that I've manage to write to a playable degree is one that I wrote for a class (I WAY over did it) and I only managed to get it done on time because I laid down the mechanics prior to starting to code it and (almost) every time I thought "The game would be better if I did this" I said "Yes, but that'd require me to rewrite other mechanics and it won't be the game idea I defined earlier". Every other game I've attempted to write has sort of crashed and burned because I got too deep into the "Oh, this would be a great mechanic, why don't I add it" until I was too bogged down with them and went "Screw this, I need a break... Oh, that's a great NEW idea'.

The information that you have given me is everything that I have told myself, I write the "documents", everything that should happen, etc... but I just don't follow it. I guess that's why I'm so hyped about an artist that came to me with HIS game idea wanting me to design it with him. He has over 90 pages of scripts, and hundreds of concept sketches already. He knows exactly how he wants the game, which is great. But I want something to call my own. Instead of waiting another year or so for him to finish all of his artwork, lol.

I'm a firm believer that placeholders exist, but they shouldn't exist if you can't tell what they are for. I don't think you can create a combat system without working animations. I know you CAN. but I'm completely against it.

Maybe that's another reason I can't get anything done.

A sprite saying "1-2-3" should be enough, but not for me. I can't work on it if it's not pretty. <-- What kind of programmer logic is this?

I think that's what is really throwing me off. I don't have a gameplan to stick to, I'm just making something, and once "something" is made, I don't really have anywhere else to go. I have never really invisioned a completed product.

I think it's easier if you design backwards. Start with the winning condition - what does the player have to achieve? Second, I think is the starting point - where and how does the player start? And then you can design paths forward or backwards from start to end.

Once you have that you can also make up a simple background story describing the end, the start and give hints on some of the paths.

Personally, I don't like story heavy games. They replayability is low. The more generic the story is, the more variation the game allows, the longer it can stay interesting (aka give the player more ways to play through).

"Alright guys, I'm just completely stumped. I can't make up my mind about my first game"

This is your first game as you said. If that is truly accurate then your first game should be incredibly basic, stop thinking about your games storyboard and over all gameplay and focus on what truly counts, getting the most primitive of functionality working.- Focus on getting a game loop working- To see the game loop working test to see if you can move something on screen a very basic shape (fillRect(x, y, width, height);- Focus on replacing the something moving on screen with a user defined action (user input, key listeners)- Replace the primitive shape with a picture, correctly (try and catches, file input and output etc.)

once those stages work develop from there by adding additional objects to the game and then the most needed part the physics (collision detection, gravity, acceleration, deceleration)

A story could be summarized into a single sentance, consider space invaders for example

"Alright guys, I'm just completely stumped. I can't make up my mind about my first game"

This is your first game as you said. If that is truly accurate then your first game should be incredibly basic, stop thinking about your games storyboard and over all gameplay and focus on what truly counts, getting the most primitive of functionality working.- Focus on getting a game loop working- To see the game loop working test to see if you can move something on screen a very basic shape (fillRect(x, y, width, height);- Focus on replacing the something moving on screen with a user defined action (user input, key listeners)- Replace the primitive shape with a picture, correctly (try and catches, file input and output etc.)

once those stages work develop from there by adding additional objects to the game and then the most needed part the physics (collision detection, gravity, acceleration, deceleration)

A story could be summarized into a single sentance, consider space invaders for example

While your recommendation would be fine for someone who didn't have a clue, it's not really what I'm looking for.

Considering I don't really know what I want to do, I've decided I'll go on helping other people do what they want to do while I figure everything out. I started working on a stand-alone server about an hour after I posted this and it's almost ready to put up for grabs, I'll be writing a tutorial series for this to create a basic multiplayer game.

Then a tutorial series on authorative servers.

While drawing things to the screen isn't my "Strong point" and I do ask for help with a library I'm not familliar with yet, I certainly do understand the language.

"Alright guys, I'm just completely stumped. I can't make up my mind about my first game"

This is your first game as you said. If that is truly accurate then your first game should be incredibly basic, stop thinking about your games storyboard and over all gameplay and focus on what truly counts, getting the most primitive of functionality working.- Focus on getting a game loop working- To see the game loop working test to see if you can move something on screen a very basic shape (fillRect(x, y, width, height);- Focus on replacing the something moving on screen with a user defined action (user input, key listeners)- Replace the primitive shape with a picture, correctly (try and catches, file input and output etc.)

once those stages work develop from there by adding additional objects to the game and then the most needed part the physics (collision detection, gravity, acceleration, deceleration)

A story could be summarized into a single sentance, consider space invaders for example

While your recommendation would be fine for someone who didn't have a clue, it's not really what I'm looking for.

^The above project shows that I know how to move things across the screen, and how to create a basic "game loop"

1

while(updateRequired()) { }

I'm more or less looking for either

A: Inspritation

or...

B: Ideas on how to get past my mental block, which Varkas is trying to help me do, it seems.

oh, my apologise, didn't notice how many posts you have made nor the projects.

in that case, the best place i find myself drawing inspiration is from movies, watch a movie and ask yourself if you were at the helm, making that movie what would you change. That may not be intirely productive in relation to what you want. I personally like RTS or RPG styled games, as for platformers i find their stories limiting in a way, but its not a huge problem, RTS styled games can have relatively complex story arcs and RPG's would have hugely complex arcs. I just realised i am of no help at all, sorry.

I'm not sure if I can help much, but I think I face similar problems. At least in the past, it was "cool" to me to develop an engine, implement cool and extraordinary features and such, but I never managed to make an intersting game. Well, oftern not even a game, but an engine, and no one was interested in yet another game engine.

One evening I sat there, having developed a sort of 2D MMO engine the past years, and wondered myself: This is boring. Players can dig clay, make pottery, try to sell it. They can search metals and learn smithing. They can keep bees and make honey. I could add fishing ... but ultimately, while this is all nice, it's all boring nevertheless. It has no reason, it doesn't make sense. It's a big playground and eventually will be boring, and apparently "eventually" isn't much more than one hour or two of exploring.

I didn't want to include combat and fighting, and it thius failure was a key experience for me - although trying very hard, I couldn't make it an interesting game. It had a map editor, network, a game server, a minimal in game messaging system, player diaries, crafting, stats and skills ... but it was boring. There were technical flaws as well, but they could have been remedied, the problem was in my head, that I couldn#t come up with fun and interesting activities for the game.

Gah. Years worth of work wasted. But a lesson learned - all these cool features are good for nothing, if you don't have an idea how to make a game interesting. Make players want to play and want to continue to play. Make them addicted.

Don't do what I did - don't build the engine first and hope you can make it a game some day. Work on the game idea first, and do not start to work on code or graphics until the game idea is rather clear. Key points: players must have a reason to play it. Play it again and again.

This is what you need to make a game. Code, graphics, sound, all are secondary, just means to the end.

Maybe should make a port or demake of an existing game.You obviously like to do engine groundwork more than gamedesign.You could look for an existing Javagame for example and do an enhancement,

Improving a gamedesign is often easier and more productive than making up a completely new one (wich oftenturns out less satisfying when implemented)Also it is not needed to have to make a disproportioned character, a psychadelic story and sad backgroundmusic,to be considderd making an Indy game.

or make a port of an old arcade game, Amiga game etc..

example: the Amiga game Interphase if you want to go into 3D,or the Amiga game PPHammer or Rick Dangerous, if you like platformers.Or a variation of the Lemmings.

Java4k also forces you to conentrate an getting the game done, asthere is not enough room for unnessesary features to creep in.

I don´t think you should be to worried about making up a great story in a game. Story is actually quite overrated, especially in games small enough to have an honest chance of completion. That´s not to say that the story is worthless but in the beginning of the process it doesn´t have to be more than "Girl is off to save boyfriend hero from evil sorcerer". That is something to build upon and start worrying about something more important: Game mechanics. A game without good/interesting mechanics isn´t a fun game, so coming up with great controls for the game should be a priority.

So here´s an idea how to move on: come up with a great concept, not story, and prototype it. Make it work and make it fun. If it isn´t fun at this stage it´s not going to be fun when you have great assets and 20 levels. You´ll just have wasted a lot of time and effort. It can be something simple, like Bionic commando (a guy that can´t jump but can swing with his bionic, extendable arm) or something more elaborate but it has to work.

Now, how to come up with ideas? Well, I have a really simple way of doing this: I ask myself "What if..?". One example is an idea I had for a platformer. "What if I played Super Mario, but instead of this super high jumping plumber it was just an ordinary guy? A person that´s just able to jump 0.5 meters, or something like 5 pixels upwards in a Mario game?". I loved the idea, but realised that is wouldn´t be any fun to play. So how do I make it fun? Again, "What if..?". What if it was a two player network game and one player was playing the ordinary guy and the other was a helping hand, able to do all sorts of magical stuff. What if the catch is that the "ordinary guy" is the only one who knows how to solve some puzzle and the "helping hand" has all the power but has to try and read the "ordinary guys" intentions? So the end result of my thinking was that one guy is playing a guy that has to use the puny tools he has at hand and another player with all the power in the world not knowing what to do. It´s pretty far from the starting point of a Mario clone. I´m not saying this would be a fantastic game but I came a long way just by thinking about Mario and ask myself "What if it was something else?".

I'm partly echoing what others have said, but I wouldn't get hung up on the story just yet (especially for the platformer). Instead I'd be focusing on getting a good game mechanic or idea going that's fun to play.

If attracting and keeping players is your main concern, think about what makes top games popular. Angry Birds has a light story woven into each chapter; but does anyone really care why you are slinging birds at pigs in houses? What is the story behind Plants vs. Zombies?: Zombies are attacking your house, and you need to plant plants to stop them; once again a simple premise, but the gameplay, continual unlocks, changing scenes & increasing difficulty keep you engaged. Mario?: Some bloke has pinched a princess, and you're off to get her back. The Harry Potter stories?: A bad egg killed your parents, is coming back to rule the world, and you need to ice him before it happens.

So in summary, I'd be focusing on creating something that is fun to play, such that the gameplay itself will keep the players engaged. Don't rely on a big, deep story to drive the game (unless of course you were trying to create an RPG). I'd play a good game with no storyline, but I wouldn't play a bad game with an epic storyline; I'd rather go read a book.

Just to add, you could start with a simple "what, why, when, where, how". As an example - What: You're off to whack a big-time druglord. Why: He's a big player and becoming a threat to national security. You're a commando tasked with completing the job. When: Perhaps it's set in modern times or the cold-war era. Where: Starts off in a city, but moves deep into the jungle as levels progress. How: Blast your way through his troops in each level, uncovering information on his whereabouts. Progressively gain cash/points that can be used to purchase more gear between levels. Perhaps swinging from a grappling hook and rope is a core mechanic required to get through levels.

I'm partly echoing what others have said, but I wouldn't get hung up on the story just yet (especially for the platformer). Instead I'd be focusing on getting a good game mechanic or idea going that's fun to play.

If attracting and keeping players is your main concern, think about what makes top games popular. Angry Birds has a light story woven into each chapter; but does anyone really care why you are slinging birds at pigs in houses? What is the story behind Plants vs. Zombies?: Zombies are attacking your house, and you need to plant plants to stop them; once again a simple premise, but the gameplay, continual unlocks, changing scenes & increasing difficulty keep you engaged. Mario?: Some bloke has pinched a princess, and you're off to get her back. The Harry Potter stories?: A bad egg killed your parents, is coming back to rule the world, and you need to ice him before it happens.

So in summary, I'd be focusing on creating something that is fun to play, such that the gameplay itself will keep the players engaged. Don't rely on a big, deep story to drive the game (unless of course you were trying to create an RPG). I'd play a good game with no storyline, but I wouldn't play a bad game with an epic storyline; I'd rather go read a book.

Just to add, you could start with a simple "what, why, when, where, how". As an example - What: You're off to whack a big-time druglord. Why: He's a big player and becoming a threat to national security. You're a commando tasked with completing the job. When: Perhaps it's set in modern times or the cold-war era. Where: Starts off in a city, but moves deep into the jungle as levels progress. How: Blast your way through his troops in each level, uncovering information on his whereabouts. Progressively gain cash/points that can be used to purchase more gear between levels. Perhaps swinging from a grappling hook and rope is a core mechanic required to get through levels.

what, why, when, where, how.

^This. This is key. This is what I needed.

[Start 10% Origina]So, I just have to type a bunch of random things to reply to this post, because a new threshold has been added to the forums, i dont know why but sometimes i wonder about the sky, why is it blue? is the blue that i see the blue that you see? how do I know that you don't see my blue as my green, but it's still blue, because you were told that, that color was blue. What if everyone sees something different, what is my "Bright" was your "dark".

If you can name the colors of a lightspectrum in the correct order, Im pretty shure you seethe same blue as me.

Well, you have to think about what I was saying.

In my eyes the order would be this: Blue, Red, Green Yellow.In your eyes the order would be this: Blue, Red, Green, Yellow.

But we don't really know what the other person really see's. When we were growing up, someone pointed to a color and said "This is Red, This is Blue, This is Green, This is Bright, This is Dark" so that's what we know it as.

Now, I could see the Color Green(From my perspective) but through your eyes it could be the Color Black to me, but even though through your eyes the Color Green is the Color Black through my eyes, you were taught that; that was the Color green, therefor you know it as green.

Similary, if I describe a color, such as yellow (A Florecent, Bright Color), through another persons eyes, "Yellow" could be what I consider a Dark Purple.

If both people point at a yellow flower, and say its "yellow", they physically see the same color.if both people say in the spectrum yellow is between green and orange, they see the same frequency.(thats the input side)

if both people say: oh orange is a warm tone, and blue is cold.they have the same (or similar) associations. People learn it in many cultures in a very similar way.Also because hot surfaces are turning orange, and cold things are often bluish (ice, cold skin)(thats the output side)

if (and thats testable) people have the same brain-activation patterns when looking at a color, vs another color,then they have the same neural processing pathways. At least roughly.(thats the process view)

basically:if input, processing and output shows no difference, we can assume that the symbol (in this case light)is perceived the same.

According to Occams Razor, we should assume that everybody sees light the same way (if their receptors work, eg not colorblind),unless you can find a concrete measurement to the contrary.

The brain is a very complex organ. I dont think singnallning pathways will differ dramatically between people, since itneeds a lot of optimization (many generations) in evolution to come up with a propperly working system.I dont think brains would work if their networking would be just determined randomly for each new person.

I mean, Look at WoW. It's been the same thing for years, but has millions of players.

League of Legends? I play the hell out of it, but it's the same. You have the SAME MAP, every game and do the SAME THING, every game. But it's the competition that keeps me playing.

So, when it comes down to it.. do you really need features? or do you need competition.

It will work for games which were early in the MMO market, or had some big advertising campaigns. But for small and new games, it will be difficult to build a player base if the first few player do not have something that keeps them going - if they leave before more players arrive the world will stay void and empty.

It's kind of a bootstrapping problem that you have with MMOs.

About the colors:

Thsi question was actually researched, and while it is impossible to answer directly (if all human brains will have the samne internal representation of what they call blue), it has been researched if colors have the same measureable effects.

E.g. watching a red area in average raises blood pressure a little bit. And it does so for a big number of humans from all sorts of cultures. Similar tests were made with other colors, and the effects were reproducible. So there are good chances that two person actually "see" the same if they see something which they call blue. At least it makes their brains and bodies respond the same way, which is a good indication.

I read the topic, but the truth is game making is not one dimensional.

The main difference between a engine and a game is that an engine has a clear goal, and a clear solution. Everything you've learned in school can be directly applied to solving the problem. A tech demo that shows off the 2D particle engine has no other goal but to show off the particle engine. It is precise, concise, and rudimentary to perform.

A game is not clear cut...

Unlike the tech demo, there is always something you can do to expand games. In this case, games force a programmer to find focus. If a programmer can't find something to focus on, the game will never be produced. So, even with all the advice, if a programmer can't decide what to focus on within himself, the game will always remain lost in thought.

The way I keep my brain from going crazy is by telling myself to think of every possible crazy idea at the start of the program (brainstorm) and write them down. When the brain had its fill, I then get to work to see what is doable from what isn't. I keep shrinking that list until it becomes a few tasks. I usually finish games and applications by finding a core mechanic and working on the mechanic until it is completed. Then I work on the next most important, and the third most important. Pretty soon, I end up getting a game... it might be rough, but it is still playable.

I always find it hard to define the word "fun" in terms of gaming.

It takes the right blend of visuals, mechanics, and challenge to hit that nerve. The weakness about something that can't be measured is that it breeds discouragement. What is a fun game to you can be boring to another, there are niches for everything. When designing I always try to make something that is fun for me to play, something that engages me. If I'm not having fun with my game, how can I expect anyone else to?

Gaming is, well, just not in tune with the developer psyche.

When we code an engine, we know without a doubt that the time used to code that engine was not wasted, and that the result we'll get is certain. With gaming, you have to be prepared to let go of 80 - 90% of your code base sometimes if a mechanic did not perform the way you wanted. The last thing programmers ever want to do is think that their code was a waste of time and scrap it.

Welcome to game programming...

I hate to say this, but when you develop games, you have to be prepared to lose code. Not every part of your engine will be used, not every piece of code you write will be important. You have to be ready and willing to drop your code if it doesn't meet the mechanics. In other words, gaming is the slash and burn tactics of programming, and it requires programmers to achieve a new thinking process.

Are you crazy?

Well, if you want to be a successful game developer, you have to assume the risks. That is why many of these people achieve this by accident. They didn't go out to create a successful game, they were just at the right place at the right time. As a programmer, it is about building the code and seeing if it is your time.

However, it is also the reason that many of these projects don't get done.

The more you code, the higher the stakes of losing a lot of code and time. Programmers end up wanting so much not to fail, they end up walking away to forget about all that wasted time and effort. They start a new project to forget the fact they are sitting on a pile of forgotten work. A bandage over the wound.

However, like all messy closets, the space becomes so cluttered that the door can't close. There you are with 100 unfinished projects and not one you can say you completed. It is a horrible feeling to have as a programmer, the feeling of not completing something...

Game engines are calculated. Game making is a risk.

When you go out to design a game, your code is already lost... so don't try to salvage it. Keep going... keep going... and when you are at your breaking point keep going. It is only those individuals that end up with a game in the end of it...

Every post that I have seen by you on this forum has been full of information, regardless of the subject.

Secondly, thanks again. The information provided here is clearly part of my problem, I'll scrap and rewrite, over and over, and over again, before just tossing it to the side and starting something new. I need to find a project to stick with.

i’ve been trying to learn game developing for almost 4 years now and i have made a lot of unfinished prototypes, during that time i learned that the most difficult thing in game creation is actually finishing a project,no matter how simple it is, finishing your game is the hardest part in the whole process.Every time i start a new project i feel REALLY afraid from falling again in the “awesome-game-trap”, am sure that you all know what am talking about, it’s that moment when you start imagining all sort of amazing things to have in your game but never being able to do any of them and in the end you give up and put all the blame on your skills; the tool you are using or the programming language you are coding with {it really sucks}.

"It's not at all important to get it right the first time. It's vitally important to get it right the last time."

Thje other "awesome game" problem is that long running projects have less chance to be completed than shorter ones, juts becuase live brings too many unexpected changes over time, and even if you stay motivated, there might be changes like a new job, family troubles, natural desasters and other which make completing such a project difficult.

I once concluded that I'll only do games which I can finish in 6 or 8 weeks, but non of my projects actually fit into that timeframe. But I still think the idea is good, to focus on smaller projects which can be finished in a short timeframe.

I'm doing a DooM fangame precisely because when I get to design my own content, I get lost in the details and never get anywhere.

Also, I'm developing the game partially as a framework I can build new stuff on top of later on.

This also made me realize a "trick" of sorts: Once you decide on certain engine specs, it can become somewhat easier to design content to fit them.

For example, my game is to be a top-down shooter, so I'm already thinking of story concepts to develop afterwards using that same engine. Having certain limitations does help the creative process, or else you get lost in the "wouldn't it be cool if..." thought process.

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