Is there ever a "correct" set of way to make a game?

[UsernameAkitsune]

I'm kinda in a pinch right now. I tried to make games so I tried doing things like searching "how to make ... games using ... game engine/framework". Every tutorials I've seen so far is different from one another. Some of them has much more simpler and cleaner code than the other. Some of them are much more complex and has many logics in them. Some of them are slow and some of them are fast.

I've already checked out Sheepolution, RVA Game Jams and Santos Love tutorials and I like them because it is easy to understand. Although Sheepolution uses some libraries, for example in chapter 11 for Classes, I can somewhat understand how that library works. After completing the tutorials I went to search for more in Youtube that is, Challacade and DevJeeper. However, unlike the other tutorials, they uses things like Tiled, windfield.lua, etc.

Uses of libraries worried me because I can't understand them completely and most of the functions in them might not even be necessary for what I tried to do. It is also the same reason as to why I don't want to use game engines, it has way to many buttons and things I don't understand. Even looking at the their document makes me dizzy. So instead, what I do is I skipped those tutorials.

Right now, I'm watching Love tutorials from recursor at Youtube. And holy crap, it is complex. Not only that, I can't understand 50% of the time what things does what and why does it even matter. I scroll through the playlist and found somethings like Event Manager, Entity Manager, Tweens, State Machines, ECS, etc. I searched throughout the internet if there are something similar to this and I found A* Algorithm, Minimax Algorithm, Heap Priority Queue, etc.

I wanted to learn how to make games, starting out with simple things like Tetris, then moving to Platformer, and so on. At the end of the day I wanted to be able to make an RPG using Love framework. Seeing complicated things like these makes me started doubting myself if I can even do it in the first place.

I learn programming by myself, and I can't really say I'm good at it. Do I need to go to college to learn these from the start or something. Seeing how a same type of game, for example a Platformer, can be done in so many different ways makes me think if, it's okay to just code the game in my own way. If I coded the game the way I understand it will it be considered a "good" way ? Not only that, will the performance of my "understandable" code can be considered great ?

Sorry if this sound like a dumb thing. I'm just a beginner. Also, English is not my main language.

Thanks for hearing me out (•◡•) /

[veethree]

You and i are not so different. I also like to understand what everything in my game does, As a result i rarely use third party libraries and instead design my own.

As a direct result of this, I have very few actual finished "games" under my belt, But a ton of prototypes and half finished games.

However, My goal was never really to make games. I just enjoy programming and figuring out how to implement various things. Thats why löve appeals to me, It doesn't care how your game is structured or how anything works. Just gives you a set of basic tools and you have to build on top of that.

If I coded the game the way I understand it will it be considered a "good" way ? Not only that, will the performance of my "understandable" code can be considered great ?

As long as it works and performs reasonably, No one cares how the code is structured / looks. Unless maybe when multiple people work on the same codebase.


To answer your title question, No. There's no correct way. Specially with löve.

[darkfrei]

I don't use any of libraries at all, but I code my own libs for the specific problems. https://github.com/darkfrei/love2d-lua-tests

The right way is to do the libs and use methods like:

Code: Select all

 -- mylib.lua
local mylib = {}
mylib.velocity = 60 -- defined velocity

function mylib:load()
	self.x = 0
	self.y = 0
end

function mylib:update(dt)
	self.x = self.x + self.velocity*dt
	self.y = self.y + self.velocity*dt
end

function mylib:draw()
	love.graphics.setColor (1,1,1)
	love.graphics.circle ('line', self.x, self.y, 20)
end

return mylib -- most important thing!

And call it from main.lua:

Code: Select all

-- main.lua
local mylib = require ("mylib")
function love.load()
	mylib:load()
end

function love.update(dt)
	mylib:update(dt)
end

function love.draw()
	mylib:draw()
end

here the method

Code: Select all

function mylib:load() -- semicolon
	-- your code
end

is the same as

Code: Select all

function mylib.load(self) -- point
	-- your code
end

and the calling this method from any place

Code: Select all

mylib:load() -- semicolon

ist the same as

Code: Select all

mylib.load(mylib) -- point, yes, we provide the lib as own argument

----------------------------------------------------------------------------------------------------------
See the A guide to authoring Lua modules:
http://kiki.to/blog/2014/03/30/a-guide- ... a-modules/

Rule #1: Do what Lua does http://kiki.to/blog/2014/03/30/rule-1-do-what-lua-does/
Rule #2: Return a local table http://kiki.to/blog/2014/03/31/rule-2-r ... cal-table/
Rule #3: Allow monkeypatching http://kiki.to/blog/2014/04/04/rule-3-a ... ypatching/
Rule #4: Make stateless modules http://kiki.to/blog/2014/04/11/rule-4-m ... s-modules/
Rule #5: Beware of multiple files http://kiki.to/blog/2014/04/12/rule-5-b ... ple-files/
Rule #6: Break the rules http://kiki.to/blog/2014/04/14/rule-6-break-the-rules/

[pgimeno]

I disagree with darkfrei. The right way is to make things the way you feel comfortable with.

I'd personally stay away from Windfield; it's just an abstraction layer on top of love.physics, and a complex one at that, unnecessary except maybe for very complex programs (and bloated, which might make it a bottleneck). love.physics is a library in itself, no need to add crap to it.

Tiled is something different: it's just a tool to create maps, and it gives you the map data so you can use it in your project; it's not a library in itself. How to handle that data is a different matter; I'd also stay away from STI, which is regarded by many as "THE" Tiled maps rendering library. Tiled generates Lua data files that you can directly use, so you don't actually even need a library. I wrote my own map renderer based on sprite batches. I didn't find the task complex enough to even merit writing a library for that.

Some other libraries are pretty fine and they actually take work from you with little learning effort; for example, timer, camera, state change and resolution management libraries are in that category. They'd be easy to recreate, but no need to bother when they are already there. There are other libraries that handle very complex tasks that would be very involved to write for you, like GUI libraries or collision libraries. And then there's abstraction libraries that I regard as unnecessary, such as Windfield.

So, with libraries, the answer is a clear and unequivocal "it depends".

As for getting dizzy from trying to learn stuff, maybe you're taking more than you can process at a time. Try to learn the very basics at first, and when you realize you need something that you can't do with what you know, check if the library has provisions for it; don't try to learn it all from the beginning.

[darkfrei]

I disagree with darkfrei. The right way is to make things the way you feel comfortable with.

I disagree with darkfrei too, the right way must be pretty ironic, but it was not enough.

[BrotSagtMist]

Stay away from youtube stuff, its just a time eater with very little information density.
Just read the documentation.

Learn by doing, target a goal, then read what you need for that specific goal instead of skimming through tons of nonsensical opinions on libs that youll never use anyway. If you want for example start with a tetris clone, you will not need any lib for that, its a simple thing you can write in minutes:
Get the screen size, divide that by how much blocks you want on the screen, that gives a blocksize and you got scaling covered.
Create a 2D Table to be filled with blocks, color tables ideally, traverse them in the draw loop and draw them as rectangle and you got you graphics.
And then you just have 4 coordinate sets for the falling blocks which you draw too and then increase in their Y to have them fall and depending on if left or right is pressed on the keyboard increase or decrease X.
Finally a little check if these coordinates, when divided through their size and floored, touch a filled entry in the grid table. If so, fill them into that grid and let a new block fall.
Thats all, tetris is done.
From such a start one may spend hours playing with enhancing the graphics and learn more than any tutorial may ever teach you.

[Gunroar:Cannon()]

Structure. With good structure everything is possible. Store data well.

Use tables/dicts

Code: Select all

Player = {
    x = 100,
    y = 0,
    speed = 10
}-- a table, also called dictionaries in python and others

Use lists/arrays

Code: Select all

scores = {0,1,3,10}

Functions return stuff. Required files/libs also return stuff. Stuff are variables.Every variable is a type. Only types are table (as above), number (1, 3, etc), string ( "Hello"), boolean (true,false), function, nil (which is ... nil) and userdata (C++ stuff and the like, forget these for now)

Code: Select all

function getName(creature)
    if creature.speed > 100 then
        return "Fast Creature"
    else
        return "Normal Creature"
    end
end

local name = getName(Player) -- returns string "Normal Creature"

Tables can store any variable of any type (functions, etc). The fact that files also return something just mean at the end of a one file module you'll find

Code: Select all

return moduleForSomething

so you get

Code: Select all

moduleForSomething = require( "moduleForSomething")--with no ".lua" attached

A function in a table uses self to talk about that table it's in

Code: Select all

Cat = {
    name = "Nell",
    getName = function(self)
       return self.name
    end
}

print(Cat:getName()) -- returns "Nell" using : is the same as Cat.getName(Cat)

Just some basic stuff...errmm...maybe it makes modules seem less complicated, maybe not. Practice makes you better I guess. Trying is the correct way to code then.

[Nikki]

At some point in your beginner phase, you just need to stop looking up random opinionated youtube tutorials,

Just try and write the (simple but doing something new for you) thing you want, the api docs are enough data,
look through them and maybe copy some examples, grow the examples in interesting ways.

Hopefully you can grow your ambition sort of in line with your knowledge, slowly making more and more complex playthings.
Then you'd end up recognising certain repetitive patterns, and at some point those libraries start making more sense.

But for now, wisest thing is just staying away of most 3rd party stuff, love2d on its own is more than enough.

[togFox]

My first real project was a single main.lua file with over 1000 lines of code.

I don't do that anymore, I use modules and libraries, because I now know how, but point is, that single file with 1000 lines of code worked and nobody saw it but me and me didn't care.

(... also use libraries if they are good. Saves your time and brain power and lets you slowly ease into the advanced stuff.)

[ReFreezed]

My first real project was a single main.lua file with over 1000 lines of code.

I don't do that anymore, I use modules and libraries, because I now know how, but point is, that single file with 1000 lines of code worked and nobody saw it but me and me didn't care.

At some point you may turn around again and think "hey, splitting up the code to so many files just takes time and isn't actually helpful in creating structure - sometimes it's even detrimental - so I'll just allow my files to have 10 000 lines of code if necessary". That's what happened to me.

Anyway, I agree that the only one it should matter to how your code looks is you yourself (and anyone you share the codebase with, like co-workers), and if you don't care then it's still fine. It doesn't matter to the end users of the program what the code looks like - only that the program runs properly.