Programming thread

[Shoggoth]

I don't speak wingding you fucking niggernerds, ←↭↰↻↠↞↘↜↡↹ right back at you

I'm actually learning a lot about category theory as I'm (sort of?) following along with your discussion. I've always been meaning to take a look at Haskell and monads and everything, but just never got around to it for whatever reason.

I'm not a category either, am learning though. I think in a year or two I'll get the hang of monads (and just when I think I had it they go on and throw Arrows at me ffs)

I'm realizing more and more that I basically want HolyC with managed memory and an interface system
My stab at it has been going relatively well; right now I'm working on a bytecode format to store programs. One problem I haven't quite settled on a solution for is how to represent s-expressions in a bytecode format. My current thinking is to create nested expressions based on data dependencies.

Due to a desire to have interrogable and transformable expressions the bytecode isn't intended to be executed directly by the interpreter, rather transformed into objects that implement a function interface.

Anyone here have a better idea for representing s-expressions in bytecode? This'll do, but I feel it's not optimal.

If you're feeling lazy you can just import clojure as a library and use its collections to represent s-expressions like it does internally for itself, then maybe hack clojure.tools.emitter to spit bytecode out from that. "transformed into objects that implement a function interface" is how clojure implemented lambdas, interestingly.
I'm also intrigued by the idea of generally embedding an interpreter on top of a program in a dynamic environment, which the jvm is. Please update on whatever you do with it, very interesting.

On a semi related note, have you run any sort of profiling on your game? Got pretty flame graphs?

 

[Strange Looking Dog]

If you're feeling lazy you can just import clojure as a library and use its collections to represent s-expressions like it does internally for itself, then maybe hack clojure.tools.emitter to spit bytecode out from that. "transformed into objects that implement a function interface" is how clojure implemented lambdas, interestingly.
I'm also intrigued by the idea of generally embedding an interpreter on top of a program in a dynamic environment, which the jvm is. Please update on whatever you do with it, very interesting.

Naw, 1. that'd be packaged with all the flaws of the JVM, 2. where's the fun in that? Thing is, more than a language I'm trying to create a framework (.Net-esque), I suppose I could wrangle some of my ideas onto the JVM but a lot of them just don't fit. The big one is the ability to actually control how objects are allocated, if I choose JVM I'm stuck with where they want to put things (the GC heap 200% of the time).
I'll definitely post some updates along the way. I'm hoping to have basic functionality rounded out by the end of the month, optimistic for sure but I've got to get back to work on other more urgent things after that so it's a deadline lol

On a semi related note, have you run any sort of profiling on your game? Got pretty flame graphs?

I'll be honest, I've been focusing on performance to the detriment of finishing the game. Here's an example run, keep in mind that the game runs about 10-20 times better when not profiling. Library names have been blanked out as they're somewhat identifying.

At the moment the game's running on two threads and though I could scale that up as much as I want, two is probably realistic for most android hardware. The basic gist is that tasks are posted to the "TaskSystem" which then executes the work across any threads subscribed as workers. Synchronization is accomplished through "SyncFilters" which define which tasks may be run together.

Highlighted in blue is collision testing, highlighted in green is lazy octree rebuild, and highlighted in turquoise is physics calculation and physics event dispatch, for this test there were ~120 physics objects on screen, but I've seen the game do 500 before at ~30fps, that's without profiling active of course.
The major cost here is plane-sphere collision testing because planes are tested regardless of likelihood —infinite planes don't fit in the octree lol. Once I get around to implementing continuous collisions I'll be able to use finite planes, and that should lower the cost significantly. Another thing that needs to be done is adding some kind of sleeping awareness to the CollisionSystem. Currently the PhysicsSystem does partially suspend physics for low energy objects, but the CollisionSystem still does it's calculations. It'll be tricky to get right though.

Highlighted in yellow is rendering preparation. Rendering is actually done on a different thread (android opengl api requires this), but a simplified copy of the scene is created on one of the worker threads and passed to the render thread to prevent race conditions. There's lots of resource reuse here, so under normal conditions there're minimal allocations from this.

Highlighted in red is logic dispatch. Entities are assigned Behaviors, which are activated by events sent to the BehaviorSystem, the BehaviorSystem then posts these coupled with the event as a closure to the task system which executes them asynchronously. Behaviors are vectorized in the sense that a single call to the behavior applies it to all the entities it effects, thus reducing some of the overhead.

Finally, those last two waits are the synchronization wait and the vsync wait respectively. The sync wait is the time that one thread has to yield to another thread due to SyncFilters, and the vysnc is of course a good sign and basically just represents free processor time. At the moment a fair number of behaviors run synchronously, so once I loosen their requirements they'll take a good chunk out of the sync wait.

 

[HikikomoriFury]

I'm interested in creating a mobile card game based on mythology, specifically obscure mythological creatures that you can learn about through the cards you unlock in game, it's style akin to MTG Arena. If that goes anywhere I'd like to expand to another game which is more story driven.
I only just downloaded Unity to see if I can make a simpler game to gain an understanding of the program.

Anyone have any tips on how to go about this?

 

[FuckedUp]

I'm interested in creating a mobile card game based on mythology, specifically obscure mythological creatures that you can learn about through the cards you unlock in game, it's style akin to MTG Arena. If that goes anywhere I'd like to expand to another game which is more story driven.
I only just downloaded Unity to see if I can make a simpler game to gain an understanding of the program.

Anyone have any tips on how to go about this?

Well first off, I'd recommend not using a proprietary resource hog for a simple card game. I know Unity's huge, but really look into open-source stuff like SDL or Godot.

 

[Least Concern]

Anyone have any tips on how to go about this?

What do you know already? Will this be your first software development project? Or maybe just your first game?

If so, I would suggest making a blackjack game first. Don't worry about using Unity or anything else graphical; just make something that works on the command line first. This is because blackjack has some well-defined rules and it's simple to implement a computer-powered opponent which follows rules such as hitting on 16 and standing on 17. And the parts about shuffling the deck and maintaining a hand for each player are directly applicable to a TCG. From there you could try to implement five card draw poker, which similarly has well-defined rules but for which the behavior of the computer player(s) will have to use some level of decision-making to decide which cards to hold and which to swap. That'll be your introduction to AI.

From there, you can adapt the rules to your own card game, with its own cards. I would suggest keeping it text-based for as long as you can for ease of iteration. As TCGs are typically far more complex rules-wise than standard deck card games, the parts of the code that involve detecting win state or invalid moves and the computer player AI are going to be the most complex parts.

If this isn't your first project, let us know what you know already and we can probably guide you better from there.

Also, I've been wanting to post a boomer meme in this thread for a while, but gracefully waited until I had a serious post to go along with it. Now that I do, here you all go.

 

[HikikomoriFury]

Will this be your first software development project? Or maybe just your first game?

Yes and yes

let us know what you know already and we can probably guide you better from there.

I'm a complete noob when it comes to programming tbh, but I do want to learn the language and what steps to take from there. I don't want to waste anyone's time asking dumb questions, I appreciate all your advice

 

[Least Concern]

Yes and yes

I'm a complete noob when it comes to programming tbh, but I do want to learn the language and what steps to take from there. I don't want to waste anyone's time asking dumb questions, I appreciate all your advice

Okay, generally speaking, the language of choice of game developers is C++. C++ and most other "C-family" languages aren't generally known for being beginner-friendly, but on the other hand, if you can master C++, you can master pretty much anything, so I'd suggest giving it a try. But if you would rather learn something known for being a bit friendlier but for which some game creation libraries are still available, you can look into Python instead. Just be aware that your end products won't be as performant as they would be if you used C++, and you won't find many Python game dev gigs in the industry if you eventually want to turn this into a career.

Do you learn well with books? With video courses? College courses? The good thing is that both C++ and Python are common enough that you'll find beginner-level courses in pretty much any medium you could want, so take your pick and start learning.

Have fun!

 

[Christ Cried]

I may or may not have to program an HTTP compliant web server in C for my systems class. I will stream the suicide.

 

[MadDamon]

Okay, generally speaking, the language of choice of game developers is C++. C++ and most other "C-family" languages aren't generally known for being beginner-friendly, but on the other hand, if you can master C++, you can master pretty much anything, so I'd suggest giving it a try. But if you would rather learn something known for being a bit friendlier but for which some game creation libraries are still available, you can look into Python instead. Just be aware that your end products won't be as performant as they would be if you used C++, and you won't find many Python game dev gigs in the industry if you eventually want to turn this into a career.

Do you learn well with books? With video courses? College courses? The good thing is that both C++ and Python are common enough that you'll find beginner-level courses in pretty much any medium you could want, so take your pick and start learning.

Have fun!

Wouldn't C be too hard for a beginner, especially when they are newbies to computer language who possible expect to have some sort.of breakthroughs in 1 or 2 years?
Personally I would suggest those game engines like Unity or unreal if you really want to develop the game without losing enthusiasm in the meantime as a beginner. It might take years for you to get a gripe on C but only a few months to master those engines.

 

[FuckedUp]

Wouldn't C be too hard for a beginner, especially when they are newbies to computer language who possible expect to have some sort.of breakthroughs in 1 or 2 years?
Personally I would suggest those game engines like Unity or unreal if you really want to develop the game without losing enthusiasm in the meantime as a beginner. It might take years for you to get a gripe on C but only a few months to master those engines.

Objectively speaking, C is one of the simplest languages. It just takes more effort to make complex things with it. Though I learned Python first so I may have no idea what I'm talking about

 

[Least Concern]

Wouldn't C be too hard for a beginner, especially when they are newbies to computer language who possible expect to have some sort.of breakthroughs in 1 or 2 years?
Personally I would suggest those game engines like Unity or unreal if you really want to develop the game without losing enthusiasm in the meantime as a beginner. It might take years for you to get a gripe on C but only a few months to master those engines.

C is "hard" in the sense that it forces you to learn a bit more about how computers work before you can do anything non-trivial. But if you're putting any serious effort into it, I would not estimate it would take you a full year or two to reach a level at which you could make a game. Maybe something closer to 4 months. At any rate, with all development, it's typically not the language itself which is the challenge but implementing (and being aware of) the necessary algorithms to achieve your goal. And anyway, what language are you going to use with Unity? It's C#, not some magically easy Unity-specific language.

I may or may not have to program an HTTP compliant web server in C for my systems class. I will stream the suicide.

If you don't have to implement anything further down the networking stack, it might be easier than you might be thinking. HTTP as a protocol (before HTTP/2) is pretty simple. Do you have to implement HTTP/2 or Keep-Alive?

 

[Strange Looking Dog]

@HikikomoriFury Honestly just use Unity. Don't try making your first game from scratch unless it's the engine you are interested in. I respect low level programming but I don't know what these people are smoking. C/C++ is an okay starting point if you seek an understanding of the interplay between software and hardware, but if you just want to make a card game it'll be a terrible introduction. Unity will give you a reasonable introduction, and afterwards if you feel the calling you'll have a starting point to pursue other languages.

Well first off, I'd recommend not using a proprietary resource hog for a simple card game. I know Unity's huge, but really look into open-source stuff like SDL or Godot.

Yes it is a resource hog, but it's a good place to start. They don't need to be worrying about fine tuning things this early on.

C is "hard" in the sense that it forces you to learn a bit more about how computers work before you can do anything non-trivial. But if you're putting any serious effort into it, I would not estimate it would take you a full year or two to reach a level at which you could make a game. Maybe something closer to 4 months. At any rate, with all development, it's typically not the language itself which is the challenge but implementing (and being aware of) the necessary algorithms to achieve your goal. And anyway, what language are you going to use with Unity? It's C#, not some magically easy Unity-specific language.

C# is a reasonable choice for this, it provides a balance of performance and usability. Under normal conditions you don't have to worry about memory leaks or dangling pointers, failures are usually gentle and easy to trace, and importantly it's coupled with an engine that does most of the plumbing for you. Let's be realistic, it's much easier to use than either C or C++.

I have no idea why you crazy people are suggesting that they use C/C++ It's a fucking card game; it's not going to need much optimization and it's their first project. C/C++ for a case like this is a recipe for frustration. Yeah sure, let's learn about windowing, opengl, and input processing at the same time we are learning our programming fundamentals

 

[Christ Cried]

If you don't have to implement anything further down the networking stack, it might be easier than you might be thinking. HTTP as a protocol (before HTTP/2) is pretty simple. Do you have to implement HTTP/2 or Keep-Alive?

I have no clue, all I know is that I bumped into the prof at a barbecue and when he was describing the project he made this face.

 

[FuckedUp]

@HikikomoriFury Honestly just use Unity. Don't try making your first game from scratch unless it's the engine you are interested in. I respect low level programming but I don't know what these people are smoking. C/C++ is an okay starting point if you seek an understanding of the interplay between software and hardware, but if you just want to make a card game it'll be a terrible introduction. Unity will give you a reasonable introduction, and afterwards if you feel the calling you'll have a starting point to pursue other languages.



Yes it is a resource hog, but it's a good place to start. They don't need to be worrying about fine tuning things this early on.


C# is a reasonable choice for this, it provides a balance of performance and usability. Under normal conditions you don't have to worry about memory leaks or dangling pointers, failures are usually gentle and easy to trace, and importantly it's coupled with an engine that does most of the plumbing for you. Let's be realistic, it's much easier to use than either C or C++.

I have no idea why you crazy people are suggesting that they use C/C++ It's a fucking card game; it's not going to need much optimization and it's their first project. C/C++ for a case like this is a recipe for frustration. Yeah sure, let's learn about windowing, opengl, and input processing at the same time we are learning our programming fundamentals

Godot is pretty similar to Unity AFAIK, but open-source (meaning that not only do you not have to give them money, but you can even see and modify the source code if you're acquainted with C++).

Besides, I've actually written a simple 2D game in SDL and it was pretty easy: for instance, to make a window you just declare a window variable and initialize it with all the parameters you need with a single built-in function. It's all very straightforward.

 

[Strange Looking Dog]

Godot is pretty similar to Unity AFAIK, but open-source (meaning that not only do you not have to give them money, but you can even see and modify the source code if you're acquainted with C++).

Besides, I've actually written a simple 2D game in SDL and it was pretty easy: for instance, to make a window you just declare a window variable and initialize it with all the parameters you need with a single built-in function. It's all very straightforward.

I know Godot is similar, but the C++ aspect is still going to be a problem. Compile times will be longer, errors more incomprehensible, and there'll be more ways to seriously fuck up. The proprietary aspect of Unity also doesn't matter here. It's a first project; if it actually makes $50k —the amount at which you require a paid license— they'll be extremely lucky. Additionally Unity's ability to reload the project binary while it's running can be very helpful for iteration.

As for SDL, the WYSIWYG nature of Unity (or Godot) is going to be very helpful for a beginner. It greatly aids in iteration, and gives the whole process a tactile aspect that can help ground you. Finally, having to set up everything before you understand what it does is going to make the process seem rather ritualistic. I really don't see a benefit to starting with SDL.


I'm not arguing against the use of C++ for games or otherwise (I'm using it right now), nor against the use of Godot or SDL, rather it's that they're not ideal for a first project —supposing you intend to get it working in some reasonable span of time. Out of the two options though, Godot seems most reasonable.

 

[FuckedUp]

I know Godot is similar, but the C++ aspect is still going to be a problem. Compile times will be longer, errors more incomprehensible, and there'll be more ways to seriously fuck up.

Only the source code of Godot is C++. Within the engine itself, it uses its own scripting language.

 

[Strange Looking Dog]

Only the source code of Godot is C++. Within the engine itself, it uses its own scripting language.

I didn't know that. Ambitious of them to undertake such a thing, Not only for the complexity of design, but also maintenance and optimization. Interestingly Unity also used to have a specialized scripting language, but that's been long deprecated. Ultimately they found it practical to just offload the costs of maintenance and optimization onto Microsoft and Mono, and so made C# the sole scripting language of Unity.

Are they JITing through LLVM or something? I'm having trouble imagining how else they could expect to achieve competitive performance, while also keeping the system manageable.

 

[⠠⠠⠅⠑⠋⠋⠁⠇⠎ ⠠⠠⠊⠎ ⠠⠠⠁ ⠠⠠⠋⠁⠛]

@HikikomoriFury Honestly just use Unity. Don't try making your first game from scratch unless it's the engine you are interested in. I respect low level programming but I don't know what these people are smoking. C/C++ is an okay starting point if you seek an understanding of the interplay between software and hardware, but if you just want to make a card game it'll be a terrible introduction. Unity will give you a reasonable introduction, and afterwards if you feel the calling you'll have a starting point to pursue other languages.

@HikikomoriFury further to this, if you want to achieve something that is playable and satisfying you want to try and find an existing project in something like Unity or an existing game written in something like Python with existing graphics and gradually iterate from and understand that. The alternative is to spend a lot of time reading about and practising programming concepts and writing gradually more advanced stuff until you can kind of hack something together. You might enjoy it but it won't get a game built.

I don't know about trading card games, but there are specific frameworks for building Chrono Trigger esque RPG's and Monkey Island like point and clicks, That takes the hardest bits of programming out of it, to the point where you just have to do the really hard stuff like the artwork and storyline.

 

[Least Concern]

Only the source code of Godot is C++. Within the engine itself, it uses its own scripting language.

Ugh. Fortunately elsewhere in that guide I found that they do support C# as well, at roughly 4x the speed of GDScript. And it looks like all of the code examples in the docs feature both GDScript and C# versions, so they're making it a first-class option.

If I can ever have a free weekend again in my life, I'll have to put some time aside and have a look at this thing. Does it force you to use a built-in editor, or are you free to use an external editor for the code?

 

[Hans]

What should i do to improve my code skills. Took basic java classes, but what should i do to improve my knowledge.