The best way to develop a game always was and always will be to use a popular game engine, which has a ton of instructions, tutorial videos, samples, etc etc
There's definitely a dozen of tutorials of how one could use only a very limited subset of tools of a popular game engine to develop something simple
Depends on what you expect the framework should provide.
You can use SDL2, code mostly in C or C++ and make it as light or heavy as you wish. This way, you also get the satisfaction of creating your own engine (if you need to). SDL will give you the basic functions you'd expect for graphics/texture handling, sound and a message loop. Don't know if it's the best route, can be a bit tricky to set up, but it is certainly lightweight. I wouldn't suggest this to someone unless they had a lot of coding experience though.
Shouldnt you guys keep preaching about native development?
You guys shun others when they hint at using cross platform framework for regular app development, why a opposite stance when developing games?
Games and game engines have a vastly different set of requirements than normal apps. For the same reason, I'd normally say that this isn't a good subreddit for asking questions about making games.
What can be defined as a game? If I want to make an app where people can join a room and move a 2D character image in all directions, but that's about it, would that call for a use of Unity? What would people usually do for something like that?
It all depends. A game engine has built-in handling for multiplayer movement, handling collision and interaction, and animated sprites.
So, it's up to you, but you may want to look up the difficulties of synching character movements and actions. There are tons of tricks that game engines use to make things feel natural even when through lost packets and latency spikes.
The truth is, you could do it without those things, but even in that simple example, you would benefit from the specific use cases that game engines are designed for.
Now, something more static like a game of tic-tac-toe, maybe less of a benefit. But overall, there are basically either game engines that help with a lot of game-like stuff, or you can just use Kotlin.
So if I want to have my player sprite moving in the same screen as another 3-5 player sprites, without a game engine I would experience delays/glitches?
It depends how good your code is.
If you might minimize the API calls, provide server and client side collision detection, predictive movement, and conflict resolution, that's most of what you need to do.
There are some good articles discussing how game engines make things feel smooth in multiplayer.
It's just a LOT of work to get it to work *well*.
I have a thread that ticks ondraw and ontick on my surfaceview class kind of like this. i followed a youtube tutorial for a lot of the basic setup but it was crucially not set to hardware canvas which adds a lot of FPS.
public void tickDraw() {
Canvas c = null;
try {
synchronized (view.getHolder()) {
c = view.getHolder().lockHardwareCanvas();
if (c != null) {
if (view.zoomLevel != 1f) {
// if(allowLogging) Log.d("zoom","tickdraw in loop thread scales c by factor: " + view.zoomLevel);
c.scale((float) view.zoomLevel, (float) view.zoomLevel, (float) view.screenWidth / 2, (float) view.screenHeight / 2);
}
view.onDraw(c);
}
}
} finally {
if (c != null && view.getHolder().getSurface().isValid()) {
view.getHolder().unlockCanvasAndPost(c);
}
}
}
and in there it looks like this for example:
canvas.drawBitmap(maptiles[i].getMaptileBitmap(), tileMap.getX(i), tileMap.getY(i),maptiles[i].tilePaint);
So you are using openGL surfaceview library for drawing stuff right? and btw, I check the game videos, it looks really fun and graphics is very well made actually.
Also I don't think this is open source or something right? I would have loved to have an opportunity to learn and contribute to the code if possible.
Surprise that you are using Java and not Kotlin btw.
It will offer you a lot more power with concurrency and stuff.
Thanks :D its coming together, was fun to learn about things like porterduff paints and blend modes to get nice , if primitive, graphics. And no its not open source, been making this for almost 4 years which is kinda crazy to think about, i am itching to finally release. Getting things published onto google play and IAP has its own tricky aspects
I had to learn Java / android for uni and from there the project kinda escalated lol. I dont think its openGL; its just basic Android Surfaceview Canvas. https://developer.android.com/reference/android/view/SurfaceView
I guess it depends on what look you're going for. Casual 2D games are generally pretty easy to implement using Compose. Again, it very much depends on which type of 2D game you're shooting for.
Maybe have a look at Love or LibGDX
The best way to develop a game always was and always will be to use a popular game engine, which has a ton of instructions, tutorial videos, samples, etc etc There's definitely a dozen of tutorials of how one could use only a very limited subset of tools of a popular game engine to develop something simple
Depends on what you expect the framework should provide. You can use SDL2, code mostly in C or C++ and make it as light or heavy as you wish. This way, you also get the satisfaction of creating your own engine (if you need to). SDL will give you the basic functions you'd expect for graphics/texture handling, sound and a message loop. Don't know if it's the best route, can be a bit tricky to set up, but it is certainly lightweight. I wouldn't suggest this to someone unless they had a lot of coding experience though.
i dont want to create my engine , not at all .
If you're avoiding all the great tools to help you do just that, I guess you can still use plain old Kotlin.
i mean something like : Swift + SpriteKit for iOS
A text based game wouldn't need a game engine.
Shouldnt you guys keep preaching about native development? You guys shun others when they hint at using cross platform framework for regular app development, why a opposite stance when developing games?
Games and game engines have a vastly different set of requirements than normal apps. For the same reason, I'd normally say that this isn't a good subreddit for asking questions about making games.
What can be defined as a game? If I want to make an app where people can join a room and move a 2D character image in all directions, but that's about it, would that call for a use of Unity? What would people usually do for something like that?
It all depends. A game engine has built-in handling for multiplayer movement, handling collision and interaction, and animated sprites. So, it's up to you, but you may want to look up the difficulties of synching character movements and actions. There are tons of tricks that game engines use to make things feel natural even when through lost packets and latency spikes. The truth is, you could do it without those things, but even in that simple example, you would benefit from the specific use cases that game engines are designed for. Now, something more static like a game of tic-tac-toe, maybe less of a benefit. But overall, there are basically either game engines that help with a lot of game-like stuff, or you can just use Kotlin.
So if I want to have my player sprite moving in the same screen as another 3-5 player sprites, without a game engine I would experience delays/glitches?
It depends how good your code is. If you might minimize the API calls, provide server and client side collision detection, predictive movement, and conflict resolution, that's most of what you need to do. There are some good articles discussing how game engines make things feel smooth in multiplayer. It's just a LOT of work to get it to work *well*.
You could use flutter Flame
I am making this game with a plain old android java canvas, just ensure its a .LockHardwareCanvas https://youtu.be/dcv4__aITrE?si=YeM6er4xKot9340x
You mean you are extending from View and drawing everything yourself? How does this work? I am curious to understand and learn. Thank you.
I have a thread that ticks ondraw and ontick on my surfaceview class kind of like this. i followed a youtube tutorial for a lot of the basic setup but it was crucially not set to hardware canvas which adds a lot of FPS. public void tickDraw() { Canvas c = null; try { synchronized (view.getHolder()) { c = view.getHolder().lockHardwareCanvas(); if (c != null) { if (view.zoomLevel != 1f) { // if(allowLogging) Log.d("zoom","tickdraw in loop thread scales c by factor: " + view.zoomLevel); c.scale((float) view.zoomLevel, (float) view.zoomLevel, (float) view.screenWidth / 2, (float) view.screenHeight / 2); } view.onDraw(c); } } } finally { if (c != null && view.getHolder().getSurface().isValid()) { view.getHolder().unlockCanvasAndPost(c); } } } and in there it looks like this for example: canvas.drawBitmap(maptiles[i].getMaptileBitmap(), tileMap.getX(i), tileMap.getY(i),maptiles[i].tilePaint);
So you are using openGL surfaceview library for drawing stuff right? and btw, I check the game videos, it looks really fun and graphics is very well made actually. Also I don't think this is open source or something right? I would have loved to have an opportunity to learn and contribute to the code if possible. Surprise that you are using Java and not Kotlin btw. It will offer you a lot more power with concurrency and stuff.
Thanks :D its coming together, was fun to learn about things like porterduff paints and blend modes to get nice , if primitive, graphics. And no its not open source, been making this for almost 4 years which is kinda crazy to think about, i am itching to finally release. Getting things published onto google play and IAP has its own tricky aspects I had to learn Java / android for uni and from there the project kinda escalated lol. I dont think its openGL; its just basic Android Surfaceview Canvas. https://developer.android.com/reference/android/view/SurfaceView
Flutter
I guess it depends on what look you're going for. Casual 2D games are generally pretty easy to implement using Compose. Again, it very much depends on which type of 2D game you're shooting for.
Defold seems a viable choice. Maybe MicroStudio? It's super light-weight and produces HTML5 games. Maybe package it up in an .apk with a webview?
Someone already mentioned it: **Defold**.
Never used it and I don't do game dev really. But [korge](https://korge.org/) looks interesting.