LÖVE

Posted: **Mon May 15, 2017 9:14 pm**

Haven't been posting progress updates in a while.
Unfortunately, that's because there hasn't been much progress

.

Recently I've updated another part in the wiki; it's about bonuses that add multiple balls into the game.

The first appendix has been included. It is about storing levels as text strings, suggested and largely implemented by airstruck (thanks).

Posted: **Mon May 15, 2017 9:19 pm**

I think, I have an idea for another appendix: "How to continue working on a project if you are starting to lose interest".
Unfortunately, I find that I have very little to say on the subject.

Posted: **Sun May 21, 2017 12:17 pm**

I've updated two more parts in the wiki: Life and Next Level Bonuses and Random bonus generation.

This finally concludes the 6-part sequence on bonuses.

Posted: **Sun May 28, 2017 5:22 am**

Two more sections: simple main menu and wall tiles.

Posted: **Sun May 28, 2017 5:52 am**

Hey Noway, well done there and impressive amount of prescience!
Looks fine, I don't have any major issues with the code.

Regarding the GUI buttons, I think it's really helpful having a GUI container, something like:

Code: Select all

function gui.new_container( o )
  return { position = o.position or vector( 0, 0 ),
    width = o.width,         
    height = o.height,
    children = {}, -- list of elements (ie: buttons)
    selected = nil -- currently selected element, aka the "element in focus" }
end

-- get the FIRST element at the given position
-- this is a simplification since elements can overlap in theory
function gui.query_container ( c, pos )
  for i = 1, #c.children do
    local e = c.children[i]
    if gui.inside ( e, pos ) then
      return e
    end
  end
end

-- update in reverse (in case any element is destroyed during the iteration)
function gui.update_container ( c, dt)
  for i = #c.children, 1, -1 do
    gui.update_element( c.children[i], dt )
  end
end

Ironically, GUI is an area where object-orientation is quite useful.
This makes the code slightly cleaner and will allow you to build upon it by introducing new types of elements:

Code: Select all

function menu.mousereleased( x, y, button, istouch )
   if button == 'l' or button == 1 then
      local q = menu_container.selected
      if q == start_button then
         gamestates.set_state( "game", { current_level = 1 } )
      elseif q == quit_button then
         love.event.quit()
      end
   elseif button == 'r' or button == 2 then
      love.event.quit()
   end    
   menu_container.selected = nil
end

function menu.mouse_prerssed ( x, y, button )
      menu_container.selected = gui.query_container ( menu_container, vector(x, y) )
end

So yea, no major complaints - my examples are not that good, but show how to move the code in a specific direction.

Also, make sure the "new_button" function accepts a filename so that you don't have to pass around quads and other internal objects.

Posted: **Mon May 29, 2017 7:16 am**

Regarding the GUI buttons, I think it's really helpful having a GUI container, something like:

Ok. I've got the idea.
IMO as long as there aren't many GUI elements, up to 5 - 7, it is possible to go without containers.
On the other hand, in the part 3-16 on Final screen and Credits I have a code like

Code: Select all

function gamefinished.update( dt )
   buttons_with_url.update_button( gamecode_button, dt )
   buttons_with_url.update_button( love_button, dt )
   buttons_with_url.update_button( vector_button, dt )
   buttons_with_url.update_button( tileset_button, dt )
   buttons_with_url.update_button( bungeefont_button, dt )
   buttons_with_url.update_button( cmusounddesign_button, dt )
   buttons_with_url.update_button( ngruber_button, dt )
   buttons_with_url.update_button( bart_button, dt )
   buttons_with_url.update_button( qubodup_button, dt )
   buttons_with_url.update_button( tinyworlds_button, dt )
   buttons_with_url.update_button( edgardedition_button, dt )
   buttons_with_url.update_button( music_button, dt )
end

In this case, GUI containers really are convenient.

Ironically, GUI is an area where object-orientation is quite useful.
This makes the code slightly cleaner and will allow you to build upon it by introducing new types of elements:

I've run into this issue while defining `button_with_url` (it is similar to `button`, but has an associated url, which is opened on click). Instead of inheriting `button` I've simply copied most of the code. Probably, no the best solution, but it can be tolerated as long as it is not overused.

I agree that GUI containers should be mentioned somewhere.
I'll think on how to incorporate them into the tutorial.
Currently I opt to postpone this topic until part 3-16 on Credits and Final screen.

Also, make sure the "new_button" function accepts a filename so that you don't have to pass around quads and other internal objects.

I can't see the point. What do you mean?
If I use a single image file for different buttons, I have to tell a button constructor which part of the image to use.

Posted: **Mon May 29, 2017 8:55 am**

noway wrote: ↑Mon May 29, 2017 7:16 amI've run into this issue while defining `button_with_url` (it is similar to `button`, but has an associated url, which is opened on click). Instead of inheriting `button` I've simply copied most of the code. Probably, no the best solution, but it can be tolerated as long as it is not overused.

One way to handling this could be callbacks/events, something like "function button.onClick()".
Yep, it's true that you could probably get away without containers in this case,
my point was that you want to steer people in a good direction that they can build upon.
I admit that GUI isn't my area of expertise, either way
it might be good to check out the code behind a few of the existing GUI libs in Lua,
since there are standard ways of handling the common issues mentioned above.
Good luck!

Posted: **Tue Jun 06, 2017 2:32 pm**

Several updates in the wiki: Side Panel, Score, Fonts, More Sounds

Posted: **Sun Jul 02, 2017 5:34 am**

I've finished the remaining parts of the tutorial: credits screen and packaging.

All in all I don't like how the Chapter 3 has turned out.
My initial idea has been to discuss typical problems arising in game programming on real-life examples.
However, most of the code in Chapter 3 has become too specific for this Arkanoid and hardly can be transferred to any other project.
Besides, technical details of the specific implementation obscure the general ideas.
I think, instead of describing a step by step code evolution, a better approach would be to restructure the Chapter 3 into a series of loosely related articles grouped by a common subject. For example, a group on visual effects with articles on postprocessing, particle effects, etc. Basically, topics currently placed in appendicies should become the main material for this chapter.

This will require a lot of work that I currently don't want to deal with.
Instead I would like to concentrate on making a small but well-polished, publishable quality, game.
As one of the first steps, this will require to find an artist and a sound designer.

Regarding the tutorial, the plan is following:
1) Update the Chapters 1 and 2.
2) Find a native speaker to get help with the text proofreading.
3) Restructure the Chapter 3 into a series of "additional topics".

LÖVE

Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.

Re: Need Critique on Tutorial Series on Making Arkanoid-type Game.