How to structure a big project

General Discussion
1

I am finally motivated again to develop a game. I now have an idea that might actually work, I know how I will get the assets for my game, I know how I will create levels and I have lots of ideas for lots of different content.

However, my experience has taught me that I will probably give up halfway through with a hell of a mess of code and a lot of wasted (ok, not really wasted, but still…) time. So my question is: How should I plan my project?

My plan is to first start with a prototype. Create some assets, write throw-away code, until I have something that resembles those essential 30 seconds of core gameplay that I want to create. If that is not fun and I don’t manage to make it fun - leave that project be.

Ok, so let’s say I have a worthy prototype. How should I proceed? Of course, it’s obvious that I should begin planning the project thouroughly. But how thorough do I need to be? In my experience, I often plan things out to the last detail, but in the end, everything plays out differently and a big part of the planning has been useless. Should I maybe start thinking about the first couple of systems and then try to implement those before I think about further systems? The risk then is that I might have to heavily adjust these systems because I did not think of other elements of the game that influence these systems or make design decisions that I made about these systems seem wrong.

Once everything is planned, where do I actually start? Should I focus on the art first, so that I have something that I can use in the game? Or start with programmer art and implement the game logic first? Or create the art ‘on-the-fly’ e.g. create a new monster model when I finished the game up to the point where I need that new monster? The benefit of creating art first is that I would have something to show off (and of course it’s much more fun). On the other hand, creating art is a distraction from creating actual gameplay and that is even more important I think… Should I start with the core gameplay or at the start of the game, which might be a little different from the core gameplay? Or should I maybe focus to get an alpha version out as quickly as possible? Should I rather focus on creating a Minimal Viable Product or create little, but thoroughly polished content (e.g. a vertical slice)?

I was just writing every question I could come up with down, you don’t have to answer all of them, but you might see that I am kind of lost. I now finally have an idea for a game again and I think I just need some advice beforehand from somebody who has actually been able to finish a project.

Thanks and feel free to leave any input if you think it helpful!

2

Project planning, specially for games is one hell of a challenge and while there are many “methods” that you can see in books and classes. Some are too much and some are too vague. What works for you is what you should follow.

Prototypes are a double edge swords for many who are not experienced enough, including me. Because from a prototype to a game many things can go wrong and one of the culprits is “tightly coupled code”. Thankfully in my job I leaned tips that have helped me in my game development. Here are a few tips I can give you.

  • Refactor your code: aim for this goal “one method does ONE job”. Also, having multiple projects for one game is recommended sometimes (i.e. AI, Multiplayer, UI).
  • Use interfaces when you can: think of making the interaction between your game and the system you want to implement through an interface. makes maintenance a lot easier since you are separating code.
  • "Proof of Concept" is your friend: sometimes a system you want to implement is a bit complex. Create a simple JME project that will test that system (or a group of systems) independently from your game.
  • Make “dumb” appstates and controls when possible: don’t put game logic code in an appstate or control, make them use that logic that is written somewhere else instead.
  • use low poly models and placeholders: for testing purposes and proof of concepts, this is helpful. Sometimes a palceholder (box, capsule) works, but there are moments where a low poly model can give you a better idea and saves you time.
3 Likes
3

Also, you may want to start with a smaller well-understood project to hone your organizational skills. Chances are you will bump into lots of things that work or don’t work for you. From there you can solicit feed back on ways you might improve it.

Ultimately, if you truly do want a flexible architecture then there really isn’t anything better than entity systems (entity component systems). It’s great way to keep different code aspects isolated.

4

My impression so far, using ES virtually eliminates the need to “always throw away a prototype” which is a widely recommended practice you can find in books. Instead, you refactor. Sometimes it is surprising of how much code appears to be actually redundant after you do, heh. Also, looking at your systems you can more easily distinguish which one is good and which isn’t that clean, conceptually…
Can’t say if it’s right or wrong, but I’d put gameplay on the 1st place ultimately. Too many games are based on polished assets nowadays, to my taste. Of course, having fancy models looks better in terms of your own motivation in the beginning, but soon you get used to them anyway, so this impression decays… and there’s still so much to do in logic! On the other hand, once you have wired your backbone, nothing is easier than to fill it with assets, that’s more technical task despite the fact that polishing can consume significant time too.

1 Like
5

My impression using ECS is that I could avoid a refactoring hell like I faced as I tried to write games the OO way. I also ended up in hard to understand code and hacking my self into a corner. With ECS this didn’t happen anymore and if I come up with a new idea it is mostly no problem to implement that without bothering about my existing code. I mosty not even need to touch a single line of the existing stuff.

I personally would start simple and try to make my mechanics first. With the mechanics in place I would try out if that could be fun and interesting to play. If not I then would try to find out what exactly is missing to make it fun.

6

I will definitely learn about ECS architecture, thanks. On the first glance, this does seem to be indeed a much better fit for games than a typical OO design. I also think that the general awareness of keeping my project structured is something that I was missing before, so I hope that I will be disciplined enough to simply enforce that structure and spend my time on refactoring code etc. if I realize that something was done in a non-clean way.

Thanks and let’s see where this project will take me!

7

Note: if it wasn’t obvious there is a library called Zay-ES that provides nice ES stuff.

A simple single-player example:

A simple network based example:

1 Like
8

Yea, prototypes are great. For a game I am making, I made a simple combat prototype, I liked it so I went ahead and now I am deciding for the artstyle. I found a reference picture of what I would possibly like it to look like and am going to model this. I start small, and if I like what I do I continue.

It’s good to have some longterm ideas/decisions too, like the theme of the game, what is the main gameplay focused about etc. However, when actually working on it, I like to work on small tasks. Eg. I got to create artstyle/assets for RPG game. I found a reference picture of a forest, thus as a smaller task, I model assets for a forest scene, and then put them together to see how they fit together.

9

I have a blog http://fprintf.logdown.com/ where I did document how to write a simple game with ECS and at the moment I try to collect kind of ECS patterns, still on going work…

The invader example can be found on the Zay-ES github wiki as well Zay Es Case Studies · jMonkeyEngine-Contributions/zay-es Wiki · GitHub.

10

Since I started with a ES I had no mayor throw-all-shit-away-and-copy-paste-useful-parts frenzys anymore, they roughly happend like every 2-3 years before.
And since the ES i switched between 3 UI systems (selfbuild->JFX->Lemur) and rewrote everything to use DependencyInjection and a central Eventbus for all non ES parts. Oh I also replaced the whole networking layer, without having to touch any game logic at all.

1 Like
11

Ok, here is a custom method that i am trying, with good results so far. It’s strange, you are warned.

I often help student for their project. And, when i do so, it seems that everything is easy, even i do a over-the-top program that they could never do.
So, i started to investigate about why. And i think that the reason is : when i do such projects, i have a document that explain everything needed, explicitly.
It says how things should interact, if graphics are important or not etc.
And when there is some complex algorithms, the document give explanations about them.

So i started to do that : create my own “project document”.
The document starts with “the goal of this project is to create a game blablabla”, with global specifications.
Then follow a list of items, like a summary of main things that should be in the project.
I can add then a list of “bonus” things, not mandatory.

Then, it’s “insert jump to next page” (don’t know the english text of that action) and, for each item, there is an explanation of how it should works, like if i was explaining it to students.

And then i can go, and it’s pretty straightforward. I tend to slack on the document, and so far it’s always a bad idea and my code suffer from it.

So, maybe you can give a try to this approach.

1 Like
12

+1 This! Make up your mind and plan on paper/notepad first will save you really a big amount of time later on

13

Yeah, I even started kinda wiki (via google.sites) for myself because otherwise catching the trees can easily prevent you from seeing the whole forest. And having a big picture you always see your overall progress and those things that are critical now or will become tomorrow. Plus, regular examining of your currently picked particular small solution against it prevents you from picking one with unnecessary constraints to the whole project. Project is, first of all, project, then code.

14

I am already working on a design document that details every aspect of the game. However, I have already done that with my last project but I ended up writing the document once and then never looking at it again… I think that you just have to be very careful to not get carried away by the excitement of implementing new features and doing what’s the most fun, but rather plan everything in detail beforehand. So before you jump right into implementing that new exciting aspect of the game, you actually have to hold yourself back and first look at the design document and what you had initially planned. Even more important is that you don’t simply code the feature as fast as you can, just because you want to test it, but that you think about your implementation first and the implement it cleanly.

Summarizing, I think the most important thing is to think long term.

1 Like
15

I would say the design document can be very coarse,
just take the time to step back a week or longer before starting a new part to implement, and try to think what role it should archive, how it iwll interact with existing systems ect.
Since using es, I rarely have really shitty code, because it forces you into some clean design, and to actually think about what is your state, what is the manipulation and cleanly seperate it. However I would actually start with some smaller tests if you plan on something larger, eg. a small test for the network? physic? weather? system that is standalonish. That way you can fast iterate over stuff not working as planned, and come up with alternatives before desining to much around it.

16

I do not have a design document for the same reasons, I rarely look at it again.

what I do is have a brainstorming of ideas of the game is going to have and I list them. if any item of that list needs to be clarified I write that, but that list is a lot easier because I can add and remove as the project progresses. It may sound chaotic but it works for me better than a document

17

Well a document isn’t something carved in stone, and anyway can barely be done to the every last aspect before you implement some things in practice, but key conceptual points are useful to be listed there I guess. In the end, those were the main reasons why I started it at all, and what will differ my game from those games I played before. It doesn’t mean I review/update it every time I commit code, but looking at it once per month or so is refreshing. Some important part could be forgotten, something else could be done even better than planned which opened new possibilities etc. This just helps to stay focused on key goals and not to distract too much to the side. Plus, ES makes progress tracking more realistic and not looking like typical classical cpp project: “Nothing is working… nothing… nothing… nothing… nothing… nothing… nothing… nothing… nothing… nothing… BANG ! BANG ! BANG ! - COMPLETED !”

18

Well “how to structure a big project” sounds suspiciously like “software engineering” or maybe “project management.” There’s lots of documentation available how those two things work. The trick is to actually read up and understand, then do it. Not try to re-invent the wheel, something I see many inexperienced developers do.

I’d recommend “Code Complete” by Steve McConnell. It’s a reasonably complete overview. It actually has your idea in it (prototyping, iterate over a design, start small), along with some pitfalls and some other ideas how to start.

Good luck.

1 Like