Game Camera & Grid Lines | Coding a 2D Game Engine in Java #54
Vložit
- čas přidán 17. 05. 2024
- Join the Discord: / discord
In this episode I go over how to code a game camera that moves with Mario, but does not move back when Mario moves back. I also go over a solution to fixing the Debug Drawing Lines that stick around for too long, or don't draw.
Code: github.com/codingminecraft/Ma...
0:00 Intro
0:40 Visual Explanation of Camera Controls
3:38 Creating the Game Camera
7:22 Finding Game Objects with a Component
8:35 Finishing Game Camera Logic
14:09 Creating a Level Scene Initializer
17:01 Fixing Scene Transitions
18:24 Fixing Camera Clear Color
20:57 Fixing Debug Drawing Lines
---------------------------------------------------------------------
Website: ambrosiogabe.github.io/
Github: github.com/ambrosiogabe
Here are some books I recommend if you want to learn about game engine development more thoroughly. I do not profit off any of these sales, these are just some books that have helped me out :)
My Recommended Game Engine Books:
Game Engine Architecture: www.gameenginebook.com/
Game Physics Cookbook (Read this before the next physics book): www.amazon.com/Game-Physics-C...
Game Physics (Ian Millington): www.amazon.com/Game-Physics-E...
Game Programming Patterns (Free): gameprogrammingpatterns.com/
My Recommended Beginning Game Programming Books:
JavaScript Game Design: www.apress.com/gp/book/978143...
My Recommended Java Books:
Data Structures/Algorithms: www.amazon.com/Data-Structure...
LWJGL (Free, but I haven't read this thoroughly): lwjglgamedev.gitbooks.io/3d-g... - Zábava
amazing as usual
Hey Gabe, great video again and amazing series. Do you have any thoughts on adding a scripting language to the engine so we can create new game objects without modifying the engine code? If you're not planning it for this engine, do you have any suggested resources for how this should be done and any suggested languages to embed in java?
Thanks Gabe
Hey Reed thanks for the comment! The reason I chose Java for the game engine is because Java is the scripting language I would prefer to use :). So I don't plan on adding one, but if you want to look into a language you could embed it looks like there is a version of lua that's been either exposed to Java or ported to Java here github.com/nirhal/JLua . I would suggest using a lower level language for the engine like C or C++ if you want to embed scripting languages, because pretty much all modern programming languages provide a way to interface with C code.
is it possible to reuse this engine for any game you want to make?
If you want to make a 2D physics or platformer game then this engine should work pretty good :)
@@GamesWithGabe so would i have to make a whole new engine to make other 2d games. i.e top down games or puzzle games?
@@glycemic4653 this engine adds abstractions for rendering basic 2D shapes and sprites, 2D physics, cameras, input handling, and scripting. You can definitely modify it pretty easily to work for other types of 2D games. If you're looking for an engine to just use to make a game I would suggest looking at Unity or something similar. If you want to learn about how to build games from the ground up then this will probably be useful, but it will take a lot of time before you actually begin building games.
Looks interesting, but your gameengine has a couple flaws, that become really annoying after a size is reached.
First of all not everything should be a game object, because otherwise logic processes the entire level no matter the size.
So the flaw there is you update EVERYTHING on every game object for every frame. Having more then 10k blocks and you notice FPS issues. Even with stronger computers at some point the computational overhead is going to be massive.
How about mapping components into "IDrawComponent" and "IUpdateComponents" and have seperate lists for them and when a gameobject is added to the world it checks if it has those then it will just sort them into dedicated updatelists.
Also since it is a tile based game wouldn't be a int[] be better for background images like "blocks" etc? Because technically anything that isn't a block/coin/pipe (Background object) can be game object and the rest can be represented by a Singleton/Struct. And whenever a "tile" needs special animations/logic for interaction that can not be done in the Struct/Singleton it can spawn a game object that does that for it.
At least you can then do draw batches based on the XY coordinate.
Also i wonder how well this would work with java16, especially since your editor uses reflection for a lot of debug info. Though i have no idea what to replace it with ^^"
Hi Speiger, you raise some valid points, and I just want to make sure that you know this isn't supposed to be a professional grade engine, but just an introduction :).
I think what you're getting at in your first point is that we shouldn't update static objects. So game objects like blocks and game objects that are only rendered and game objects that the position never changes for shouldn't be updated at all. That could definitely be a performance improvement, and if I were to go about implementing this I would just add a checkbox to the editor to mark a game object as static. Then I would add this to a separate list than the regular game objects. I tend to shy away from interfaces for things like this, especially if you're trying to improve performance because they bring additional overhead in (stackoverflow.com/questions/4256928/is-it-better-performance-wise-to-use-the-concrete-type-rather-than-the-interface this question is about C#, but almost all languages have additional problems because of the way interfaces work).
For your other point, this doesn't need to be a tile based game. The engine is built around the Box2D physics engine, the grid is just for help laying out a level. None of the blocks need to be aligned with the grid, so that if you want to build a more custom game it is possible. If it was a tile based game you could definitely create some sort of int[] array that contains background images, I might make it some sort of enum like BlockType[], but you would also be limiting the extensibility of the engine. If you're just creating a game though and you know it will always be tile based this is a good approach.
You can still do draw batches based on the XY coordinates, and that would be a good addition so that you can implement culling :)
And I have no idea how it would work with Java 16 haha. In my hobby engine I try to stay away from reflection since it's slow, but I don't mind using it for the editor since the editor won't be shipped with the final game anyways.
Also, the main reason I'm not making a lot of these performance improvements is because I haven't found a good free Java profiler. Without a profiler you can't *really* tell which parts of your code are the slow parts. In my hobby C++ engine I'll look through the profiler from time to time to see where the hot paths are and try to optimize there, and if you have access to a profiler for Java I would suggest starting there :)
@@GamesWithGabe I totally missed your answer:
To summerize:
- Interfaces: Eh that is mostly a C# Problem and I am not sure if that is even still a problem, Java already has a fix for that as long the implementation is clearly defined and only 1 implementation in terms of performance (speaking of method overhead). But the idea behind this is just to easily filter stuff out. You can have a Interface or just all methods but provide a way to mark functions that should be called. (There is interface free methods to do that). But yeah i get the point. My Main point was though: You kinda need a "Visible" List and a "AllList" or some way to clear out things that shouldn't be rendered or updated for the after mentioned overhead. That was the main point.
-TileBased Game: Yeah in this case i am speaking of this example. A Engine should be able to do more then that. Ofc. But your example with "Enum" I wouldn't suggest the int[] was more of a "ID" system that uses a SingletonArray BlockType[] but instead of an Enum its just a class that makes it expandable and you can see it as a base class that people can extend from. And you later translate the id from the int[] to the BlockType that way you save a lot of ram and 2Billion Ids should be more then enough. You could even go so far as making subStates per block types but that is going ahead of things. The int[] is just a representation of indecies/ids and not the entire thing.
This is what my gameengine actually uses. Same with Minecrafts engine, ECS technically too (but way more abstract) etc etc.
-Java16/Reflection: Eh i need to try out java16 because of some things i work on. But You say reflection is slow? EH Not really. Yes it is slower then a normal function call. But it is faster then Lambdas and streams etc from (example: instead of taking 1 nano second it takes 2-3 nano seconds to "start" the function call with reflection) So it is now that slow as you think. Also MethodLookup is something that you should look into that way you can "unreflect" a reflection call. (can also allow unreflected ways to lookup fields. Much much nicer for performance)
-JavaProviler: JavaMissionControl is actually a good tool for performance, memory allocation usage and a couple other things. The other tool i use is VisualVM it is really good at showing the memory that your progam uses and Displaying thread activity. I use it heavily for performance etc. Also it has allocation plugins that make it useable in that regard too.
Imgui is not really good sadly, because you are constantly getting/setting values which is not always the best idea... It has a lot of performance impact. Yes i know its the editor only but still what UI system do you use outside of the editor? Write your own? Why use imgui then?
But then again imgui has a lot of Good features i am trying to copy right now.
Anyways thanks for the answer ^^"
Edit: Also if you profile your engine. Let it run for at least 60-120 seconds so javas JIT compiler is through the optimizations it does. (Yes it takes this long and i see after 60-120 seconds a performance boost of 10x from 10ms down to 1ms of lag as example)
@@Speiger thanks for the reply! I really like well thought out comments like this and I have a lot of new tools to try out now haha. I understand what you're saying about the IDs now, it seems like you were talking about a more typical approach to ECS. And I didn't know Java has the interface optimizations, but you are right about separating updateable objects to help out the game engine. And I'll have to check out the profiler and stuff :)
@@GamesWithGabe No Problem and Good luck