Creating a complex game

[micha]

I'd like to add, that looking at finished code does not tell you, how it has developed over time. So don't be overwhelmed by a fully complex source code of a game. Just start with one element, and then step by step add more feature. Eventually you will have to adapt some older code to go on. I personally don't consider my code an "engine" by rather a game. And that is what I am working on. So I don't write an engine first and then make a game with it, but I make a game in the first place.

[Bobbias]

Yeah, thinking of writing a game as an engine is a tough task... It's probably best to just write code, and when you realize you should change something because it's poorly structured.... refactor it. It's perfectly fine to have a monolithic graphics.lua for a long time. Of course, if you're planning on making something really huge you'd better expect to have to refactor your code multiple times. Don't get too attached to a specific implementation of something, because you never know when you might need to break something apart and such.

[Germanunkol]

I want to object to something:

- Have the ability to extend my game into a multi-player one

It is possible to extend a single player game to a multiplayer game, but I highly recommend NOT doing it.
Single and multiplayer games are entirely different by design. It is not even close to "I have a single player game and now I just add more players", the entire structure must be changed.
So my recommendation is: Choose single or multiplayer, and then stick to it. For an indie game, if you want both multiplayer and singleplayer, I'd go as far as to advice you to make a multiplayer game, and in singleplayer mode simply set up a local server and only allow one connection (all automatically, of course - the player doesn't need to manually set up a server and join it), since any other way will be twice as much work...

Other than that, for managing a large project, I would recommend:
a) Object oriented - put everything into classes
b) Test these classes/modules individually, as much as possible. Write programs that just test the classes by themselves before putting them into the game, and keep the classes as seperate from each other as possible. Make strict distictions between the classes, don't let them overlap.
c) And make absolutely nothing global, if it can be local. This is a bit of a mess in Lua, since everything is global by default (probably the only thing I dislike about the language). So put "local" wherever you can.

So... any hints on what you're planning to make?

[obey]

I want to object to something:

- Have the ability to extend my game into a multi-player one

It is possible to extend a single player game to a multiplayer game, but I highly recommend NOT doing it.
Single and multiplayer games are entirely different by design. It is not even close to "I have a single player game and now I just add more players", the entire structure must be changed.
So my recommendation is: Choose single or multiplayer, and then stick to it. For an indie game, if you want both multiplayer and singleplayer, I'd go as far as to advice you to make a multiplayer game, and in singleplayer mode simply set up a local server and only allow one connection (all automatically, of course - the player doesn't need to manually set up a server and join it), since any other way will be twice as much work...

Other than that, for managing a large project, I would recommend:
a) Object oriented - put everything into classes
b) Test these classes/modules individually, as much as possible. Write programs that just test the classes by themselves before putting them into the game, and keep the classes as seperate from each other as possible. Make strict distictions between the classes, don't let them overlap.
c) And make absolutely nothing global, if it can be local. This is a bit of a mess in Lua, since everything is global by default (probably the only thing I dislike about the language). So put "local" wherever you can.

So... any hints on what you're planning to make?

Thanks,
So from what I've read up to now, I think the way to go is like this:
- Use some-kind of lua classes implementation. Is https://github.com/kikito/middleclass a good possibility?
- Try to build the game itself and redactor it when necessary.
- Use unit tests - any suggestions?
- I also found that I could separate code blocks in a simple trick like:
main.lua ->require 'player' -> update -> updatePlayer(dt) -> player.lua

Any other tricks that may help?

About the game:
I wanted to create a little game that had networking abilities. I want to create something that my friends and me could play.
I've built a few games with LOVE but never something that I would distribute (even though only for my close friends).

[Bobbias]

You should definitely look into component based entity systems. There's lots of stuff out there on them, and they work very well for going beyond the really simple games. I've been working on implementing FEZ (which seems to have been abandoned quite a while ago) myself, and it's given me quite a bit to work with in the sample and with the library. It makes use of middleclass and comes packaged with it as well. Looking at the example gives you some idea of how they use the entity system to encapsulate game logic for each entity separate from some large update function using a simple event system.