Thank you for trying out my game! The intended way to build a single engine/port (e.g. SDL2 in your case) is to run:
meson setup -Dengines=sdl2 build
meson compile -C build95 karma · joined October 23, 2020
meson setup -Dengines=sdl2 build
meson compile -C buildI feel like designated initialisers can be circumvented by simply assigning the fields individually. It’s a bit more verbose, but I feel like it works almost as well, the biggest downside being that the compiler won’t warn you if you miss some.
Regarding loops and variables, I opted for just declaring all variables at the top of each function definiton (only using an initialiser for ‘static’ variables), which I find almost reminds me of how Python handles variables, except with a chunk of declarations at the start of each function.
Of course, this is all subjective, but I find this style looks neat, and I don’t think it gets in my way at all, personally.
Yes, that’s exactly the kind of thing I was going for! Though I will say: I feel like my controls, although difficult at first, are easier to get used to than either of those two, or at least they were to me. After a while playing with the game, you “get the hang of it” so to say, and it starts feeling more natural.
Also, thank you for your advice! I have some thoughts/questions about some of it:
> Things like describing what "chapter 1" is are basically asset problems.
Well, my current solution is to encode the different “assets” (chapters, characters, images) as source code, and link them with the rest of the game at compile time. The biggest benefit is that I end up with a single executable that is easy to run, and don’t need to bother loading assets at runtime. To me, it doesn’t seem to matter ultimately whether I store information about how a chapter should play out as plain data or as code, and making it code seems simpler insofar.
Though a lot of the assets the game uses (e.g. the dialogue boxes you mentioned) are generated during intialisation, and then just displayed as a set of images during gameplay. Effectively, it shifts some “during build” work to “when the game starts”. The benefits include a simpler build system and fewer required build dependencies, besides being more straight‐forward to work with.
> A simple constraint solver for the platforming physics.
I don’t think I fully understand what you mean by this. Are you saying you feel like it would be better to avoid performing collision checks in order of axis? I.e. that it would make more sense to perform the checks in conjunction somehow?
From the very beginning, I wanted to make it simplistic in approach, so the AI algorithm isn’t very complicated. I wanted to balance strength and simplicity, and I think I’m very happy with the results!
My hope is that it can be fun to play for begginers and intermidiate players! It was meant to be played by humans rather than to play against machines.
It can also be used as a library, and I put a lot of effort on thoroughly documenting its API. It isn’t a fixed API, and it follows a “rolling release” approach, but I try to avoid making breaking changes unless I have a good reason for it.
I wrote a post about it in the Computer Chess Club forums a while back, but people didn’t seem so interested about it there: https://talkchess.com/forum3/viewtopic.php?f=7&t=79379 Again, it isn’t a particularly strong or innovative approach, but I am happy with how it turned out!
I had made a simple Bash script that displayed the calendar of a given month using ‘greg’ with ‘paste’, ‘columns’, and some other common utilities, but I haven’t uploaded it anywhere yet.
I didn’t want for it to get to the front page at all, by the way! I was honestly not expecting this to get more than the three points it got yesterday, to be honest!
Originally, I had written a linker script that could generate really small ELF executables, using the information I found on this website: http://www.muppetlabs.com/~breadbox/software/tiny/teensy.htm...
That meant I had to implement functions for myself, including ‘write’ in x86 assembly.
As soon as I started storing function pointers, however, my program started to segfault, and I didn’t bother to figure out how to fix it. Do I stopped providing those builds on the website, and decided to start using other standard library functions, such as the time‐related functions.
Since I already had those functionalities there, I decided to keep them anyway. It would make sense to reuse the library functions, though, I agree!
I have (somewhat) recently decided to start working on a simple C project. It is a “replacement” for the Unix utility ‘cal’.
Of course, it is far from actually hoping to replace anything, it is more of a clone with some different functionalities than anything else.
One of my friends mentioned that in his classes for his degree in computer science, he was assigned to fix a ‘cal’ clone the teacher had written in Java.
Since I was always kinda interested by calendars and timekeeping, that sparked some interest in me. I decided to start the project because I felt like it would be fun to try to come up with something simple to display the calendar.
I chose C because it is a (relatively) straightfoward language, and it is very popular, so basically anyone can understand it.
Initially, the program was really short, but lacked a lot of functionalities. As the time went on, and I felt periodically bored enough to work on it, I decided to sacrifice some simplicity for more useful features.
I feel like now it has gotten to the point in which it is “mature enough”, and could potentially be used by people who regularly use ‘cal’.
Don’t mind the bugs too much. (But of course, feel free to bring them up!) One that I know exists and just haven’t gotten around fixing yet is the overflow handling for my function for parsing integers.
I’m looking forward to know what people might think about it! Any kind of feedback is really appreciated, be it regarding functionality, code style, or anything else!
P.S., You can try it through a Web interface through the first link on the website. Try e.g. ‘greg -yh’ for output very similar to ‘cal’.