Perspectives on game development

[CaptainMaelstrom]

I've been working on a simple 2D fighting game lately, but I've noticed that I'm hesitant to go forward with the programming. I'm having a hard time figuring out where to put certain variables like projectile velocity, collision details, map elements, etc. I want to be able to add mechanics to the game to make it more fun/interesting without having to re-write the whole codebase. Is that a feasible desire? Should I write in stone as much as possible up front?

I think I have a general understanding of the difference between procedural and object-oriented programming, but maybe I need help understanding it in the context of game development. I hear professional game developers talking about event managers and message handling, and I think I understand the ideas there, but how can I know if my project is big enough to warrant that stuff?

Resources that you know of that might help me would be great, but I'm also just trying to open up a general dialogue, maybe get some anecdotal input. Thanks guys. : )

[Pash]

I'm not an experienced game developer at all but here are the rules I try to adhere to when working on a project in lua and love:-

- try and implement a class system on all projects. I use https://love2d.org/wiki/Simple_Educative_Class_System

- write code that is as reuseable as possible and the interface to your objects are self explanatory so you can just re-use project to project and make improvements/additions as time goes by.

When I started with lua/love I found out there is no real OOP implementation and we should use one of the available class systems to achieve such results. As such, and to cover one of your questions, when you have an OOP system in place you can the add in stuff as you see fit.

[Roland_Yonaba]

As a straight addendum to Pash's post, you can cook your own class system. PiL provides some good pointers for that.
You can take a look at this list of libraries for Lua/Löve. MiddleClass, hump.class and SECS are the most-common choices, you might want to take a look at them. And time for some advertisement for 30log, my own little object orientation framework.

[kikito]

... where to put certain variables like projectile velocity, collision details, map elements, etc. [...] without having to re-write the whole codebase.

Add "How to choose good names for things" to that list and you will have the list of Big Programming Problems of programming, not only games, but anything.

I remember clearly what was the first place were I read about organizing your code. It was the first article of Code On the Cob, a game programming series by Chris Hargrove. A lot of how I try to organize my code can still be traced back to that article. Sometimes when I'm writing a file I still mute "Pandora's boxes, Pandora's boxes".

But a lot of time has passed since that article was written, and things have changed and evolved. Nowadays there's lots of people talking about the SOLID principles. The first one, Single-Responsibility, is actually Pandora's Box all over again, and I think it's a great pinciple. The rest of the principles sound useful, but not as much as that first one IMHO.

I guess what I'm trying to say is: don't despair if you don't get it right in the first week or two. I've been trying to solve it for two decades now, and I still struggle. Even if the questions you are asking are short and simple, answering them "completely" would require months, if not years.

Imagine that you asked "how does a car work?". The question is simple, and I can give you an answer to that in a couple phrases. But that answer will not help you much when you are actually building a car from spare parts. The process is complex, and requires time. Try different things, and be incrementally better each time you do it. Jumping from "all my variables are globals and they are in a single big function" to "my program is flexible and well structured, and I can make changes without having to modify everything" is not something you can do overnight.

[Pash]

Excellent points by Roland and kikito. The single responsibility principle is perfect for fitting your question as well. Programming is a problem solving activity and as such you are improving your problem solving by making your code adhere to tried and tested methods. For me, I treat a game programming activity like...eg adding floating combat text to the game - as a problem to solve (like kikito's car example):-

- build the blueprint
- build the required properties to make the object
- build the methods that the object would need and engineer the arguments required
- create the interface to these objects via the methods

I also try to read others games source as well to learn the syntatic sugar and tricks of the languages.

[CaptainMaelstrom]

Wow. Thanks guys.

I appreciate all the links and words of wisdom here. I'm definitely going to try to make more stuff re-usable, practice using classes in a practical way, read the resources ya'll have given me, and especially opening up sample code and seeing how others have tackled this issue.

Imagine that you asked "how does a car work?". The question is simple, and I can give you an answer to that in a couple phrases. But that answer will not help you much when you are actually building a car from spare parts.

I find that I learn quickest and best when I cycle between experimentation and discussion. Left completely to my own devices, I'm not sure I would ever make the games I want to make. To stay with the analogy, just telling me how cars are usually thought of, as having suspension systems, braking systems, engine and ignition systems, etc, helps me to think about how to build one. At least that maybe I shouldn't build my brakes into my suspension or something, haha.

But that's exactly what ya'll have done, give me some new ways to think about programming and making games.

[scutheotaku]

I don't have much to add here, except that, as far as OO programming with Lua, I'd like to recommend Roland Yonaba's excellent 30log class/OO library: http://yonaba.github.com/30log/ . It is extremely easy to work with yet powerful, and without the inheritance bugs that some of the simpler OO libraries have. Great work Roland!

[Roland_Yonaba]

@scutheotaku