Design Talks - Your Game Module

Well for example if you had an array of sequence data you could truncate this

 if image[isoldat[numero].typesoldat].typedep==1 then sequenceData=sequence.cavgent elseif image[isoldat[numero].typesoldat].typedep==-1 then sequenceData=sequence.elf2 elseif image[isoldat[numero].typesoldat].typedep==2 then sequenceData=sequence.golem elseif image[isoldat[numero].typesoldat].typedep==3 then sequenceData=sequence.araigne elseif image[isoldat[numero].typesoldat].typedep==4 then sequenceData=sequence.ours elseif image[isoldat[numero].typesoldat].typedep==5 then sequenceData=sequence.rhino elseif image[isoldat[numero].typesoldat].typedep==6 then sequenceData=sequence.chien end

to

 sequenceData=sequence[image[isoldat[numero].typesoldat].typedep]

@remi  I imagine you have many thousands of lines of code to manage the movement and physics in your apps.  If I didn’t use corona Box2D physics for most of my collisions and movement, my code would be much more bloated.

My apps range from 5k lines to 40k lines.  My largest app, which is on the back burner at the moment, is looking like it will be 60-70k lines by the time I finish (it has extensive AI, math, and genetics modules).  However, with better coding practices I think I can cut it down to 40-50k.  For example, I recently shaved off 80% of a math module by rewriting the entire thing in radians instead of degrees.

Agree with @sporkfin…  always use framework code wherever possible.  There are rare occasions where you can do it better (not using thousands of transitions for example) but not often; and physics is definitely not one of them.

Also, you have zero white space/line breaks - it is just a wall of code.  It must be a nightmare to work on?

about 8.5k of actual code for https://play.google.com/store/apps/details?id=org.davebollinger.dropstack

PS \> ./cloc.exe DropStack 46 text files. 46 unique files. 10 files ignored. http://cloc.sourceforge.net v 1.64 T=0.12 s (386.9 files/s, 101834.9 lines/s) ------------------------------------------------------------------------------- Language files blank comment code ------------------------------------------------------------------------------- Lua 45 1877 1463 8503 ------------------------------------------------------------------------------- SUM: 45 1877 1463 8503 -------------------------------------------------------------------------------

Looking at my code and @remi’s code, it reminds me that I miss the good old fashioned “switch” statement that Lua doesn’t support.  I could especially use that for my AI modules.  There are, of course. workarounds but I’m always thinking someone else must have a better solution for this.  Hmmm. . . maybe a new topic.

Sometimes Box2D physics won’t cut it - for instance if you were making a Sonic-clone, you’d have to roll your own.

But woah there’s a hell of a lot of unformatted if > then > elses there. I now have a rule, any code in a nested if gets refactored out to a separate function, and if any if/else branch has more than one line, that also gets refactored.

I wasn’t expected some fast review. Thank you so much!

@sgs Good idea!

For me it’s quite easy to find my way in my code. With sublime text it’s very easy to find files and function. I need aroud 15 sec to find the code I am looking for.

What do you mean by no space or line break?

@sporkfin Can you explain more how physics could help?

I see how it can reduce some part (for example in the three files send previously, I see only one function, it’s to avoid objects (100 lines))

but how can physics can help for example(I think there is a way but I don’t know how):

  • to know if a moving object can be catch up by an another one and in which way it need to go to catch it the fastest?
  • map are defined with two kind of points. Road and unauthorize walk zone. There is any way to find the shorter way to go back on the road without walking on an unauthorize zone? 

@remi look at SSK as that has simple functions for returning direction vectors - will save you lots of code.

Also look at jumper for path finding (rather than your own implementation).  There is a tutorial here - http://battleofbrothers.com/sirchris/pathfinding-in-corona-with-jumper-and-a-star/

a long series of if-elseif’s can be refactored as a table-lookup, fe see:  http://lua-users.org/wiki/SwitchStatement

His algorithms are for grid map only? For grid it is simpler, I can change my map to work a bit like grid but it will still be a bit weird and use a lot of resources if my tile are small.

To find the shortest way it’s not complicated if the goal don’t move. But when the goal move it’s harder. For example A is going to B and C try to catch A. Which way C need to take to catch A? 

i haven’t looked at your code, but pathfinding in general, as a discrete topic, is not dependent on a grid structure - all it needs is a graph of connected nodes.  true that a grid is often used just as a simple way to imply that graph, but you could just as easily perform pathfinding on something like this.  look for the concept, rather than a specific grid-based implementation.

You may find this discussion/page interesting: http://lua-users.org/wiki/SwitchStatement

@sporkfin,

You might like this:

function switch(n, ...) for \_,v in ipairs {...} do if v[1] == n or v[1] == nil then return v[2]() end end end function case(n,f) return {n,f} end function default(f) return {nil,f} end local test = 2 switch( test, case( 1, function() print("one") end), case( 2, function() print("two") end), case( 3, function() print("three") end), default( function() print("default") end) )

@RG Yes I like!  Thanks also to @davebollinger!  Your two great minds where thinking alike  :wink:

@remiduchalard  No, I don’t think physics will be useful for your app.  I was just stating that using physics makes my apps smaller but your app wouldn’t really make sense with physics.

@sporkfin Thank you for your analyse

Have you in all your apps a module to manage timer, transition and enterframe listener to put them in pause, resume, cancel…

To manage them with tag like for transition?

@remiduchalard  Yes, I keep master lists of all transitions, objects, and timers in my “master module” - mentioned in my first post in this discussion.  I also associate the timers and transitions with their related objects so if their object dies the timers and transitions will be removed from the master list.

[lua]

– the death of an object removes all of it associations including timers and transitions before the object is cleared

function mt:death(o)

if (o and o ~= nil) then

     if o.shaderInfo  then mt.shader.removeObject(o) end

     if o.timer then mt:clearTimer(o.timer)  end

     if o.timer2  then mt:clearTimer(o.timer2)  end

     if o.shadowList  then mt:clearFromTable(o.shadowList, o) end

     if o.myTable then mt:clearFromTable(o.myTable, o) end – object list “sphere”, “egg”, “worm” etc.

     if o.trans then mt:clearTrans(o.trans) end

     if o.eye then mt:clearObject(o.eye)      end

     if o.shadow then mt:clearObject(o.shadow) end

     if o.ripple then mt:clearObject(o.ripple) end

     if o.ripple2 then mt:clearObject(o.ripple2) end

     mt:clearObject(o)  end

end

[/lua]

Hi! I definitely use a game module. In fact, I use TONS of modules. Typically I will have a “gameEngine” module, containing an “enemiesManager” module, containing for example an “alienShip” module, containing an “alienShipBulletManager” module, containing an “alienShipBullet” module. It sounds very cumbersome and complicated, but the reality is the opposite: yes, it means you get lots of modules, but each modules has a clean, simple, welldefined and easy to understand (and debug) job.

I also have a really handy parent/child setup for these, which helps me speed up my coding tremendously. Handy meaning consistent and easy to read.

Also of note, I actually have an appEngine module called from main.lua that creates the game in it’s own module and displayGroup, so in essence I can have multiple instances of my game running in one app, side by side and scaled / rotated differently.

So, as far as I’m concerned, you can’t have enough hierarchical levels in your modules and displayGroups!

you use:

if (o and o ~= nil) then

you can use:

if o then

with the same result as yours…

your statement

 if o.shaderInfo then mt.shader.removeObject(o) end 

Usualy, I create the if statement to check if the argument is valid or not inside the function not outside.

why?

because in your case…if in other parts of your code you call more times this function, you will need to create an “if” in all of them.

in my case, I only need to create 1 time…inside the function.

you have this problem here:

if o.timer then mt:clearTimer(o.timer) end if o.timer2 then mt:clearTimer(o.timer2) end

since you don’t have any object check inside your function you had to create the if 2 times to check if the object exists before going to the function…

regards,

Carlos.

I don’t create games…but I do create business apps.

Usualy I create functions that I know I will use it in other apps or more than 1 time in the same app. self-contained modules.

in my last projects, I studied all buttons, shadows, menus from material design website. tried to mimic their results.

my UI.lua file has this functions:

-- topBar -- testNetworkConnection -- urlEncode -- networkRequestImages -- networkRequest -- endTransitions -- dbCopy -- divider -- changeState -- background -- backgroundStatusBar -- addCircleShadow -- circle shadow -- createShadow -- rectangle shadow -- bottomShadow -- line shadow -- checkBox -- switchButton -- tooltips -- toolbar -- menuTreeItems (use bottomNavigation) -- menuFourFiveItems (use bottomNavigation) -- bottomNavigation (use this function instead menuTreeItems or menuFourFiveItems) -- listStyleSheet -- actionButtonSpeedDial (revise code) -- actionButtonMenu (revise code) -- actionButtonChange (revise code) -- actionButton -- button -- unselectButton -- used for Button -- selectButton -- used for Button -- disableButton -- used for Button -- changeButtonState -- used for Button -- changeButtonColors -- used for Button -- enableButton -- used for Button -- dialogBox -- dialogBoxLogin -- dropdownButton -- card -- cardBlock -- cardBlockLinks -- cardContentImage -- cardContentImageAvatar -- cardBlockLinks3x -- chip -- gridList -- list -- menu -- slider -- sliderEditable -- sliderAnimated -- snackbar -- subHeader -- tabs -- use only with 3 or less elements -- tabsScroll -- use for any number of elements (if you have more than 3 is recomended using center=false) -- newTextField -- focusNewTextField -- used on newTextField -- unfocusNewTextField -- used on newTextField -- resetNewTextField -- used on newTextField -- createBackgroundFields -- used on newTextField -- showErrorMessage -- used on newTextField -- utf8\_decode -- utf8\_encode -- newCalendar -- get\_year\_month\_day -- get\_days\_in\_month -- get\_day\_of\_week\_alternative -- get\_day\_of\_week -- get\_month -- get\_day\_week\_month\_day -- get\_date\_parts\_alternative -- get\_date\_parts -- maxWidth -- maxChars -- limitString -- splitString -- addTouch -- return self if return\_self=true -- fileExist -- menuScrollNew -- slideRotate -- removeMost

right now its a mess and I need to remove some of this functions to different files…not related to UI…this all functions are about 16k lines…all functions have an example how to use them so I can remember later the code needed to execute them properly so the real code is less than this.

with the help of this file. usually, my scenes are about 200 to 300 lines. oh, I use my own code to create/remove scenes it’s about 40 lines to take care of any transition from 1 scene to another…100 lines to remove any scene…