LÖVE

Posted: **Fri May 25, 2012 7:41 pm**

Hi,

I was wondering how do you handle your coding regarding efficiency, speed and as well cpu usage.
At the moment, I evolve my personally programming style and I think that is good, except I probably have to "optimize" it later.

To the point...

I would like to know how you handle things like gameStates, loops and efficient coding in generally.
Do you have some special methods or something like that?

I'm trying to make a dynamically menu, what means that I change a lot of X and Y coordinates if the user clicks on a menu point.
Also, I wonder what's better of the following things:

1) Use a Gui-library for buttons, etc.

or

2) Write the buttons as strings or images and check for collision (then hover them, mark them in another color).

Basically, the Gui-libraries base on the same system, what would be more resource-saving?

And regarding the gamestate, I essentially have two... "game" and "menu", but also other like "toGame" or if it's multiplayer "toGameMP" and so on.
I need them to hide/fade out the menu of the other gamestate.

The results are many ifs, also in other ifs and so on, like:

I call them every "dt".

...

As you can see, I'm confused.
I had a lot of other questions, but I forgot all of them.

Anyway, I'm would be very happy if you can explain and demonstrate your knowledge and experience.
Oh, and sorry for my english. I'm gonna "improve" it.

Greets

Posted: **Fri May 25, 2012 8:56 pm**

If you have two tables (game and menu) you can simply do this:

Code: Select all

function love.load()
menu = {}
--etc.

game = {}
--etc.

state = menu

end

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

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

and change status through "state = menu" or "state = game"

Posted: **Fri May 25, 2012 9:36 pm**

Don't worry so much about optimization. It's a huge trap. Wait until performance is a problem before you worry about it.

How I generally handle game states is to simply foward all love calls to whatever state is active. In that sense each state is like a mini love game.

Code: Select all

-- main.lua

global = {}       							-- Put all global values in this table
global.state = {} 							-- The current state
local callbacks = {'keypressed', 'draw'} 	-- The love callbacks that we want to forward

-- Forward love callbacks to the current state.
for k,v in pairs(callbacks) do
    love[v] = function(...) if global.state[v] then global.state[v](...) end end
end

-- newgame is the default state.
function love.load()
    global.state = require "new_game"
end

I will put each state into their own file to encapsulate them.

Code: Select all

-- new_game.lua

local state = {}

function state.keypressed(k)
    if k == "return" then global.state = require "pressed_enter" end
end

function state.draw()
    love.graphics.print("Press enter to enter the next state", 5, 5)
end

return state

Code: Select all

-- pressed_enter.lua

local state = {}

function state.draw()
    love.graphics.print("You pressed enter!", 5, 5)
end

return state

statetest.love: (865 Bytes) Downloaded 98 times

Of course, in practice you probably want something a little more sophisticated than this. It would be a good idea to tell states when they become active or inactive. etc.

Posted: **Fri May 25, 2012 10:07 pm**

I found programming much easier when using object oriented programming.
It allows you to extend and inherit values from parent classes, override methods etc...
So when it comes to programming in lua i found 32log which allows you to implement an OOP approach.

I need them to hide/fade out the menu of the other gamestate.

This was an annoying problem for me as well. getting menus to fade in and out...
What I did was create a class called Transition (which turned out pretty complex as I implemented easing and capabilities for swipe and zoom, and callbacks).

But in essence my Transition object takes an object (something which has a 'opacity' value associated with it) as a parameter.
The transition has an update function which adjusts the opacity value of the object passed.

Then in your main update function you can update whatever transitions you have

Posted: **Fri May 25, 2012 10:11 pm**

If I may quote a classic...

"The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet."

Generally, make a change to your program, then run it to see if it works. I generally have an FPS counter on screen so I can see what's going on, and if there are any huge performace issues from small changes then there's probably a bug causing it anyway.

Beyond that, only worry about speed when it is actually a problem, at which point you should profile your program to find out what is actually slowing it down a lot and focus on that one thing. But only do this if you absolutely have to, once your program actually works.

So don't worry about speed. For you, especially starting out, having a well-structured program that works is way more important than speed. If you have a well-structured program that works, then it should work reasonably fast anyway.

Posted: **Fri May 25, 2012 10:28 pm**

Nixola wrote:If you have two tables (game and menu) you can simply do this:
[snip]
and change status through "state = menu" or "state = game"

That's generally the easiest, and (probably) most efficient way to do gamestates.

Posted: **Sun May 27, 2012 12:31 pm**

THANKS you all very much!

Thanks for the examples of gamestate-handling, it's easier to understand now.

@juno
Sounds good. I'm gonna do it this way, thanks!

@icefox
I read your quote already another time, but I didn't realise that it's true.
Regarding the FPS counter, do you have vsync enabled or disabled?

Let me know, if my game have continuous 60FPS and the cpu usage on my old laptop here (Core Duo T9550 @ 2.66 GHZ) doesn't pass 60%, would it also run on other systems, that have lower hardware?

And the real point why I have asked is that I wanted to see how efficient programming works, but I understood that I have to show some code so you can help.

Posted: **Mon May 28, 2012 7:19 am**

Petunien wrote:THANKS you all very much!
I read your quote already another time, but I didn't realise that it's true.
Regarding the FPS counter, do you have vsync enabled or disabled?

It's one of those things that sounds like a joke until you experience it.

Research has shown that programmers are actually pretty bad at guessing what is taking up lots of time in their programs, and are much better off actually measuring. So if you spend a lot of time worrying about making part of your program fast, there's a decent chance it's not even an important part of your program.

For testing I turn vsync off, since having it generally caps your framerate at 60 FPS (depending on your video card). I believe it's generally good practice to have it on if you can though (someone correct me if I'm wrong). Also, LOVE's functions to measure FPS seem to cap out at 999 anyway.

If you want to learn more about program efficiency in general, I'd suggest finding a good computer science book on algorithms and data structures. Usually efficient programming means understanding what kind of problem you are trying to solve and using the right tools for the job. Get something that explains program analysis and big-O notation.

Posted: **Mon May 28, 2012 8:10 am**

icefox wrote:Also, LOVE's functions to measure FPS seem to cap out at 999 anyway.

That's not the measurement, the main loop limits the game to 1000 FPS (and we'll assume that other frame is taken by drawing).

LÖVE

Efficient programming (generally)

Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)

Re: Efficient programming (generally)