a couple of very basic questions: 1. some samples ...

# korge

[Rishav Sharan]

a couple of very basic questions:
1. some samples add views to the stage explicitly using the addchild functions while others do not. in my own code, i just create the view objects directly in the sceneInit function and that seems to work. is that the recommended way to add objects in the game?

class PlayScene(val myDependency: MyDependency) : Scene() {
    suspend override fun Container.sceneInit() {
        text("Play Scene: ${myDependency.value}") {
            filtering = false
            position(10, 10)
        }

2. In my sceneInit, i have added multiple game objects and want to be able to refer to one object from within the addupdater code of the other object

class PlayScene(val myDependency: MyDependency) : Scene() {
    suspend override fun Container.sceneInit() {
        var ball = circle (....
        var paddle = SolidRect(....

For example, I want to add a check in the add updater for ball object that gets the position and dimensions of the paddle object every tick, so I can do simple bound checking. However, I am not able to call one objects from within another. WHat would be the way to go about it?

[Nico]

to 1: the lowercase functions like circle , text , ... are actually extension functions of Container (which is a View. And the Stage you are working on is a Container ) so you call text as a member of the Stage. This will create an object (using the uppercase class Text then chains an .addTo call to add it to the parent Container (The stage in most cases) and even applies a callback.
So you can freely choose between the uppercaste + addChild and lowercase as long as each method is suited for you case

[Nico]

to 2; you should be able to call the ball object inside the paddle 's updater. Can you show more code to reproduce it`?

[Rishav Sharan]

nevermind #2. was a silly mistake from my side.

Thanks for explaining though

[Deactivated User]

A small addition note: The lower-case extension function variants, are actually DSL builder functions. The point of them is to be able to build tree structures easily. For example:

container {
solidRect(100, 100).xy(0, 0)
solidRect(100, 100).xy(100, 0)
}

You would need much more code to do that without the DSL:

val container = Container()
this.addChild(container)
val rect1 = SolidRect(..,)
val rect2 = SolidRect(...)
container.addChild(rect1)
container.addChild(rect2)

And you can see that if you have further nested views, the resulting code would be even more complicated and hard to follow. Also you need to create local variables with its names to each view, while with the DSL is not required

[Rishav Sharan]

One suggestion here; I think it will be much better to go with the non-DSL approach as the "recommended" one and have the samples/tutorials reflect that we well. Extra samples showcasing the DSL can be added separately so that users understand the difference between the two approaches.

having multiple different ways of doing this was super confusing to me and as a beginner i'd rather write a bit more of code and have it make sense.

[Deactivated User]

I think makes sense. Thanks for the feedback!

[Rishav Sharan]

I understand how helpful the DSL is with code composition, the problem for me was that:
1. when I saw the Stage2D like display tree structure, I thought I was on familiar grounds. But the samples were very different from what I expected, and that was fairly confusing.
2. people who are coming from other languages/frameworks will be familiar with the Stage2D display tree approach or with the load/update/draw callbacks approach. So at least the starting tutorials should keep that in mind to help with easier transition.
3. My assumption is that as Kotlin doesnt have lots of gamedev options, most of the Korge user would either be LibGDX users or come from different languages/frameworks altogether. DSL will make uptake harder for them. In my case, I am learning Kotlin along with Korge and the DSL made me confused if its something from the language or specific only to the game engine.
4. DSLs are fantastic in their own right but the documentation should make it clear that it is one of the two ways to write Korge.
Hope, this helps.

[RezMike]

@Rishav Sharan the ability to write DSL is one of the greatest features of Kotlin. DSL-way is a much shorter, fast-to-write and easy-to-read approach, so I personally would recommend to use it.

About new developers - yes, we should definitely write about it in docs, tutorials and samples, so Kotlin-beginners could get used to it much faster. I will write about it in the next chapters of 2048 tutorial. There will be views DSL and animation DSL, and I will try to explain the DSL-approach on their example.

Thanks for your feedback! It really helps to undestand what we need to focus on.

[Deactivated User]

Yeah I think that we should notice about the DSL indeed but as @Rishav Sharan said separately, in more advanced sections. So great, I will review the documentation and existing samples and will see what we can do to improve that entry barrier. Again thank you for your time and your feedback!

[Rishav Sharan]

in the DSL approach, how would one object refer to another considering that there are no variable names?
The way I went about is to add a variable name for each object. Is there another way where I don't need to add a variable name?

[Deactivated User]

you can still assign variables:

val mycontainer = container {
...
}

[Deactivated User]

If you need to use a variable outside a block:

lateinit var rect1: SolidRect

container {
rect1 = solidRect()
}

[RezMike]

yep, I definitely should explain DSL in the tutorial

[Rishav Sharan]

I have discovered that lateinit is a great friend to have ^_^

[Deactivated User]

Try not to abuse too much. In kotlin you should try to use val as much as possible, then var, and as a last resource lateinit. But yeah :) allows to handle stuff without explicit nullability

[Rishav Sharan]

Thanks for the heads up! I think I did go a bit overboard 😅

[Nico]

„Lateinit cars not being initialized“ are the new nullpointer exceptions :)