How to make actual games
How to make actual games
How do you make an actual game? By that I mean a game that is professional and can be released. There seems to be a lot of stuff going on, like gamestates, menus, graphical effects and a lot more, doesn't the code become cluttered? How do professional game developers structure their games?
- zorg
- Party member
- Posts: 3468
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: How to make actual games
Question, are you looking for answers only from pro game devs, or can others risk an answer as well?
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Re: How to make actual games
Doesn't matter, as long as the answer is helpful
Re: How to make actual games
As you get better and better at programming you'll learn tricks and methods to make your code structured and optimized, one major thing being OOP.
If you're looking to make and release a game, try to have the minimum amount of content. That is, dont "waste" time on good graphics, music, a professional menu, a huge story, Just make the game mechanics, make it fun.. And thats it.
And just go on like that, make games, try new things out, learn what works for you, add new content like menus, and just learn from there.
If you're looking to make and release a game, try to have the minimum amount of content. That is, dont "waste" time on good graphics, music, a professional menu, a huge story, Just make the game mechanics, make it fun.. And thats it.
And just go on like that, make games, try new things out, learn what works for you, add new content like menus, and just learn from there.
- zorg
- Party member
- Posts: 3468
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: How to make actual games
It should boil down to how the game plays, not how nice or readable the codebase is.
Granted, keeping the code clean helps the programmer's work, but as an example of the opposite; Minecraft is certainly not popular because of the obfuscated code, now is it?
As for how one should structure the game, it's really up to who's designing it; it depends on a variety of factors, from the scale of the project to how it should present itself, &c.
One could separate external libraries, internal modules, game entity data, map data, tile data, whatever else into elaborate folder hierarchies; in the game, using game states to change from menus to other menus and into the game(s) proper.
Each game does it differently, for whatever reasons, technical (limitations) or purely by choice (or lack thereof).
Edit: Of course, one other factor would be the size of the team making the game, which matters too!
Granted, keeping the code clean helps the programmer's work, but as an example of the opposite; Minecraft is certainly not popular because of the obfuscated code, now is it?
As for how one should structure the game, it's really up to who's designing it; it depends on a variety of factors, from the scale of the project to how it should present itself, &c.
One could separate external libraries, internal modules, game entity data, map data, tile data, whatever else into elaborate folder hierarchies; in the game, using game states to change from menus to other menus and into the game(s) proper.
Each game does it differently, for whatever reasons, technical (limitations) or purely by choice (or lack thereof).
Edit: Of course, one other factor would be the size of the team making the game, which matters too!
Last edited by zorg on Sun Jan 31, 2016 2:53 pm, edited 2 times in total.
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: How to make actual games
Making a "real, complete" game is like running a marathon. It requires accumulated experience and stamina. You cannot go from "not doing any exercise at all" to "running a marathon" without any steps in between. You start running 1kilometer. The next week you do 1.5 km. And so on.
For games it's the same thing. It is not physical, but mental. But that's the main difference. You also need to "extend your resistance gradually".
That is why everyone says "start small." (And then gradually make more complete games over time). There's no "shortcut" to skip this, or at least I don't know it.
Good luck!
For games it's the same thing. It is not physical, but mental. But that's the main difference. You also need to "extend your resistance gradually".
That is why everyone says "start small." (And then gradually make more complete games over time). There's no "shortcut" to skip this, or at least I don't know it.
Good luck!
When I write def I mean function.
Re: How to make actual games
I would also recommend reading the brilliant book by R. Martin - Clean Code, to get an idea how to write and maintain clean code, which should help with structuring too.
PM me on here or elsewhere if you'd like to discuss porting your game to Nintendo Switch via mazette!
personal page and a raycaster
personal page and a raycaster
Re: How to make actual games
one word: modular programming.
I've seen a lot of code for complex games made in Lua, they all have this in common.
Also Object Oriented Programming makes everything a lot shorter to code. You then have script objects for example player.lua, enemy.lua, boss.lua, mydog.lua e.t.c.
Then the main function looks something like this
You don't even see any variables in main.lua unless they are MACROS (very key global variables like units)
Thats for a "real game".
So you should go check out Meta Tables and Object Oriented Programming in Lua as well as Scope and Modules. You can then expand the game for ever and ever without worrying about clusters and repeated code. Also you can work more with division of labour, some work on the player module, others work on the enemy module and then the lead programmer works on the main function. Its even possible to work with people across the globe thanks to github fork it. You can then really expand on your ideas and blow things up but even then you need a solid prototype and some dedicated testers. (bugs are a harder to catch, you change one module and then you have to keep up consistency or the thing will just crash and burn)
Hope that helped.
https://en.wikipedia.org/wiki/Modular_programming
I've seen a lot of code for complex games made in Lua, they all have this in common.
Code: Select all
require "script"
Then the main function looks something like this
Code: Select all
require "player"
require "enemy"
require "world"
function love.load()
player:set(12,23,343,123)
enemy:set(23,12,232,22)
world:set(232,121,232,121)
end
function love.draw()
--camera set
player:draw()
enemy:draw()
world:draw()
--camera unset
end
function love.update(dt)
player:control(dt)
enemy:control(dt)
world:control(dt)
end
Thats for a "real game".
So you should go check out Meta Tables and Object Oriented Programming in Lua as well as Scope and Modules. You can then expand the game for ever and ever without worrying about clusters and repeated code. Also you can work more with division of labour, some work on the player module, others work on the enemy module and then the lead programmer works on the main function. Its even possible to work with people across the globe thanks to github fork it. You can then really expand on your ideas and blow things up but even then you need a solid prototype and some dedicated testers. (bugs are a harder to catch, you change one module and then you have to keep up consistency or the thing will just crash and burn)
Hope that helped.
https://en.wikipedia.org/wiki/Modular_programming
Re: How to make actual games
From a practical standpoint, it doesn't make sense to spend your time trying to make your code 'professional' or super-optimized.
Basically, you release something and if people want to play it - you go back, refactor and rebuild.
With many indie games a lot of the development is done after release.
As for the overall structure, try to keep the content (levels, images, sounds) separate from the code (scripts, modules, ai, physics).
This way you can expand the game without rewriting old parts of the code.
Basically, you release something and if people want to play it - you go back, refactor and rebuild.
With many indie games a lot of the development is done after release.
As for the overall structure, try to keep the content (levels, images, sounds) separate from the code (scripts, modules, ai, physics).
This way you can expand the game without rewriting old parts of the code.
- zorg
- Party member
- Posts: 3468
- Joined: Thu Dec 13, 2012 2:55 pm
- Location: Absurdistan, Hungary
- Contact:
Re: How to make actual games
Also, keep in mind the limits and the features of the framework/engine you are using (most likely löve, if you're here, but there are exceptions ), decide what your game needs, and if the f/e lacks it, implement it yourself in a way you find it usable. It's slow? Then rewrite that small piece of code, assuming you wrote modular code, and you wrote it fast, like you were prototyping.
Full disclosure, the above sentences don't apply to me, i like to throw away whole engine ideas because i'm like that. A reason why i don't have any completed games yet (just a few small "0-player" things i did for fun )
Full disclosure, the above sentences don't apply to me, i like to throw away whole engine ideas because i'm like that. A reason why i don't have any completed games yet (just a few small "0-player" things i did for fun )
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
Who is online
Users browsing this forum: No registered users and 5 guests