Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Dashing Ball ("Hello world" project) — Gideros Forum
  • Home
    • ›

    Dashing Ball ("Hello world" project)

    E1e5enE1e5en Member
    edited October 2021 in Game & application design
    Dashing Ball is an arcade game developed as part of the study of the Gideros game engine (a kind of "Hello word" project). This mechanic is a clone of an existing mobile game with modifications.

    How to play

    The player (blue ball) moves towards the "coin" (orange ball). Tapping (pressing LMB) reverses the direction of the player. Your task is to collect as many points as possible and face obstacles (white figures).
    Music and sounds are absent. Laziness, maybe I will add later.

    About development

    As part of testing tools, I use them in game development contests (Jams) or develop simple projects. I love this mechanic, so I use it.
    During the development, 2 incorrect decisions were made, which led to the complication of development and not the most optimal solutions. On the one hand, it was more difficult, on the other hand, it made it possible to get to know the game engine even better. Wrong decisions:
    1) Using a physics engine to check for collisions.
    This led in the future to another wrong decision and made it possible to study how to work with it. But it was possible to do without a physics engine, and just write a few functions to check for collisions.
    2) Use sprites as objects of motion, and then synchronize them with physical bodies, and not vice versa.
    It was possible to adjust the direction of linear acceleration or forces acting on objects, and then apply their position to the sprites, but then it seemed to me that it was easier to do this.
    Of course, most likely, more mistakes were made, the structure of the project I do not like at the moment, and I have not completely decided on the style of the code.
    The source code of the project is attached, but I am not responsible for your health after viewing it. Be careful not to take it lightly. :D

    Suggestions/discussions:

    - The physical world is tied in a global coordinate system, which cannot be changed in any way (move, rotate). And I would like to have such an opportunity, or bind it to a specific node (child), so that the local coordinate system is used. This will allow you to easily create interesting game mechanics (for example, just rotate / flip a level in a platform game), without changing anything else (gravity, controls).
    Perhaps there is a way to rotate the "camera", but I did not find it.
    - Set limits for canvas sizes in HTML5 assembly. Otherwise, it is always stretched and you can see how objects are created outside the left and right borders of the screen.

    Link to project page: https://e1e5en.itch.io/dashing-ball?password=gideros

    As a result, about 20 hours were spent on the project. I liked the game engine and you can start developing a "large" project with its help. :)

    Likes: MoKaLux

    Beginner game developer:https://e1e5en.itch.io, Google Play
    Tagged:
    +1 -1 (+1 / -0 )Share on Facebook

    Comments

    • hgy29hgy29 Maintainer
      Accepted Answer
      E1e5en said:


      - Set limits for canvas sizes in HTML5 assembly. Otherwise, it is always stretched and you can see how objects are created outside the left and right borders of the screen.

      Sprite:setClip() should help for this.

      Likes: E1e5en, MoKaLux

      +1 -1 (+2 / -0 )Share on Facebook
    • E1e5enE1e5en Member
      hgy29 said:


      Sprite:setClip() should help for this.

      Thanks. I'll try how the opportunity arises
      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1Share on Facebook
    • E1e5enE1e5en Member
      hgy29 said:


      Sprite:setClip() should help for this.

      Thanks again. Works. :)

      Likes: MoKaLux

      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1 (+1 / -0 )Share on Facebook
    • MoKaLuxMoKaLux Member
      edited September 2021
      hi E1e5en, I played it and it is pretty fun :) high score 16 :/
      E1e5en said:

      Dashing Ball

      Suggestions/discussions:

      Perhaps there is a way to rotate the "camera", but I did not find it.
      As I have been told here on the forum a camera is simply a Sprite. You attach every objects of your game to the Sprite and then you can rotate it...

      Example:
      local camera = Sprite.new()
local obj1 = Pixel.new(0xffffff, 1, 32, 32)
local obj2 = Pixel.new(0xff0000, 1, 32, 32)
camera:addChild(obj1)
camera:addChild(obj2)
camera:rotate(30)
stage:addChild(camera)
      see also: https://wiki.gideros.rocks/index.php/Introduction_to_Graphics#Introduction_to_graphics

      There is also this camera class from mr rrraptor https://github.com/MultiPain/Gideros_GCam with cam shake, rotate, ...
      E1e5en said:

      Dashing Ball
      As a result, about 20 hours were spent on the project. I liked the game engine and you can start developing a "large" project with its help. :)

      Congratulations!


      I have downloaded the source code and will try to add rrraptor's camera (https://wiki.gideros.rocks/index.php/Game_Camera), give me some time please. ;)
      EDIT: I couldn't add the gcam camera to your game, I am not used with your code structure :s

      Likes: E1e5en

      my growING GIDEROS github repositories: https://github.com/mokalux?tab=repositories
      +1 -1 (+1 / -0 )Share on Facebook
    • E1e5enE1e5en Member
      edited September 2021
      Thanks for the class information camera. The hierarchical structure of nodes (child) allows you to change the parameters of child nodes, if we change the characteristics of the parent, I understand that. Moreover, this is what happens in my game (level turn). But the physics engine uses "its" (global) coordinate system. Therefore, no matter how you rotate the child nodes, for physics, the X-axis will still be directed downward, and the Y-axis to the right. In other engines, the Camera class also uses its "own" coordinate system, if you rotate it there, the physical world will also "rotate".
      P.S. I haven't tried rotating the main stage node. Perhaps the physics engine coordinate system is tied to it.

      Update: Thanks for trying. Not worth wasting time. I understand how to add this class. But it won't help. :)
      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1Share on Facebook
    • E1e5enE1e5en Member
      edited September 2021
      My project has the following hierarchy:
      - background (class BG) is added to the stage.
      - next, the Game node (added to the stage node).
      - in the Game class, the SceneManager class is used, which contains the nodes: the main menu (MainMenu), the playing field (Field).
      - the Field class contains the elements of the playing field (this node is just rotating) and also contains the SceneManager class for the game interface: the start window, the game menu with the display of points and the pause button, the GameOver window. Thus, depending on the state of the game, I switch the interface.
      The camera class can replace the Game class or be “above” it, or “above” the Field class.

      P.S. SceneManager - it would be more correct to call this class NodeManager, because it controls the display and switching of nodes (child) that are at the same level. It is convenient to create different layers and combinations with this class. :)
      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1Share on Facebook
    • E1e5enE1e5en Member
      E1e5en said:


      P.S. I haven't tried rotating the main stage node. Perhaps the physics engine coordinate system is tied to it.

      It turns out that if you rotate the main node "stage", then the physical world will also "rotate", i.e. the coordinate system of the stage node and the physics engine is the same. This means that we only need to take into account the rotation of the child nodes so that everything is correct (meaning the game interface, provided that we need to rotate the game itself). Cool :)




      Likes: MoKaLux

      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1 (+1 / -0 )Share on Facebook
    • hgy29hgy29 Maintainer
      Actually the physics engine(s) aren't tied to any other Gideros coordinates space, they are independant. But in your game loop you update your Sprite corrdinates based on physics bodies coordinates, and you can apply whatever transform you see fit according to your scene layout.

      You can decide that your physics scene coordinates go from 0,0 to 1,1, and adjust Sprite coordinates directly, or adjust the parent container, or whatever
      +1 -1Share on Facebook
    • E1e5enE1e5en Member
      edited September 2021
      hgy29 said:


      You can decide that your physics scene coordinates go from 0,0 to 1,1, and adjust Sprite coordinates directly, or adjust the parent container, or whatever

      Agree. But it is necessary to write the appropriate code (and waste resources, and create more errors). In the post above, I added a rotation line to the example:
      stage:setRotation (30)
      As a result, the physical world rotated as I wanted, and the sprites are updated from the coordinates and rotation angle relative to the physical object. Those I do not need the transformations you are talking about.
      hgy29 said:


      Actually the physics engine(s) aren't tied to any other Gideros coordinates space, they are independant.

      It turns out that the physics engine is still anchored in the coordinate system of the stage node. And this is good :)

      Beginner game developer:https://e1e5en.itch.io, Google Play
      +1 -1Share on Facebook
    Sign In or Register to comment.