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?
Recent community posts
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.
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.
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.