Hi everyone,
I have been having trouble lately starting the development process of my game. I have all of my ideas gathered, I know what I want the final product should be but I am really struggling to see where I can begin.
I was just simply hoping for some advice - maybe from those who have developed their own game in jMonkey - on where to start…
General tips, bullet points etc. would be awesome. I have already read jMonkey’s section on planning but I am looking for more specific answers like how did you plan the game as an entirety? Did you make class diagrams, mind maps etc.? How did you know what to implement first?
Thanks for any advice 
I think for most people its just lots of meditation about their ideas. Its hard to have an idea on how to do things if you don’t know what you can do… So experience leads to ideas for implementations… If you try and jump ahead and implement extensive AI systems or the likes then you will most probably stumble across basic knowledge issues on the way… So I guess your plan should somehow look like “do I know how to do this? – if not, put it on the list of things to do.” You will inevitably get to points where you will rewrite or scrap parts of the code, even in big projects this happens so don’t worry too much about “starting out wrong” ;).
Start from the core of your game. It’s no use trying to create the small parts of your game without the core. Plus, it’s better that you create the important stuff in the beginning when you have more willpower and motivation. Start with the simple things and then think about harder engines etc…
Regarding planning - if you feel you’re not good for that kind of stuff, don’t plan using diagrams etc… I, for one, just plan in my head, and it works well enough for me. Sure, sometimes I feel the need to write something down so as to remember it, but only then do I get a pencil and a paper.
@memonick said:
Start from the core of your game. It's no use trying to create the small parts of your game without the core. Plus, it's better that you create the important stuff in the beginning when you have more willpower and motivation. Start with the simple things and then think about harder engines etc...
Regarding planning - if you feel you're not good for that kind of stuff, don't plan using diagrams etc... I, for one, just plan in my head, and it works well enough for me. Sure, sometimes I feel the need to write something down so as to remember it, but only then do I get a pencil and a paper.
Do you mean like you kind of improvise as you go? And I don't mean ideas-wise, I mean in terms of coding.
@normen said:
I think for most people its just lots of meditation about their ideas. Its hard to have an idea on how to do things if you don't know what you can do.. So experience leads to ideas for implementations.. If you try and jump ahead and implement extensive AI systems or the likes then you will most probably stumble across basic knowledge issues on the way.. So I guess your plan should somehow look like "do I know how to do this? -- if not, put it on the list of things to do." You will inevitably get to points where you will rewrite or scrap parts of the code, even in big projects this happens so don't worry too much about "starting out wrong" ;).
That's true. I haven't planned to use any AI but I do need to implement networking. I know how to do this but it is just a case of getting it done.
On another note, I think what is holding me back is the thought that if I create one thing, it then may not be suitable to work with other parts of the game. Has anyone ever stumbled upon this whilst creating a game, or am I worrying about nothing?
Not idea-wise, just start coding from the base code. If you feel the need to write the steps you must take, or the variables to use, write them down.
Regarding your last concern, it might happen. The result is the need of debugging. Yesterday I spent half an hour trying to find the bug, only to notice that one piece of code had the wrong variable set to it (because it was meant to do something slightly different when I created it for testing purposes).
@ollie said:
On another note, I think what is holding me back is the thought that if I create one thing, it then may not be suitable to work with other parts of the game. Has anyone ever stumbled upon this whilst creating a game, or am I worrying about nothing?
That's inevitable with any reasonably sized project. Even with a full waterfall model it always happened - that's why virtually everyone has moved to agile.
Essentially you need to embrace that. Write things knowing that you may well need to modify them in the future but accept that that is fine. By writing it and modifying it you have learnt something (even if what you have learnt is not to do something in future) so you gain.
Don't worry too much about the big picture (obviously having a rough plan in mind is good!) just focus on getting one bit done. And then do the next bit and plug them together, and then the next, and the next. Unit testing and integration testing then take up the slack of making sure everything works as it should and works together right.
Just think, you could spend days working out the "best" way to do something - or you could spend a day trying something and either it works or it doesn't but you now know for real not just in theory :) You will also find that once you get one bit working that starts making the other areas around it clearer.
When writing things try and make them modular, self contained, all the things that makes good object oriented code. Don't try and pre-empt yourself by adding hooks and customizations and modifications though. Write what you need at the time but write it as cleanly as you can and then go back and add more as you need it.
Brilliant advice. I will keep it as self contained as possible. I have already updated my voxel code several times; originally, everything happened in one class but I have separated it into smaller classes like ‘Block’ and things like that.
Seeing as jMonkey is a visual-based engine… I suggest starting with the following:
- Set up a test scene that mimics the way your final game may look (and what I mean by this is… are you using rolling landscapes? wall/floor/ceiling mazes? boxel type landscape? etc). Once this is in place, you’ll have the ability to start implementing thing that will be “working towards” a final.
- Set up you camera/player movement. This is probably pretty critical to everything else you will want to do.
- Collision detection/basic physics (i.e. gravity and such).
After these 3 steps, you can pretty much tackle anything you like, as your fundamentals are in place for testing anything you build.
Suggestions for next steps:
- Communication layer (if your implementing a client/server multiplayer game). Decide how you would like to share information… this can weight heavily on how you decide to implement many of the client features.
- GUI… pretty critical, seeing as past most basic features, you’ll rely heavily on the user interacting with the these components.
- AI & AI path… if you game requires NPCs… pretty self-explanatory,
Seriously, past the first three things I mentioned, every feature can be developed semi-independent of all other feature, as long as you keep in mind (and document) where those crossovers need to happen.
I develop prototypes (code that I throw away after I try it). I find it helps me narrow down what I want, and leaves me free to throw away things that just aren’t working, or turn out not to actually be fun or don’t add anything to the gameplay.
After a few prototypes I nail down a steady version where I don’t throw away the code. Then I do small releases, every month, and see how it is going. Set small goals (get animation working, get an enemy, add in a few models…). With small releases it easy to feel progress. Also the end goal might change, and probably will, as you develop it. Starting with a design document first can sometimes be a waste of time in my opinion, at least a full, complete, and detailed design doc. Having a bit of a base idea to go by does help you work towards something.
Also class diagrams are a waste of time, until maybe after the project is complete, and then only if you are working with a group of developers. It’s something that never gets maintained and always changes.
Also, think about the hard parts of a game and if you need them:
- networking: only if you really really really really need it
- AI: takes some learning but isn’t too hard. It does take time though
- fancy models an animation: how fancy do they need to be, how seamless do the animations have to be
- pathfinding: can be tricky and does take time.
- scripts: make the game fully configurable and scriptable? It might take more time than it is worth.
Small, achievable goals. Don’t be afraid to scrap features.