itch.io

Fun game! 24 was a bit "Kaizo" but it was a good conclusion.

The default download is on 1.9, not 2.01 - (this is mostly an issue when using itch app to install)

The "better halftones" effect is a bit dangerous - it lets me choose values that lock up the CPU too easily right now!

This is a great challenging game for 1CC players! All the references are spot-on and the gameplay feels unique.

It looks appealing but playing it just made me want to go back and play Galaxy 5000 again. It's unsatisfying to control, even with practice. The steering doesn't "look ahead," so it never does the thing an actual driver would intuitively do, instead it massively oversteers most of the time. The best method appears to be to allow it to  make extremely wide turns(which = slow? except not here?). It's a premise that, as implemented, I don't want to be good at, because it's not QWOP - it's not like it's presented as being miraculous that I can even finish the race.

The weapons just add more contradictions because they are largely unavoidable and unaimable, so it's like, what are they contributing, really? 

I'm thinking about it. The problem is not that I don't want to do that, but I want to scope it correctly so that I can publish it once, it works, it covers the major bits and pieces, it's documented, and I don't have to maintain it and answer questions. So I also need to set up some clarifying boundaries to publish it, like "here are raw mechanisms and layout tools, you add the rules, camera, etc". I might be able to do that a few iterations down the road once I feel like I've solidified everything to where it's ready for production. As-is, it's not quite complete enough or polished enough to be more than a demonstration, but I think I'll get there, so...stay tuned!

First let's talk about game concept, which is both clear and not clear:

1. It's obviously "Megaman but Different" going by the stage design, powers,  obstacles, and aesthetic. But what's implemented doesn't demonstrate Megaman's concept.

2.  For one thing, I have all four elements at the start, so there's a jarring overload of abilities. I never managed to spot the distinction between them. Megaman approaches this by having you unlock them gradually and also in some places using sound and graphics to indicate strength and weakness against foes. (this is actually a thing the NES Megamans could have done better, probably)

3. There is little definition in the moment-to-moment platforming. What I mean by this is best illustrated by the distinctions between Mario, Megaman, Metroid, and Castlevania, and how each controls and what that means for the physics of motion. In Metroid, for example, your jump is extremely floaty, which helps both with precise shooting and with easing exploration in difficult terrain. In Castlevania your jumps are committed which encourages you to plan and strategize around the enemy patterns. Mario adds difficulty of control at high speed with a sense of momentum, and then plays that off against you by making the levels challenge you to keep up your speed. And in Megaman, you have both shooting and platforming challenges, so the jump is faster than Metroid, but still somewhat controlled so that you can place shots and dodge. All four games have pretty good platforming jump physics, but they're distinct because there's an overall intended feel to the game guiding them at an abstract level, and defining this abstract part is something you need, otherwise you won't have a benchmark for whether you've succeeded.

4. Because the moment-to-moment isn't well defined, there also isn't a way to pace the level around the character's abilities, and therefore there isn't an opportunity for the kinds of set-pieces that occur in Megaman. An interesting level design tries to stretch the boundaries of what the player abilities can do - not to the breaking point like a Kaizo level, but it presents scenarios where the strategies have to change slightly, where there is a different "puzzle" to be solved through your use of abilities. Nowhere is this more clear than in boss fights: if the player can solve a boss fight by mashing fast enough, then the game probably isn't aiming to really study and explore the abilities it gave the player, rendering them cosmetic.

5. Cosmetic abilities actually are not all bad, but it helps to acknowledge that that's what's going on in the design if you're going to have them because it's the kind of thing you want to cut for scope early on. A broad spread of abilities with really substantial differentiation and strengths and weaknesses is much, much harder to design than, say, three "archetypes" with mostly cosmetic variation.

Now, some technical/polish critique:

1. On boot I went to the the options menu first to set it to fullscreen and it is pretty unexplained. I knew that the combobox with "High" meant graphics quality because it's the same one that every Unity game has, but it still needs a label.

2. Once ingame I didn't know what the controls were so of course I had to alt-tab to look at the instructions here.

3.  I started testing the fire rate of each power and couldn't figure out what was controlling how many shots I could get out, so I couldn't develop any sense of how much firepower I could put out under pressure.

4. While I shot at stuff, there was no reason to try to fight anything, really, since it was so easy to run past and tank the damage, which contributed to me not learning if the abilities did anything differently from each other.

5. I let myself slide off the conveyor belt and didn't fall immediately. Wile E Coyote behavior intended?

6. I didn't recognize that the ladders were ladders, I just happened to notice that I was double-jumping and it looked like a glitch.

7. Once I reached the boss the game softlocked.

I just wrote an update detailing what's happened, https://triplefox.itch.io/galapagos/devlog/187898/october-2020

I just wrote an update detailing what's happened, https://triplefox.itch.io/galapagos/devlog/187898/october-2020

I like the concept of this - and by this, I mean the focus of the development. The specific thing you made remains ambiguous of course, but perhaps the levels could be less dense so that it's easier to see more successful interactions.

I'm thinking of some terms that describe the boundaries you're working with adequately and what came to mind at first was "physics", or maybe "metaphysics". But I was a little bit unsatisfied because of the implication that it's just collision and movement, or just abstract laws, and browsed Wikipedia and saw "natural science", and I think "nature" might work. Skilled play is often called "a science", but if that's a science, what you're working on is the thing that gets studied, which emerges from the nature of the thing itself, and the nature encompasses not just laws of physics but initial conditions, context, etc. By resisting the rules that would develop this game from the playable stage to a complete game loop, the nature of it is different, more open to suggestion - and it can be deemed a complete artwork at this stage, for the same reasons as Impressionist paintings. Perhaps the enjoyment is in imagining what it could be.

Lately I have been very interested in pinball, and the nature of a pinball experience is not just the game rules, the playfield, or the physics, but what parts of the machine are worn, whether the playfield is dirty, and other details about the particular setup that day. During the course of play, the nature of the game changes with the wear and tear, and interaction is fully connected with the outside world - it's not "knowable" like knowing facts about Super Mario Bros., studying the laws of the land, or writing mathematical proofs. The knowledge is more ephemeral and illegible, that this particular instance of the game behaves in a certain way and the tricks that let one play around that behavior. And the gamified parts of pinball have never been the thing that attracts new players: nobody knows or understands the rulesets and scoring at first, there is no expectation of tutorials or teaching moments, and only the enthusiasts get excited about competition. Everyone just walks up to the thing in a bar and starts playing however they like. They enjoy the aesthetics and the action of the ball, and then everything following that develops from wanting to study those things in more detail. Digital pinball simulations can recreate the major elements of this experience, but they still change its nature.

And I do believe that sensitivity to nature is most often absent from explanations of what games are, all the attempts to pin them down into airtight definitions and then plop a formal theory on top. Nature suggests the frequent inversion of thought process that occurs in artistic design between "what happens when I make these rules? better try it and find out," and "what rules do I need to make to study the nature of this?" It's acknowledging that the nature of the thing may change when the rule is added, that one rule suggests another, and that there isn't a moment where it has to stop evolving.

It was and still is a huge thing for me to grasp that I could apply any kinds of rules to any kind of creative work, defining the result as "my interpretation of the rules", not just "my creation": I could apply storytelling rules to games, ethical rules to stories, musical rules to ethics, game rules to music, and so on. A rule like "do not gamify" is one more way to go about it. It might be insufficient on its own to bring you to something you can let go of, but in that case you can always look for more rules to add to give it some shape.

Having just been on a virtual pinball kick, I had to try this. The game feel pales in comparison to real tables(which made me miserable) but the concept is worthy. I wish Mr. Flipper's turning was manually controlled.

This game is very close to being well-balanced, but the way in which draw-three forces two to the discard means almost all of your strategy has to bias towards maximal redundancy, and you can basically never use any of the power-up cards because the discards will almost certainly be useful floor tiles that would let you progress directly or keep your card count up.

I made a PICO-8 game for Ludum Dare and thought that maybe improving it and reworking the assets to fit GB spec would make a good GBJam entry, but it skirts the "original assets" limit. What do you think?

Could you link this to the LD rating page so I can rate it? I spotted this game through itch but I can't search for it on the ldjam site.

This is a problem I've totally run into before, and have been on both sides of from when I was a little kid posting in Usenet in the mid-1990's until today where I've tried on a few occasions to support groups doing fan games or open source games.

Basically, if you aren't paying people, then you are throwing a party, and if your party isn't great, people check out. Motivation, drive, focus are things you end up with by  accident, and when it's a group project it becomes very tempting to let someone else make the first move and not look like a fool. And anything you do might be worthy of extended discussion the first time you do it. Which in combination with large scope(which tends to inflate as a way of avoiding reaching a concrete and coherent resolution on any decision), makes things go slower, and slower, and slower, until everyone has given up. 

Plus it's easy to build a very flimsy kind of hype around the idea of "making a game" because games are fun at the surface, so lots of people sign up for what they hope will be a lightweight experience only for it to gradually sink in that there is a huge boulder to push up the mountain before the game can even resemble anything, and the things they thought they would work on and want to voice their opinions about are actually pretty simple decisions or only become relevant much later, while the majority of the work consists of blundering through the dark barely understanding how to move the project forward and learning new skills constantly to do so.

And even if you are paying people, this happens. Hiring people is a two-way thing in that while on a small team you would like for them to self-start and cover for you on many different fronts like intelligent automatons, the reality is that the average candidate will tend to hope that the job will be a straightforward fit to their very specific fixations and not require anything outside of that. Even more so when they're on a short term contract and already have the next gig on their mind - they may put on a brave face to pay bills, but no spoons will be spared to give your project special consideration, and if you let someone on who isn't up to it or is given insufficient direction, they crumble with anxiety and may be damaged by this toxic mix of obligations and inability to fulfill them.

And when put that way it becomes a little more apparent that team building is a kind of design process - you have to design both roles that you can fill and a workflow that puts those roles together in a way that does not blow up. Functioning game studios end up with a lot of overhead in the process because, as it turns out, what's acceptable for most people tends to be that mix of regular hours, a desk, bosses, meetings, and separations between "creative" and "business" roles. With all that stuff in place, the team can move forward and accomplish things even though not every member of it is a perfect fit or wholly engaged every day.

My solution has been to downscope to a project size that works for me alone and then fill in gaps by adding other people only once I think I have a clear role for them that doesn't cascade into "now you do all the work for me" - a lot of the fantasy of team building is that you just assemble the "artists/programmers/designers/writers" in a room and they automatically know what to do and how to resolve project decisions. Nobody does. Even if you've got motivated and skilled folks they will have blinders and bottlenecks. Even major, apparently better financed and organized stakeholders like publishers will fail at giving your project special attention and default to giving the low-quality, polish-focused feedback that you could get from any random player.

If you don't actually have the game done in any form yet I suggest rebooting it in a limited format that you can adapt from - the PICO-8, Twine or Bitsy version of the experience. Throw on as many limits as you can to avoid upscoping, even if it that means it becomes more like a mockup than a functioning game. If you can't finish it in that form, where the limits stop you from tacking on more stuff, then you don't have the game yet, you have an incoherent mess to untangle and prioritize. The team will have a much easier time seeing a working result and giving feedback on that than sitting in a long meeting going, "well, we could do any of these 50 things, let's keep all our options on the table."

Laatly, remember to mix group interactions with one on one interviewing. People share themselves differently in the two contexts and a lot of basic management issues can be resolved by going to person A and asking, "what's bugging you right now?" and then going to person B and saying "hey, person A is worried about X. Do you think you can help?" Because it will turn out that the communication just didn't happen before and they needed a go-between.

Godot has a Kinematic 2D Platformer demo that does what you are looking for.

Video demo

Collision is one of the most challenging parts in programming basic gameplay because of the mixture of geometry problems(what collides) and timing/synchronization problems(when/what order things resolve, breaking a continuous movement along multiple axes into simpler one axis steps, resolving unexpected overlaps from objects spawning or teleporting). As needs get more and more complex all games eventually need to create custom solutions instead of relying on a generic engine collision system.

Fortunately for basic behaviors like tile worlds with slopes we do have a lot of examples to work off of now!

The concept is fun and exciting at first. I stopped at stage five because the challenge  started to feel overly reliant on negotiating with an uncomfortable/imprecise control for picking up and throwing objects. It's in the awkward space between being a tight/precise puzzle game and a fluid platformer.

I have two picks for Windows:

OBS as an all-around "stream/screen capture/composite" - can convert the resulting clip to GIF after with e.g. an ffmpeg script.

ShareX for screenshots. It's a little more convenient than the "windows clipboard" route most of the time

Hi, and welcome to game dev!

First of all, it's great that you have someone supportive in your life. It can be very hard when the ideas are just stuck in your head and you can't act on them or talk about them in the way you want to. I often turn to writing in my personal diary now when I need to reflect on things and make big decisions and I'm feeling stuck. If you aren't already, it's a good habit to get into.

Regarding the game idea, there are a bunch of motivations to disentangle there:

• Raising money for rescue centers
• A game scenario revolving around dog rescues
• Gameplay based on a genre concept (shooter game)
• A specific feature of the game software(real stories, in-game catalogue of these stories)

These are all basically good ideas, when we put them in a list. You can see and imagine a way to execute on each one. Do they all go together? That part is more tricky.  The game's scenario, its reason for being, and the catalogue feature all make sense. But as you point out yourself, there is some kind of gap between "shooter game" and "dog rescue scenarios" that we have to tackle by working on the game design some more. So let's focus on that.

Here is a technique I use which is modeled on the classical "theories of truth" that appear in introductory philosophy courses. Read up on those first to get yourself oriented as to how I'm using them.

First, establish some ground rules about what the design goals are: What do we expect the player to do and to feel, and what methods are we implementing to convey that? What does the game believe is "true" about the world? (e.g.  "it is good to rescue dogs in danger" or "a violent intervention like shooting is OK") Brainstorm, and then try to make the things the game believes are true be justified by the things the player is seeing and doing: for example, "the player earns points for each dog rescued" justifies our belief that rescuing dogs is good, and "there is a character shown immediately threatening each dog" justifies the use of violence against that character. What we're ultimately looking for in the implementation part of things is a close correspondence to reality - it just makes sense to have those specific ideas and rules in the game, and where there are gaps like "it wouldn't work like that in the real world" we can lean on pragmatic justifications. 

You have a great starting point here because you can do this initial brainstorm by researching real rescue stories and then also listing things that already exist in shooter games. It's much easier to borrow and reuse elements than to try to develop them "from scratch".

After you've brainstormed a bit, you might find that while you have very specific elements that are cool ideas, like the catalogue feature, the game as a whole is still not coherent yet - the implementation is not succeeding at justifying the beliefs, nor do the beliefs motivate the implementation, and it's drifting away from being a specific genre like "shooter" too because there are too many competing elements. At this point it's time to try to filter things down and revise them into a smaller, more prioritized number of ideas that can cohere better: If a very specific belief like "shooting is OK" doesn't seem to be working, maybe a different common-sense phrase like "you should help those that can't defend themselves" will make it fit, and it motivates some different angle for the implementation like "the player has an ability that prevents dogs from getting into danger".  Some very big breakthroughs in your ideas can happen by revising towards better coherence and more efficient use of a limited "idea budget". You may have to make a hard decision about what to keep or cut, and it's much better to make that decision before you've started building anything!

After doing enough revision, eventually it will become very hard to make things cohere any better, like screwing in a bolt tighter and tighter until it just won't turn any more.  At that point you can show it around for more feedback, or move on to thinking about how to execute on the idea!

Feedback from other humans(players or developers or otherwise) is limited by what they see in front of them...it will tend to express everything as a surface issue of either polishing, expanding, or cutting parts of the game. That can be very helpful when you are trying to get a sense of how "much" you need to execute on a concept before people understand it. Things like finding out where people are getting stuck or confused, adjusting difficulty and balance are solved through this process.

For working on the basic concept of the game and figuring out major features and scope, you can get better feedback by developing your own rubric like the writing rubrics used in grading school papers, and "grading" the current game against the rubric to see where it succeeds and fails at the vision you have - abstract things like "what is the game about, what should the player do and feel," and so on. When the game is failing something in the rubric, that means you have to iterate, but that doesn't mean it takes a big change! It just means that you have to make a big shift in your perspective that wasn't obvious and might feel uncomfortable or contrary to what you wanted at first. 

That's where feedback from people tends to fail, because most people will come from the same perspective and can only suggest changes in small increments. When it comes to conceptual issues it's very hard to get the information you need just by discussing it at a low level. A conceptual failure that isn't polished tends to result in comments about what could be polished("I don't like the keyboard controls, could you add mouse controls") and then once you finish off every polish feature requested, you get silence.

With multiplayer games and virtual worlds there is a tendency for the community to take "ownership" of the game once it crosses a certain level of success, becoming resistant to any change. Then you will have to learn to be a politician. But that means having enough players to be successful first which is not guaranteed - it's far more likely that you get an empty server.