https://kotlinlang.org logo
#korge
Title
# korge
r

Rishav Sharan

06/03/2020, 4:37 AM
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?
Copy code
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
Copy code
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?
n

Nico

06/03/2020, 4:46 AM
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
to 2; you should be able to call the
ball
object inside the
paddle
's updater. Can you show more code to reproduce it`?
r

Rishav Sharan

06/03/2020, 6:45 AM
nevermind #2. was a silly mistake from my side. Thanks for explaining though
👍 1
d

Deactivated User

06/03/2020, 8:07 AM
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
r

Rishav Sharan

06/03/2020, 8:11 AM
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.
d

Deactivated User

06/03/2020, 8:12 AM
I think makes sense. Thanks for the feedback!
r

Rishav Sharan

06/03/2020, 8:18 AM
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.
👌 1
🙏 1
r

RezMike

06/03/2020, 8:23 AM
@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.
👍 1
d

Deactivated User

06/03/2020, 8:27 AM
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!
❤️ 1
r

Rishav Sharan

06/03/2020, 8:30 AM
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?
d

Deactivated User

06/03/2020, 8:31 AM
you can still assign variables: val mycontainer = container { ... }
If you need to use a variable outside a block: lateinit var rect1: SolidRect container { rect1 = solidRect() }
👍 1
r

RezMike

06/03/2020, 8:33 AM
yep, I definitely should explain DSL in the tutorial
❤️ 1
r

Rishav Sharan

06/03/2020, 7:19 PM
I have discovered that
lateinit
is a great friend to have ^_^
d

Deactivated User

06/03/2020, 7:20 PM
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
r

Rishav Sharan

06/03/2020, 7:25 PM
Thanks for the heads up! I think I did go a bit overboard 😅
n

Nico

06/03/2020, 7:38 PM
„Lateinit cars not being initialized“ are the new nullpointer exceptions :)
2 Views