I always find it bewildering when someone says "you should do this, this way, because it is better" and I reply with "It depends on the situation" suddenly it becomes a religious debate that is veering off-topic. Surely the prudent answer -- especially to someone who is barely learning how to develop games -- is that they should not be afraid to try different methods and see what the pros and cons are of each? If you don't agree with that then we should leave it at that, you gave your opinion and I gave mine.

As a side note I'm not really sure what you mean about Unity, it stores the delta time from the last frame and also has a fixed update function, like most engines I've seen have. There isn't anything forcing you to use a fixed timestep. There are many fully functional games out there that use a variable timestep, games have even created replays with variables timesteps. They had reasons, it wasn't just that they were bad programmers.

Fixed time-step trades a little up-front complexity for a lot less complexity later on.  As such, I think it is almost a good idea to use it, and to use it early.

Consider, for example, a rotating turret that rotates at a fixed speed and shoots whenever it reaches a 90° increment.  With fixed time-steps, this is trivial to implement:

def update(self):
  self.angle += angle_increment
  if self.angle % 90 == 0:
    self.fire_projectile()

Simple, intuitive code.  With variable time-step, the equivalent code would look something like this:

def update(self, delta_time):
  while int(self.angle / 90) != int((self.angle + delta_time * angle_increment) / 90):
    new_angle = int((self.angle + delta_time) / 90) * 90
    time_consumed = (new_angle - self.angle) / angle_increment
    delta_time -= time_consumed
    self.angle = new_angle
    projectile = self.fire_projectile()
    projectile.update(delta_time)
  self.angle += delta_time * angle_increment

Lots of hairy math, difficult to read, difficult to debug.

On 10/21/2018 at 3:49 AM, Kuurde said:

ey guys!

After some googling, and trying different stuff, I decided to start with very basic games as suggested in this article. The article also suggested to get your code reviewed, so here I am! Today I finally finished my first game, pong. ?

The source code can be found here: https://github.com/Kuurde/Pong

Oh, and you can play it here: https://kuurde.github.io/Pong/

 

Thanks in advance,
Kuurde

Hey,

First of all, congratulations on getting the game up on github. Version control is very important when coding in teams.

It works ( I assume). And that is what matters most!

The code is easy to read and its easy to see where you made changes. I loaded the code up and was able to see changes. I did not play the game, my environment is not set up for android programming. Thus a video clip or apk might be useful.

May I suggest a small demo video or the built version for easy download. Many developers are very busy, and would like to see the game at a click of a button.

I agree with the other poster. Fixed tick rate is very important for real-time games, and for turn based games which feature animation, for movement and effects.

I noticed you reflected the ball's speed, this is exactly how I made pong many many years ago. I would suggest moving into more advanced physics, such as rigid bodies, or using a physics library for your future projects.

Took me a bit to figure out what you were doing in the code, have not done java in some time, had to jump into an IDE to figure some things out.

I see the other AI player matches the y position of the ball.  Using better physics for future projects you may want to use dead reckoning calculations to resolve where an AI should be or not be. When having objects of two difference velocities this might be useful.

I might suggest moving AI into its own file or class in future projects, so you can start thinking about it separately, and think about larger scale AI using OOP. For this project its fine.

On 10/21/2018 at 2:06 PM, Kuurde said:

next game will be snake. I'll try to add nicer menus. And I should also figure out how fonts realy work in libgdx. Now I either have small text or blurry text when I try to scale it up.

From what I was told having a menu gets the programmer points, focus on menus with better functionally, unless you do wish to do graphics as well. For example, when you press a button play a sound like a beep, or animate the button being depressed, or when the mouse hovers over. Also having the menu align to a point on the screen regardless of resolution of the screen might be an additional challenge.

Quote

I did not play the game, my environment is not set up for android programming. Thus a video clip or apk might be useful.

For what it's worth, Kuurde provided this link to a browser version of the game. That worked for me, although I suppose it's possible it requires some component or other that not everyone has available (it does require WebGL at minimum).

39 minutes ago, Zakwayda said:

For what it's worth, Kuurde provided this link to a browser version of the game. That worked for me, although I suppose it's possible it requires some component or other that not everyone has available (it does require WebGL at minimum).

I see that now, thanks.

From what I see, one detail annoyed me when the ball/cube hits the top of the screen, the ball goes off the screen slightly. By eyeballing it, I suspect this is because the box is being drawn from a center or bottom point, so the top box bounds goes off the screen. A few extra logic statements might fix it.

Great stuff.

11 hours ago, WolfHound Coder said:

Hey,

First of all, congratulations on getting the game up on github. Version control is very important when coding in teams.

It works ( I assume). And that is what matters most!

The code is easy to read and its easy to see where you made changes. I loaded the code up and was able to see changes. I did not play the game, my environment is not set up for android programming. Thus a video clip or apk might be useful.

May I suggest a small demo video or the built version for easy download. Many developers are very busy, and would like to see the game at a click of a button.

I agree with the other poster. Fixed tick rate is very important for real-time games, and for turn based games which feature animation, for movement and effects.

I noticed you reflected the ball's speed, this is exactly how I made pong many many years ago. I would suggest moving into more advanced physics, such as rigid bodies, or using a physics library for your future projects.

Took me a bit to figure out what you were doing in the code, have not done java in some time, had to jump into an IDE to figure some things out.

I see the other AI player matches the y position of the ball.  Using better physics for future projects you may want to use dead reckoning calculations to resolve where an AI should be or not be. When having objects of two difference velocities this might be useful.

I might suggest moving AI into its own file or class in future projects, so you can start thinking about it separately, and think about larger scale AI using OOP. For this project its fine.

From what I was told having a menu gets the programmer points, focus on menus with better functionally, unless you do wish to do graphics as well. For example, when you press a button play a sound like a beep, or animate the button being depressed, or when the mouse hovers over. Also having the menu align to a point on the screen regardless of resolution of the screen might be an additional challenge.

 

 

Thanks for your review.

The default libgdx setup allows to build the game for different platforms. I just left the android one in there, but haven't built for it yet. It wouldn't work out of the box either, android won't understand my UP/DOWN keys that I used for input. During development I just focused on the desktop build. It was a nice extra that the HTML build worked right away

I decided not to go with a physics library as it is probably overkill for a game like pong. Also, I want to learn how the physics work, so I tried to write something myself. It's not perfect yet. Most stuff focuses on the x/y coordinates but these represent the bottom left of an object. That's why it goes a little off-screen at the top. For my next game I'll try to implement the fixed tick rate. Guess it will be useful as the snake moves with a fixed step as well. 

I agree with moving AI to its own class. Next game won't have AI, but I want to focus on not putting everything in one big file  Splitting game logic from rendering for example. 

9 hours ago, Kuurde said:

.. physics...

BOX2D is an easy one to start with it, works in flash, with Java. Its great for creating platformers with it. It draws a debug box right into the interface.

The basics is that you have to link your physics with gameobject's position. Have physics control the gameobject's position, but the object being able to run its own transformations for bone animation, or play a sprite sheet.

A big hurdle for your own custom physics engine is integrating constant time equations with stepped time in games. Also fast objects tend to overshoot into other objects, something to adjust the position to the point of contact is required. Usually you call an event on the physics object when collision occurs. Bullets for example, have a tendency to pass through thin objects and planes, bullets are often resolved with a raycast, with perhaps a slight timedelay for far away objects. (Ex see muzzle flash, 0.1s, hit.)

9 hours ago, Kuurde said:

...android won't understand my UP/DOWN keys that I used for input...not putting everything in one big file...

This is where having an input file or class comes in handy, you want a central area for understanding input. For example lets say your API has getMousePos(x,y) and get touchPos (x,y), bool isMouseDown() and bool isTouched(). You want a file to control both inputs and simplify the input for the gameplay portion. A robust input manager can handle joystick, mouse,keyboard, gamepad, touchscreen all at once. Having an understanding of how inputs can add to an input data structure, and event systems will be very useful down the road. 

Also a scoring class of some form will be useful for tracking achievements if you want to deploy on cellphone, steam, console or stores. It also makes it easier for doing the GUI or HUD.

And that being considered a game manager class comes in handy to track everything through reference. If you use a singleton pattern you can find you game manager anywhere in the code.

You'll need a state machine to handle game pausing, which is required for deployment on some platforms. Simply create an enum with your game states then halt all updates of the game until the player presses unpause. A bool can also do the trick for arcade projects. 

Oh dear, so many new ideas to keep in mind for my next game ...