Hello chaps!
Let me introduce myself, I’m currently trying out the Love framework and so far it’s been a very pleasing experience, I’ve a project in mind, a simple platformer, just to get the hang of love’s workflow and design methodology. I’ve previous programming experience (C, mainly), but this is the first time I give Lua a try. I must say it is pretty impressive, and strongly reminds me of MATLAB’s m scripting language, which I personally love.
Anyway, I’m here because I’m mainly looking for feedback about the things I’m doing or, at least, I’m pretending to do. So far, I’ve coded a simple player movement description. I’m currently using placeholder sprites (MegaMan FTW!) but, eventually, I’ll replace them with custom art.
Please guys, check out my code and provide all the feedback you consider appropriate. I’ve documented my code whenever possible, and, as clear as I could, but feel free to ask anything. This is my first shot at game design, and I’d like to learn as much as possible.
Actions: Left, Right cursor arrows for movement, “W” key for jumping. Press and hold right arrow for “sprinting” to the right.
Please, Give me your feedback! (Updated 01/01/12)
Forum rules
Before you make a thread asking for help, read this.
Before you make a thread asking for help, read this.
Please, Give me your feedback! (Updated 01/01/12)
- Attachments
-
- PlayerTest.love
- (17.36 KiB) Downloaded 168 times
Last edited by verilog on Mon Jan 02, 2012 3:28 am, edited 1 time in total.
Re: Please, Give me your feedback!
I didn't go over all of it, but your code looks fairly clear. I personally try to write code as succinctly as possible but I guess that could be a matter of style.
Could become:
Secondly, I'm not sure why an object's destroy function has to tinker with global data - it doesn't look like very good OO design.
Class object are supposed to be self-contained.
Why not make a "DestroyObject" function that manages "destroyList" instead of allowing "destroyList" code to creep into your game object classes.
PS. Keep at it man, looks like you know what you're doing. Lua scripting is quite different than C/C++ and you'll get better at it with practice.
Code: Select all
--This will destroy the player when needed
function player:destroy(obj)
destroyList[#destroyList + 1] = {}
destroyList[#destroyList].object = obj
destroyList[#destroyList].time = love.timer.getTime()
end
Code: Select all
function player:destroy(obj)
local t = { object = obj, time = love.timer.getTime() }
table.insert ( destroyList, t )
end
Class object are supposed to be self-contained.
Why not make a "DestroyObject" function that manages "destroyList" instead of allowing "destroyList" code to creep into your game object classes.
PS. Keep at it man, looks like you know what you're doing. Lua scripting is quite different than C/C++ and you'll get better at it with practice.
- josefnpat
- Inner party member
- Posts: 955
- Joined: Wed Oct 05, 2011 1:36 am
- Location: your basement
- Contact:
Re: Please, Give me your feedback!
I am quite impressed with how clean the code is. This is a very good basis for an entire game.
Missing Sentinel Software | Twitter
FORCIBLY IGNORED.
<leafo> when in doubt delete all of your code
<bartbes> git rm -r *
<bartbes> git commit -m "Fixed all bugs"
<bartbes> git push
FORCIBLY IGNORED.
<leafo> when in doubt delete all of your code
<bartbes> git rm -r *
<bartbes> git commit -m "Fixed all bugs"
<bartbes> git push
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: Please, Give me your feedback!
It looks good. I've some small comments on the player.lua file, which is the one I reviewed.
There is some unnecessary repetition, due to the use of a "magic number" for the current animation. It needs a comment to be understood - the following code repeats several times, changing the image, the number and the comments.
The images are stored on different variables:
Also, you make a difference between the "standing still" and "running". The former is achieved with a "normal image" but the later needs an "animation". Try not to have these special cases. I mean, use an animation for everything! The still animation can simply be one frame.
Once you do that, you can use a string for the player direction: player.direction = "StillLeft" instead of player.direction = 6 . If also a table for the player animations instead of a bunch of variables, you can get rid of all those ifs:
Also, try to use love.keypressed and love.keyreleased instead of love.keyboard.isDown . The usual way of doing this is by adding specific boolean flags for your player:
Use those variables in the rest of the code. Instead of this:
Do this:
I know this looks cumbersome in principle. The good thing about it is that your player movement code now depends on those variables; it doesn't depend on the keyboard any more! Later, if you want the player to be able to change the control scheme (to use another set of keys, or a joystick) you will not have to meddle with the player movement code at all; just make the joystick or the new keys set the player.WantXXX variables.
Another advantage is that you can use the same code for enemies; you can have a "think" phase where the enemies set their "want" variables - (enemy.wantRight == true) and a "move" phase in which they move accordingly with their desires. You can even allow a second player to move the enemies without much trouble!
So it's a bit more work, but the benefits are huge!
That's all I could think for now. Regards!
There is some unnecessary repetition, due to the use of a "magic number" for the current animation. It needs a comment to be understood - the following code repeats several times, changing the image, the number and the comments.
Code: Select all
if self.direction == 1 then --(Direction 1 => still left)
self.image = playerStillLeft
--draw player
love.graphics.draw(self.image, newX,newY,0,spriteScaleX,spriteScaleY,0,0)
end
Code: Select all
...
local playerStillLeft = love.graphics.newImage("media/MegaStillLeft.png")
Once you do that, you can use a string for the player direction: player.direction = "StillLeft" instead of player.direction = 6 . If also a table for the player animations instead of a bunch of variables, you can get rid of all those ifs:
Code: Select all
...
local playerAnimations = {}
playerAnimations.StillLeft = newAnimation(...)
...
self.animation = playerAnimations[self.direction] ---- > this is the important line
self.animation:draw(newX,newY,0,spriteScaleX,spriteScaleY,0,32)
Code: Select all
function love.keypressed(key)
if key=="right" then
player.wantRight = true
end
...
end
function love.keyreleased(key)
if key == "right" then
player.wantRight = false
end
end
Code: Select all
if love.keyboard.isDown("right") then ...
Code: Select all
if self.wantRight then ...
Another advantage is that you can use the same code for enemies; you can have a "think" phase where the enemies set their "want" variables - (enemy.wantRight == true) and a "move" phase in which they move accordingly with their desires. You can even allow a second player to move the enemies without much trouble!
So it's a bit more work, but the benefits are huge!
That's all I could think for now. Regards!
When I write def I mean function.
Re: Please, Give me your feedback!
Hey guys! Thank you very much for your input, I really appreciate all your suggestions.
Ivan: You’re right; I like your function a lot more than mine, I’ll definitely review that. Thank you! Initially I found Lua a little bit cumbersome, coming from C, I’ve developed some habits and vices, lol, but, aye, it is getting easier with practice.
Josefnpat: (nice avatar!) Thanks man, I’ve learned through the years that clean code definitely makes things a lot easier
Kikito: Thank you for your input man (and tutorials) , I’ll definitely change the way I address each animation, using a string makes a lot more sense, also, I’ll be using animations for most of the players actions – that’s a good suggestion!
I’ll get rid of all my animations variables and use a table instead, that’s a nice and clean way of storing the animations, thanks for the example code, it will definitely come in handy.
Last but not least, thanks for the keyboard managing tips, I’ll as well include those suggestions in the code, I’d also like, at some point, to include joystick support, and your suggestion will make things a lot easier in the future.
Thanks again guys, I’ll keep you posted with my progress in the future (and doubts, I’m sure)
Cheers!
Ivan: You’re right; I like your function a lot more than mine, I’ll definitely review that. Thank you! Initially I found Lua a little bit cumbersome, coming from C, I’ve developed some habits and vices, lol, but, aye, it is getting easier with practice.
Josefnpat: (nice avatar!) Thanks man, I’ve learned through the years that clean code definitely makes things a lot easier
Kikito: Thank you for your input man (and tutorials) , I’ll definitely change the way I address each animation, using a string makes a lot more sense, also, I’ll be using animations for most of the players actions – that’s a good suggestion!
I’ll get rid of all my animations variables and use a table instead, that’s a nice and clean way of storing the animations, thanks for the example code, it will definitely come in handy.
Last but not least, thanks for the keyboard managing tips, I’ll as well include those suggestions in the code, I’d also like, at some point, to include joystick support, and your suggestion will make things a lot easier in the future.
Thanks again guys, I’ll keep you posted with my progress in the future (and doubts, I’m sure)
Cheers!
Re: Please, Give me your feedback!
Hello guys and happy New Year!
During the past months I’ve been working on this project during my free time, making a little bit of steady progress, I think. Let me show you what I’ve been up to. Below you’ll find the most recent version of my platformer code.
I’ve replaced the old mega man sprites with my own custom sprites, the player is supposed to be a flying saucer with mechanical arms and legs, kind of a robot. It may sound weird, but hopefully it will make sense with the kind of gameplay I plan to show.
Please check it out and tell me what you think, currently the basic actions are as follows:
Left, Right cursor arrows for movement. Hold each arrow for “sprinting” to that direction.
“W” key - Jump
“D” key – Fire (Currently in two directions only: left or right)
This is still all very experimental, so please check it out and, as always, provide all the feedback you consider appropriate.
A little bit about the code:
You’ll notice different animations are chained together and triggered by a specific action key (walk, run, jump, fire). The most direct solution for me to implement this was using Finite State Machines, the most recent version of the code implements tables for this, storing each state data in each table entry, and cycling trough them accordingly. Past versions of my FSM system used a bunch of nested if and elseif statements, making things a little bit messy.
The great thing with my new table-based approach is that I can further add (or remove) new states quickly and easily into specific actions.
Other thing you may notice is that all my media is loaded into a table, actually a 2D matrix, where I store the image file and the corresponding animation in the same row, hopefully this will come in handy when loading specific animations only.
You’ll notice also that, currently, the jump action is a little bit “restrictive” in the sense that you cannot jump and move at the same time. The reason for this is that I wish to add a different animation for this case, different from the “regular” jump. But I must confess that I’m a little bit afraid of loading to many images into RAM, so I would like to ask, is there any clear estimation of how many image data (for the main player character) is “too much”?
During the past months I’ve been working on this project during my free time, making a little bit of steady progress, I think. Let me show you what I’ve been up to. Below you’ll find the most recent version of my platformer code.
I’ve replaced the old mega man sprites with my own custom sprites, the player is supposed to be a flying saucer with mechanical arms and legs, kind of a robot. It may sound weird, but hopefully it will make sense with the kind of gameplay I plan to show.
Please check it out and tell me what you think, currently the basic actions are as follows:
Left, Right cursor arrows for movement. Hold each arrow for “sprinting” to that direction.
“W” key - Jump
“D” key – Fire (Currently in two directions only: left or right)
This is still all very experimental, so please check it out and, as always, provide all the feedback you consider appropriate.
A little bit about the code:
You’ll notice different animations are chained together and triggered by a specific action key (walk, run, jump, fire). The most direct solution for me to implement this was using Finite State Machines, the most recent version of the code implements tables for this, storing each state data in each table entry, and cycling trough them accordingly. Past versions of my FSM system used a bunch of nested if and elseif statements, making things a little bit messy.
The great thing with my new table-based approach is that I can further add (or remove) new states quickly and easily into specific actions.
Other thing you may notice is that all my media is loaded into a table, actually a 2D matrix, where I store the image file and the corresponding animation in the same row, hopefully this will come in handy when loading specific animations only.
You’ll notice also that, currently, the jump action is a little bit “restrictive” in the sense that you cannot jump and move at the same time. The reason for this is that I wish to add a different animation for this case, different from the “regular” jump. But I must confess that I’m a little bit afraid of loading to many images into RAM, so I would like to ask, is there any clear estimation of how many image data (for the main player character) is “too much”?
- Attachments
-
- Draft.love
- Updated: 01/03/2012
- (308.2 KiB) Downloaded 52 times
Last edited by verilog on Wed Jan 04, 2012 12:42 am, edited 1 time in total.
Re: Please, Give me your feedback! (Updated 01/01/12)
I love the artwork. The animations are smooth and the graphics are fun.
Since you have only two speed states (walk/run), then transition based on the time a key is held is a bit jarring. I'd suggest making either the run or the walk speed toggled by another key, like SHIFT or CTRL. In a platformer, no one really ever wants to move slow. They aren't admiring the scenery and contemplating the fate of the universe. They want to go in the direction that leads them to the finish, and they want to do it fast. So, maybe make the walk speed/animation toggled by SHIFT. If someone wants to slow down, they have the option. But the default would get them through the level faster.
That's only my opinion, though. However you want to make your game is perfectly fine.
Since you have only two speed states (walk/run), then transition based on the time a key is held is a bit jarring. I'd suggest making either the run or the walk speed toggled by another key, like SHIFT or CTRL. In a platformer, no one really ever wants to move slow. They aren't admiring the scenery and contemplating the fate of the universe. They want to go in the direction that leads them to the finish, and they want to do it fast. So, maybe make the walk speed/animation toggled by SHIFT. If someone wants to slow down, they have the option. But the default would get them through the level faster.
That's only my opinion, though. However you want to make your game is perfectly fine.
Re: Please, Give me your feedback! (Updated 01/01/12)
Thanks, MarekkPie, I appreciate your comments.
I agree with you, in fact, I was planning to review the walk/run mechanic and change it to a switch method between the two speed states with a key, but I couldn't make up my mind about it. I think it will be easier for the user to switch to the desired state at any time.
Again, thank you for your input, man!
I agree with you, in fact, I was planning to review the walk/run mechanic and change it to a switch method between the two speed states with a key, but I couldn't make up my mind about it. I think it will be easier for the user to switch to the desired state at any time.
Again, thank you for your input, man!
Who is online
Users browsing this forum: No registered users and 93 guests