81–90 of 111 posts
I see a few people have adopted it - what do you guys see as the future of the language? Do you think java8+Lombok is moving in a direction that makes kotlin useless ?
Earlier quoted context omitted.
Yep gonna have to bookmark that comment for some bedtime reading tonight :D
Thanks, if you do nothing else, please (links to follow): 1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step. I have to say if there's one company who puts out stuff like videos and articles/books you should read, it is Naughty Dog. They know what they are doing optimization-wise, I just happen to find most of their games boring and lifeless from a design point of view…
Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable sources that the game dev industry extremely overworks and underpays people, and that it has a high turnover rate.
As a husband and father of 5 kids, I can't imagine making games in a job like that. Part of the reason my game is still unfinished after 15 years is because web dev is a much more stable income which lets me give my evenings and weekends to my family, and in that time it's either spend time with them or spend time writing a game. So I have like 10 lines of code to show for the choice I've made :D
Regarding entity systems, I read a blog post somewhere which discussed a really good idea that I liked a lot for how to implement them. It recommended eschewing the typical OOP concepts and just writing a struct that had slots for each "trait" that an entity could have, like Movable (x,y & controls), Damageable (HP etc), Container (chests, boxes, secret bookshelves, etc) and in the update function, iterate each entity in the active game state and if they have a thing present, run the relevant function on it. Plus it allows things to have multiple aspects, like an "evil gnome" is both Damageable and Moveable but an "evil tree" is only Damageable, This sounds like a really doable approach.
Okay anyway, will bookmark those links and look into them more when I have time. Thanks for the recommendations.
Earlier quoted context omitted.
Also, using it with RoboGuice is a bit annoying. At the moment I use vals, but it still requires me to mark injected dependencies as nullable (and coerce them with !! on use), which feels like I'm fighting the type system. It would be really nice if there was some sort of "special" null that was of the non-nullable type, but could only be used when initializing variables.
Wouldn't a `lateinit var` solve the problem in this case? (Although the downside is that now it's a variable) Otherwise I'm sure you can come up with a good solution using delegated properties or something like that.
I'm curious to hear from anyone with a Groovy background that has worked with Kotlin as well.
Earlier quoted context omitted.
Thanks, if you do nothing else, please (links to follow): 1. Read/watch the naughty dog presentation on Last of Us port where they talk about their time step. I have to say if there's one company who puts out stuff like videos and articles/books you should read, it is Naughty Dog. They know what they are doing optimization-wise, I just happen to find most of their games boring and lifeless from a design point of view…
Thanks for all these links. Will definitely check them out. Per your game dev career, sorry to hear that it's so stressful. I've heard from several reliable sources that the game dev industry extremely overworks and underpays people, and that it has a high turnover rate. As a husband and father of 5 kids, I can't imagine making games in a job like that. Part of the reason my game is still unfinished after 15 years is…
An entity is an int, long, or something else depending on your needs. It should be light-weight and not cause garbage to be allocated, thus why a long is good. A UUID/GUID is bad because you cannot use the entity id to cheat into pool rosters or other uses, not to mention it is hungrier for memory and slower to generate. Entity IDs should be allocated, often atomically and in one place and from a single thread.
A component is the data that you mention and should be a class or map/dict depending on the language. It is just a collection of fields, usually flat. Allocation should be done from a pool. It should be attached to an entity and detached as necessary. This is like a foreign key relationship per component to the entity ID if you want to think of it in DB terms.
A system operates on collections of entities, usually per frame/tick. Generally it is looking for one or more types of components per entity and isolating the logic there.
You can go outside the entity system for performance reasons like rendering if you must. Purity is good, but a lot of people go crazy and wreck performance. Be smart. The other hard thing is communicating between entities and between components. There shouldn't be any hierarchies or hard-coded things like that. Usually what is best is a queue or mailbox approach that the system can read from and deal accordingly, and then perhaps something more sophisticated beyond that as required per type of game.
My advice for getting games done in general if that's what you want to do is to just build a game and not an engine. From that regard, do dirty things like using pre-built engines such as Unreal or Unity. Better yet, just make a simple game. You will learn less, but be far more productive as a single person. If however you just want to muck around and learn things, then go wild. One thing we used to do to test architectures and game concepts that might be of interest to save time and explore me is we would build big chunks of a game with wire frames, stick figure-like things, whatever. If it's fun playing as a cube, it will be fun playing with a fancy sprite or 3d model.
Saw this pop up in my IDE this morning, excited to upgrade. The auto-for-loop-refactoring is interesting. I've found I never use for-loops in Kotlin - between the abundance of iterator methods and concise trailing-closure syntax, it always ends up being more concisely expressed as collection.forEach { ...body... }. Seems like the language may be going that way too; I wonder if we'll eventually see the for-loop start…
But does .forEach compile to an efficient for-loop in Kotlin?
Earlier quoted context omitted.
On the topic of using the JVM to make games, do you find yourself using the trick of not allocating any new objects (wither from Java or Kotlin) within the game loop? I've heard of that trick, and am considering using it because GC pauses are the main reason I'm considering avoiding the JVM for games.
It's not just JVM - even if you are a Unity 3d user you need to work around GC too. There are programming guidelines to ensure less frequent GC pauses. IMO the trade off of having a GC worth is for small developers.
Earlier quoted context omitted.
Have worked on many games and game engines for several decades. Here's some quick advice that applies mostly regardless of the JVM. 1. Allocations of any kind are often the most expensive operation per frame, or at least some of the ones that are fixable (you can't just not have physics in some games). As such, avoid allocations per frame. 2. Notice transition screens, loading screens before levels, brief artistic an…
Wow. Thanks for all this. I've casually read a lot of people's advice on game dev, and while some of it is reflected in what you said, your comment kind of ties it all together. And it confirms something I've been thinking for a few months (possibly years)... Everything needed to write a simple game is right there in C, using structs, pointers, and functions! Anything beyond that is over-engineering. And the convenie…
Most of what I've been describing came about because people were in OOP hell, and decided to move towards composition vs. inheritance. As multi-core machines, GPUs, and more sophisticated games arose as well, there was more of a need to start thinking more in terms of what the CPU wants and pipelining things for the CPU, GPU, and such (think PS3 for instance). To some degree, this thinking was always there and circling back to 80s game programming, but a lot of people got off-track. For example, memory allocation was always a thing to the point where no sane person every used anything in C++ from std because of allocations and bad memory layouts. Structure packing has always been a thing of course too. Another was thinking about v-tables and how they just get in the way, especially when working on more limited platforms like the NES, 286, etc. in those days.
Games are mostly about enumerating a lot of stuff, very fast, per some measure of time, and then repeating. If this sounds a bit like a map or a reduce in functional terms, it should because it is. You have loops inside loops, and you try to operate on similar blocks of data, rather than jumping around all over the code or iterating mixed collections (or hybrids using co/contravariance). It turns out computers, especially x86, really like it when you enumerate things in a line. There's a fun presentation somewhere where Stroustrup himself shows how an array can be faster in many situations than a linked list when the linked list fits the exact description of the correct data structure.
Anyway, you can rig a lot of this into Java as you say, but fighting the GC is still considerably hard. Clojure itself is even worse because it generates garbage like nuts and you also end up doing things like transient! or using volatile! to work around other speed issues. I'm not sure about Kotlin would be, but as a JVM language dealing with JVMisms, I suspect largely the same as Java. Other languages that are more predictable or not GC'd fair much better for games, they are just not used as much because of the people in the industry, technical debt, tool chains, know-how, risk, etc.
Where I'd disagree with what you said is that those constructs are all you need. For certain parts of your game you still need quite sophisticated stuff. Threading primitives and complex pieces of code help that are a pain to write with just what you described. But these things are generally higher level. For example, scripting engines are a good thing to have and often not written in the same language (ex: lua). Editors are another example. They aren't part of your game directly necessarily, but these days they increasingly are on some level, at least some form of them. Either way, you benefit from building toolchains in a variety of languages to help a game. It's not just a single code-base and ultimately you only have so much time, so you take shortcuts like throwing in Lua to make life easier.
Regarding SDL2, it's probably great for what you are doing. It's more low-level, but if you want to build things from the ground up, it's a fine and well-tested choice. There are other alternatives, but mostly in the form of full game engines. Certainly you could do this with something like Unity and it'd be good enough. If you're going 2D, the one piece of advice I'd give you is I'd say probably these days you can get just as much done by making things 3D and fixing the camera most of the time, or using a hybrid. 2D is more difficult than people think and often sucks in certain engines (ex: Unity :) ). Anyway, it's just a matter of some head banging and time. If you go SDL, you'll learn a lot, just remember, build games, not game engines.