What alternatives to git are popular-ish these days?
Before I was introduced to git, i had only tried Microsofts SVN server and it was a crap experience compared to git. Git just clicked with me, i fell instantly in love with it. It was fast and logical. And its file merging worked great. The only drawback was the program command args, it was hard to understand. So I relied a lot on GUI apps. And still do because I suck at memorizing more complex commands and args and at navigating the history graph with only colored ascii text.
Git is by far the most popular but I know large studios sometimes go with Perforce because it’s apparently better for dealing with extremely large projects. I say “apparently” because as a lowly hobbyist I’ve managed just fine with Git thus far.
Neat! Good luck and lots of fun to everyone participating. Unfortunately, I will be too busy with trying to finish my contribution to Fuck Capitalism Jam and future jams to learn how to code gba roms - even if they allow (but not recommend) GBStudio.
It looks really fun, I have to set myself a reminder to check the results in August.
Thank you! It was lots of fun, a great learning experience, and seeing all the games was great! Definitely not the last jam I will participate in, can only recommend it to other devs.
Game dev is a very varied field, there’s lots of ways to get into it and there’s (almost) no bad choice as long as you put effort into it. Game development includes even things like art, sound, music, writing etc. which all are exciting in their own right (and indeed, if you want to make a game by yourself you’ll have the chance to dabble in all of them), but from the way you phrased your question I’m assuming that you want to focus first on the programming(/game engine) part.
For game engines, I’ve heard a lot of praise for Godot, both for its good design and possibilities. For a first game engine, I’d pick one that is well documented, has a strong community and a doable learning curve, I think Godot ticks all boxes. After that, you can look around to see if another engine matches your needs better, but you’ll already be familiar with the basics which are transferable.
For programming, the basic skills are again transferable between different languages of the same type; any popular imperative language should do. Lua is simple and straightforward, Python probably has the most resources for beginners, C still is the basis for a lot of the systems in use and will teach you more about computer science if you feel like it, C++ is popular for bigger projects in gamedev, the list goes on. No reason to be overwhelmed by choice though; pick any of them that seems to “click” with you and if you want to switch a few months later, you’ll get up to speed fast. Once you pick a language and have gone through the basics of it, a good game dev exercise I think is to try to make clones of existing small games. Games like Tic Tac Toe, Snake, Pong hold a surprising amount of challenges which will all come in handy when you’ll start making your own (more complex) thing.
Personally I have more experience with programming than with game engines, but you could go with either of them and leave the other for later as needed. As long as you’re motivated and put in effort, you’ll get there :)
Unrelated, but I’d remove the question mark from your title or add [Question] to the beginning of it. Some people (myself included) might think this was advice on where to start, not asking about where you should start. Good luck on your journey!
I’m not aware of there being a special build targeting riscv - maybe some searching around could find someone who did one? Other than that, I guess you could try compiling the source yourself - I guess that could end up being an exercise in itself.
Personally, I started developing in Godot, just fired up a tutorial two months ago and went from there, so unfortunately I am not that familiar with tic80 beyond a very superficial level :/
TBH this is a bit weird of a thing to do, as a lot of the things I originally made notes of I am not sure how much is in your design vs. what you're working with (transparency is great but a half-a-day tutorial is a lot to sift through). I feel like a teacher trying to grade an assignment but having little knowledge of the rubric or provided assets. I cleared the map (715 on easy) unless I missed something more than the basic loop, ultimately it seems fine (even as not 100% my thing). ~115MiB download is a little big for this art style and such little amount of content IMO, optimization or whittling/stylization could probably be had (I mean sure, most people don't care).
thank you for the Linux export
the non-round collision on the player can lead to getting (partially) stuck when rotating+moving due to position being shifted (getting over it, maybe?)
the room being zoomed doesn't seem quite great (and also makes it seem like a significant thing), but again this is a thing that I know is tied to the tutorial
even outside the camera would benefit from some aim shifting particularly vertically when aiming near the top/bottom of the screen
something like the steam vent might me more interesting if the player could walk through/under the steam instead of blocked
the throwable range seems too short for the mega-turrets esp w/current radius.
maybe do this on button release to allow a charged throw (or cooking mechanic) and possibly (optionally?) to prevent misfiring.
or something else like some amount of proximity and/or some stickiness instead of bouncing
distance is kind of cheesy. Both for how quick enemies can spawn endlessly and for the opposite reason being able to snipe the mega-turrets
spawners can be a bit annoying and maybe could use some behavior changes/variance
For something bigger, the ammo situation I think doesn't work so well. First try I ran out of ammo, I found the chest interaction on accident... this design (outside of loading screen tips or a wiki) may prevent a player from discovering that if they were better at conserving ammo and/or not having stray shots. The fallback of enemy shots isn't so great either (especially with melee enemies) and even a blast doesn't open them. I don't mind the idea, in-context not so much. Also my second game I had fully stocked ammo, but a later test I did run out and I'm not sure if that's because of me or randomness etc.
Side-note definitely with what you're working with: the top-down 2D/gritty Armor-Games style is one I can respect but also one that always seemed hard to read (like the angle/satellite-view just sort of makes everything feel unidentifiable unless it is really used carefully).
Thank you so much for having a look and giving feedback, it really does mean a lot to me. 😊 Like, seriously, this is basically just a small thing I threw into the void, having people see it and care enough to give feedback gives me a lot.
Yeah, I do agree with your points, a lot of it stems from the basic design being carried over from how the tutorial was set up. It was very basic, did not finish with anything close to a full game. I mostly decided to build upon it into a short game, because I wanted to develop that as a standard for myself from the beginning of doing this - makes it easier to learn and keep up continuing.
Most of the download size is basically from just using unmodified assets from both the tutorial itself and a few things I downloaded on top of that, this is really something I will look into for my next project(s). I think it wouldn’t be as egregious if the game itself had more content built from the assets, but I was definitely ready to move on to other things by the end. Same with the boss at the end of the inside level - I thought about giving it proper patterns and phases, but it remained a simple bullet sponge, because I wanted to start on my next project.
thank you for the Linux export
No problem at all, I am developing on Linux, and rely on friends to test on Windows 😅 - I have no one that could help me out there for Mac, so I left that one out.
the non-round collision on the player can lead to getting (partially) stuck when rotating+moving due to position being shifted (getting over it, maybe?)
Yeah, that one basically was a compromise between either having a huge circle as a hitbox (which felt strange and awkward), or having a separate one for the gun part of the sprite to prevent more cheese like shooting through walls (and weird behaviour with the torch on the gun). But I do agree, it is a suboptimal solution. I tested it for a bit and at least didn’t manage to get stuck properly without being able to get out anywhere, but I fear it might end up being possible somewhere.
the room being zoomed doesn’t seem quite great (and also makes it seem like a significant thing), but again this is a thing that I know is tied to the tutorial
Yupp, goes back to the tutorial and how it teaches zooming when entering/exiting trigger areas. I tried to somewhat give it a design purpose to foreshadow/teach about the zoom in the inside level, but it remained feeling a bit suboptimal, I must admit. I was thinking about maybe adjusting it a bit, so I might end up doing that on an update 🤔
even outside the camera would benefit from some aim shifting particularly vertically when aiming near the top/bottom of the screen
Oh, yes, that is something I thought about and ended up not doing - and then forgot. It was not brought up in the tutorial, but I think I do know how I could implement that. I should definitely revisit this - especially with how I ended up structuring the design around exploiting range.
something like the steam vent might me more interesting if the player could walk through/under the steam instead of blocked
I think I ended up not using it to its full potential, because early on I had not figured out how to properly set the Z index for particles. I agree, that would have added a lot to the atmosphere and could have opened up some interesting design potential.
the throwable range seems too short for the mega-turrets esp w/current radius.
This one actually might be due to me testing it too often and getting too good at throwing grenades with the player’s momentum added onto the throwing range. It ended up as a conscious decision to leave it too short when not using that, but I might increase it just a tad bit.
maybe do this on button release to allow a charged throw (or cooking mechanic) and possibly (optionally?) to prevent misfiring.
That’s actually a good idea, a friend of mine had some misfires when adjusting the mouse, where she accidentally ended up throwing grenades. Definitely something I will revisit.
or something else like some amount of proximity and/or some stickiness instead of bouncing
Yeah, I thought about reducing the bounce but ended up not doing it because it felt “good enough” - I will have a look there again.
distance is kind of cheesy. Both for how quick enemies can spawn endlessly and for the opposite reason being able to snipe the mega-turrets
Believe it or not, that was actually a conscious decision. 😅 I thought about how the player could best be forced into not rushing and carefully assessing and then clearing threats, and kiting back enemies and/or using range ended up being what I landed on. I can definitely see it only worked partially, but this would require some fundamental changes, that, to be honest, I don’t think I’ll implement. There also actually is a limit to how many of those bugs can spawn, but it might be too high 🤔
spawners can be a bit annoying and maybe could use some behavior changes/variance
Agree. To a certain extent, they were meant to be annoying roadblocks, but I guess I ended up going a bit overboard. They were the first enemy I created myself (as the tutorial itself did not cover spawning, and I wanted to look into how to implement it), and I at several points thought I should probably revisit them. I ended up not doing that, and it shows.
The chest and ammo situation is something that has come up several times in feedback I got from friends, with conflicting points of view. 🤔 I heard both that discovering chests without them being highlighted feels rewarding, and on the other hand, the points you brought up. I tried to design the very first area in a way, where the player is somewhat guided to them (with the item near the starting point guiding the player down, and a bug placed in a way where a missed shot will end up opening the chest[s] that are illuminated). I’m still not entirely sure how to handle that situation, to be honest, but I agree that running out of ammo at the moment is unfortunately just frustrating with no real rewarding way to overcome it - at most you can try to kite one of the alien scout or infested zombie enemies to the chest and make them fire into it.
Side-note definitely with what you’re working with: the top-down 2D/gritty Armor-Games style is one I can respect but also one that always seemed hard to read (like the angle/satellite-view just sort of makes everything feel unidentifiable unless it is really used carefully).
100% agree, I personally never quite liked the style, to be honest. For what I’m currently working on, I am going with a more retro but also more readable pixel style (with the added benefit that I can reasonably create assets in that style myself, even though my lack of talent and experience in the art department does shine through.) It stems from the assets provided with the tutorial, and I don’t think I will end up redoing any of that from the ground up.
Again, thank you so, so much. Genuinely made me smile and giddy to see someone having a closer look and leaving feedback. I hope even with the frustrations, you had a bit of fun while playing. Updates will be coming - although I don’t think there will be any that can fundamentally do away with all the issues. It’s more that I want to hold myself to the standard of supporting a project, instead of just dropping and forgetting about it, while I learn game development.
Thank you for having a look, it means a lot to me! :)
Finding the tutorial was actually as simple as just searching for “Godot Tutorial” on YouTube, I just went with the first one that looked like it provided a thorough introduction into everything. There are also a lot of tutorials on YT that are more advanced - and Godot actually has very good documentation behind it, with online guides linked within for a lot of topics.
A completely free(forever) grand strategy game where you control everything about your army, air force, and navy.
In Rixas, you will possess the heads of your country’s military throughout time. You will be able to create gear down to the finest details. The loadout of every soldier and composition of every platoon is under your control.
Politics is at large, as it is in any other organization. You don’t have full control over the government or your subordinates. People need time to be convinced of new ideas or equipment, and victory can make a nation complacent.
If you are curious and want to see more, check out the itch page or my other socials, or ask me anything!
While I’m all for dynamic swapping during gameplay, in the menus I suggest an option to disable controller, in case there is a malfunction. Also, to the same problem I’d suggest havinge the mouse cursor to have a) priority, that affects the menu element under the cursor (not the element selected) and b) a fade out time, so it can be active at the same time as controller is active, to prevent the case, where the game detects controller to be drifting. This will be a godsent feature, when, for some reason, even removing the controller does not fix the game detecting the drifting input.
Also, it would be cool to have a manual option to force displayed prompts, not only between keyboard and controller, but also between x-input, Direct-input and PlayStation controllers.
The consensus solution. The Steam Deck and Steam Controller’s touchpads can result in both mouse and joystick input being used simultaneously. Locking down which input is used prevents this from working as intended.
gamedev
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.