I noticed a problem: Many, I really mean "the most", stay solo on developing. Why is it that way? There are indie devs who invested months and years into ONE single project. Wouldn't it have been easier when the devs form a group.

I work alone mainly because I don't want to argue or compromise on what I make.  Working alone means I can make only what I want to make, and I can make it however I please, without having to convince anyone that it's the right decision.  I also want to work at my own pace without other people depending on me, or me having to depend on them.

Unfortunately, working alone is also exhausting and demoralizing, but to me it feels like the only option.

Thank you for the offer, I will consider it.  I have not decided what to do about music, other than a couple of tracks I have already produced for demo purposes, but it will probably be a while before the project is ready for a serious music pass.

Thank you for the detailed review and thank you for sharing it here!

I don't know why the moderators allow you to keep spamming this topic over and over.  I would have banned you a long time ago.

You prove a good point that caring about numbers is a bad thing and that I should focus more on individual people, but dude I don't even have that. People on my Reddit posts just say it looks cool, like bruh can you play the game please?

Is there a formula that makes games blow up, or at the very least have some YouTubers cover the game and give live feedback?

You've already discovered the formula: meme horror games.  I count a total of twenty-six gameplay videos linked from the comments of your other three project pages, mostly for the two Siren Head games.  That's a lot.  When a YouTuber runs a generic search for "siren head" looking for something to entertain their audience, they will find your games in the list.  Your original tower defense project will probably not get the same level of attention as those.

A feedback circle probably works for short-form games, but something like my last release, which is a long-form game in a niche genre, is still not really going to get the kind of feedback that it would most benefit from.  It requires too much engagement, and it would not be reasonable for me to expect that from people.

It's clean, which is good, but you don't have much information there.  Consider adding more info about the kinds of games that you make or aspire to make.  I would also consider changing the default color scheme, but that's up to you.

but countless times I feel like my dating sims are good at first, until I trash out my idea and the cycle starts all over again.

It's probably not trash.  It probably just needs refinement.

I'm not much of a writer, so I don't have any advice on how to get better at writing, other than practice.  If you are anything like me, though, you need to not just write, but rewrite.

My first attempt at a scene or conversation usually isn't great.  That's OK, though.  I just do the best I can in the moment, which I may or may not be happy with.  Then I move on to something else.  When I come back to that section later and reread it, I might think it's awful and despair that I wrote something so bad, but I will see ways to improve it, so I rewrite it.  It's probably still not good enough, though, so I come back to it again later.  Then I rewrite it again.  I keep doing that until I have something satisfactory.

I am not talking about proofreading (although that is mandatory) but revising the text for better flow, better word choice, more natural dialogue, more evocative descriptions and so on.  It takes a few tries to get it right.  So basically, don't be discouraged if your work seems poor at a second or third look.  Just keep going over it again and again until it's polished.

How did you implement this?

I have also had my dev logs appear in their correct category, and then later disappear.  It makes no sense and there is no transparency.  I don't even know if it's working properly.

There are many, many ways you can do this depending on the complexity you need, but first you should know why that data isn't persisting currently.  It sounds like you are assigning the player's name to some MonoBehaviour attached to a GameObject in the scene.  You can do that, but (by default) when you unload a scene, every object in the scene is destroyed and its data is lost.  Even if you have e.g. a copy of the same prefab in every scene, each one is still a separate object with its own state.

A simple way to do this would be to create a ScriptableObject containing variables for the player's name and whatever other persistent data you need (health / ammo / etc) and set the values there.  Then anywhere you reference that ScriptableObject in the application, you will see the same values, because there is only ever one copy of a ScriptableObject and it is not tied to a scene.  To get the data to persist after closing the game, you would have to write those values to a file when the player saves the game, then read them from the file when the player loads the game.

Thank you!

I just keep in mind that nobody really cares what I'm doing.  Publishing is an act of completion for myself more than for anybody else, like framing a finished painting before putting it away in the attic.  From that perspective, there's nothing for me to be afraid of.  Obviously I hope someone enjoys my work from time to time, but if not, I made something that I wanted to make and passed another milestone on the journey to making better games.

Not at all.  To describe my work as niche would be doing it a kindness, so I genuinely can't see why a non-gamer would have any interest in it.

Grilled chicken, jalapeños, tomatoes, and red bell peppers.

Another point I would like to add is that if he had changed his mind he would have noted it directly in the video. If I made something I did not like no matter what I would tell people "I do not like making games of this genre, I will try to build something else that is more of my style", but in the video he still calls his finished product a Roguelike. So, the original idea was to make a Roguelike, his final idea was still to make a Roguelike, he did not have a change of mind in this regard. The only change of mind, maybe, was that he dropped the puzzle aspect of his game which is something he mentioned early in the video, but something that he did not follow through.

You still seem to be saying that this person just picked an arbitrary label that they didn't really understand, then worked backwards to arrive at a product that they thought fit the label.  That doesn't make sense to me.  Something about roguelikes evidently piqued their interest, but if they were really committed to making a turn-based, tile-based RPG, they would have.  They wouldn't have scrapped that design and made a twin-stick shooter instead, just because they saw that some of those are labeled "roguelike."  I can't see how tighter application of that label by other developers would have prevented any genre drift by this one.  They might have just gone further afield for inspiration before finding something they liked.  Games create genres, not the other way around; genres are just a shorthand in how we talk about games.

Moreover, the developer could very well have made such a change without ever seeing those other games.  Did you know that Diablo 1 was originally a turn-based game?  It evolved into real-time combat later in development.  This despite that Blizzard North explicitly cited Rogue itself as an inspiration for Diablo.

Why would they? Didn't you say it was a theme, not a genre?

To me it is.  Sometimes it's useful to loosely indicate a genre, but it can really be any sort of game.

I am actually curious now, what do these people consider a game to be a dungeon-crawler? Perhaps it is something I'd like to play too.

Sure.  Here you go.  This is a very strict definition that largely limits the term to only the most traditional Wizardry and Dungeon Master descendants.  By this definition, Might and Magic III is a dungeon crawler, but Might and Magic VI is not.

I don't really agree with the lines drawn there, but it goes to show how subjective genre labels can be.

In a nutshell, the developer was developing a Roguelike, but because it did not pan out the way he intended to, he got inspired by games he found on Steam to make another quote-on-quote "Roguelike", wrongfully thinking he was still developing a Roguelike and that misconception came from a spread-out misinformation that still gets perpetuated to this day.

You are saying that you expected an authentic traditional roguelike experience from a developer who, by your own account, doesn't even know what a roguelike is.

What seems to have happened here is that the developer did not like what they were making, so they made something else instead.  You seem to be suggesting that the reason this happened is that language is insufficiently prescriptivist, and not that the developer just saw something they liked better and changed their mind.

Secondly, this asinine problem makes it harder for me (and other people like me) to find games that I like, thankfully the Dungeon-Crawler tag still works and that is the only way I can still find Roguelikes on gaming sites such as Steam, Itch and Gamejolt.

I don't see why that would be the case.  Not all dungeon crawlers are roguelikes, not even close; and roguelites are probably almost as apt to be labeled dungeon crawlers as roguelikes are, given that dungeon crawling is typically considered a theme, not a genre.

I decided to try this out for myself.  Both The Binding of Isaac and Slay the Spire, which you keep bringing up as undesirable, are tagged "dungeon crawler" on Steam; in fact, when I browse the dungeon crawler tag on Steam, both of those games are prominently displayed in the banner at the top of the page.  Glancing over the actual recommendations, I see a handful of traditional roguelikes, as is expected, but I mostly see other genres.  If I were actually looking for roguelikes in this list, I would probably be disappointed.  The roguelike list is, as you say, a mix of roguelikes and roguelites, but it looks more promising than the dungeon crawlers.

Filtering my own Steam library for dungeon crawlers, I see JRPGs, action RPGs, first-person shooters, arcade games, puzzle games, board games, a platformer, and more.  Few of these are what I would actually want to see when searching for dungeon crawlers.

If you still find the dungeon crawler tag a reasonable and effective filter for roguelikes in spite of all that, then why do you find the roguelike tag so unusable?  I sympathize with your difficulty in finding what you want, but most highly specific sub-subgenres do not have a commonly agreed-upon label at all, let alone one as precisely defined (if frequently misapplied) as "roguelike."  All anyone has to meet their specific tastes is an approximation, which then has to be sifted by hand.  It isn't just roguelikes.

By the way, I know of folks who would take umbrage at grouping traditional roguelikes in with dungeon crawlers.  To them, dungeon crawler is a term with a very specific, long-established meaning (which does not include Rogue) that has been diluted into uselessness, making it difficult to find the true dungeon crawlers amongst all the mislabeled pretenders.

Nevertheless, while language is subjective, it needs to serve its purpose. I can not imagine how a conversation between a fan of Rogue and a fan of Isaac would go like when the term that even link these 2 games together have different definitions, the other of which is wrong

Why can you not imagine it?  I would think that they would discuss the games themselves, rather than being confused and deadlocked over a label.  I can't remember ever having that problem.

Why do you keep posting this nonsense? 

You could always split the difference.  Maybe if fps>60, alternate or randomly choose between a new ship and an accelerated one, instead of always spawning a new one.  That would close the potential gap a bit, and would also mix it up a bit more when performance isn't an issue.

I have seen this as well, but I have also seen posts newer than mine show up.  I just assumed that the staff deemed my posts unfit to display there, for some completely opaque reason, and delisted them.

Great progress so far.  Looking forward to seeing more.

It sounds like you need to apply gravity to the ship and/or increase its mass.  Or, if the ship never needs to move up and down at all, you could just reset its Y position every frame.

As for jittery movement, if you are applying a force or some other physics function, you should do it in FixedUpdate.  If you are applying a regular translation or rotation or doing anything else, you should do it in Update.

I am not sure what technologies you are using or what you have already tried, but all you should need to do is apply a force* along the ship object's forward axis, i.e. the vector that corresponds to the ship's facing.  So for example, if the ship's positive Z axis points in the direction of travel, you would direct its movement along the positive Z axis (relative to the ship, not the world space).  Meanwhile, steering would just rotate the ship along its vertical axis without applying a directional force.  This would mean that regardless of how the ship is rotated, it will always continue moving along its own forward axis.

I am not an expert in nautical physics, so you may be trying to do something more complicated, but this should handle the basic case.

* Substitute translation, acceleration, etc. for whatever method you're using to calculate movement.

I hope you will reconsider.  I get ditching the forums because of this frequent foolishness being allowed, but your creator page is your space.  If you have made up your mind though, where will you take your content?

If you don't mind me asking, I'm curious about my next questions because it's nice to get some experience in knowing the way that other people work on their projects. When you spent 1-2 weeks developing your games, How many days do you think you worked on it in a week, and for about how many hours per day?  One of the reasons I am curious is because I generally only have time during the weekend to work on my games and I feel that may be slowing down my progress.

I work full-time but don't have many demands on my time outside of that.  Most of these were made for game jams, so I worked more intensely on them then I otherwise would have, probably a couple hours a night on weeknights and more on the weekends.  They would probably have taken 3-4 weekends to complete if I were only working on them then.  I also can't keep up a jam pace of development indefinitely, so this time frame doesn't necessarily scale up for larger games.  Note that these aren't extensively-polished games with full option menus and such; they were made quickly to a minimal standard, and I moved on after finishing them.

Something else that interests me is that you said you made an RPG game in two months. I don't generally play RPG games so forgive me if I'm way off... But when I think of RPG games I imagine them including Inventories, characters, missions, maps, maybe some animals, a storyline, interactions, music, rewards, save points, etc... And while all of these things can be cut down — for example maybe the game only has 1 map instead of 5 — It is not much different from what I'm trying to achieve. Perhaps I'm just slower lol, but what do you think helped you to efficiently develop those aspects of the game? and Also what did your "bare-bones" game include or not include that made the initial development phase quicker? 

The game is a traditional dungeon crawl, so I asked myself, what does a dungeon crawl really need and what can I do without?  Thinking about what worked in the classic games was helpful here.  Graphics are low-resolution, largely iconographic, and all flat images / sprites that I could draw fairly quickly.  You control five characters, but they are predefined, not custom.  Combat is turn-based against up to ten enemies at once.  Stats and skills are very simple and balance is hand-tailored to this scenario; it is not a full-fledged and fully-scalable system.  There is basic equipment and inventory, but only static NPC interaction, no shop feature, and no "side quests" as such.  The game world is small - five dungeon levels, each a 12x12 grid, and your objective is to explore them all and overcome the challenges presented in each, ending with a final boss.  The game being built on a grid made it easy to rapidly snap dungeon geometry and events into place.  There are save/load and automap features.  I wrote a post-mortem where I talk about some of these decisions and fitting the work into the allotted time frame.

Turn-based combat in particular appears straightforward, and it some ways it is, but it also demands a lot of menu programming and a strictly-controlled cadence of play and visual feedback.  This can be considerably more time-consuming to implement than, say, moving a fireball across the screen each frame and checking for collisions (unless maybe you're working from scratch and haven't implemented a collision API at all yet).

If your objective is just to tinker and play with code, then it doesn't really matter how you spend your time, but if your objective is to ship the game, the key is really to nail down your scope early and try not to get sidetracked adding stuff that might be cool, but isn't really important.  You can always add that stuff in the sequel.  As hobbyists, it is crucial to not let ourselves get carried away, because we can only do one thing at a time.

Also, know when good enough is good enough.  That goes for both game design and code architecture.  Don't spend time significantly refactoring code unless doing so will really save you time later.  Otherwise, save it for the next game.  It is much easier to declare a feature complete if you know when to stop.  I learn better practices and techniques with each game I complete, and since my next game is also an RPG, it is built directly on the framework I created for the last one.  I can now make something bigger and better, with new features, improved workflow, and enhanced playability, while also having shipped a complete game in the mean time.  Shipping is good for motivation.

I find it helpful to design things on paper first.  Whether it is a complex algorithm, a dungeon map, a statistical formula, a monster's behavior script, a gameplay feature or whatever else, I get my clipboard and sit in my bedroom for a while to work it out.  This eliminates the distraction of the IDE and level editor and lets me focus entirely on creating or problem-solving.  Then when I come back to the computer, it is much easier to implement the design I have settled on.

Interesting, I don't know if I have seen that approach before.  Theoretically then, faster hardware will tend to produce a different experience than slower hardware, because it will usually favor adding more ships over upgrading existing ones?  Have you done much comparison of older vs. newer hardware?

I don't know anything about Overcooked or working in 3D, but if you want to finish a game in under a month, you probably need to have the basic gameplay prototyped in a week or two.  Some genres are just more complicated to program than others.  Browsing some game jam entries might give you an idea of the type of games that people make very quickly.  

I work (I think) relatively slowly, and all of the finished games in my profile took 1-2 weeks to develop, except MM0, which took two months.  This one was far more complex than the others, but is still fairly bare-bones by RPG standards.  For that one, implementing the rules, mechanics, and GUI took about half the time, and the content and some basic polish and playtesting took the other half.  I still spent a lot of time after the initial jam period adding more features, polish, and fixes.  If I had to do it again in half the time, I would probably slash the RPG mechanics to the bare minimum to create a more arcadey experience.

Squarespace is an independent website hosting company.  It means that they used a template from Squarespace and did not correctly update all the fields. (In other words, it's an honest mistake.)

Sloppy, but fair enough.  I had hoped it was only something like that.

The twitter one I can answer too - if you follow someone there's a good chance they will follow you back, so the more people you follow, the more followers you get.  It's one of the ways to get followers quickly. 

I see.  I find that distasteful, but I guess it's expected behavior for a marketing firm.

More peculiar things that I noticed:

1) I made a mistake: the e-book is actually sold on the Superstring web site, not the Beamsplitter web site.  However, that's... not better.  Superstring is the publisher of your current game of the month, Acolyte, which just came out at the end of June.  Promoting two products by the same company at the same time, especially when one is brand-new and the other appears to be a competing product, makes me think that you have some undisclosed connection to that company.  Even moreso because:

2) The Twitter link at the bottom of your site links not to the Beamsplitter account, but to the account for some web design firm called Squarespace. What's your connection to that company?  It seems that Superstring's web site is also running on Squarespace infrastructure, since pressing Escape on their website prompts me to log in to Squarespace. 

3) Speaking of Twitter, why are you following 18,000 accounts?  I don't do social media, but I still find that very weird.

not quite sure what the scam would be given we don't want money. Or information. Or anything. 

Not strictly true.  You're collecting email addresses on a weird site, which I'm not comfortable providing.  Your websites (why do you have two?) also list an e-book, marketing packages, and publishing services for sale.

Incidentally, I don't trust giveaways in general, I definitely don't trust "no strings attached", and it bothers me that Konami probably has a copyright claim against one of the games you've retweeted recently.  Also, your Twitter account is ten years old with 30k followers, but I can't seem to find any information about you online.  Who are you?  What's your history?

I'm not saying you're up to something, I'm just saying there's no verdict 'til we know you.  Since your expertise is in marketing and brand awareness, you definitely won't be surprised by skepticism.

As far as I know it is not possible to maintain seamless compatibility with multiple versions. Once you import a project into a new version, going backwards is not supported and can cause problems.

However, I would go a step farther and say that this is probably not desirable anyway.  Because each LTS revision is essentially a different code base, behavior between revisions will be slightly different.  This can lead to one developer coding something that doesn't work quite the same in another developer's release, or QA assigning a bug to a developer who can't reproduce it.  Having everyone on the same release prevents this kind of confusion.

As for how to manage versions, it is really up to you how often to update, but at a minimum I would recommend researching and testing any new version before committing to it.  I generally don't update very often unless there's something specific I want from the new version.  At some point prior to release, you will probably want to lock down the Unity version to avoid any last-minute engine-related issues.

Thank you! I'm working to improve the next one.

However . . . what about the situations where spawning another enemy could negatively affect the framerate? That's where the exhaust animation comes in. Instead of spawning a new enemy, the existing shield fighters will fire up their engines and accelerate towards the player. It's easier to make an existing enemy "harder" than to draw a new enemy on the screen.

Interesting, how do you determine that?  Do you just have a hard limit on the number of concurrently spawned enemies?

As far as I can tell, there are two types of games that get featured:

1) Games that the staff likes and wants to promote.

2) Games that are already popular and have received widespread attention.

There's no submission process or guarantee.  You are probably better off focusing on promoting your game in general than specifically trying to make the featured list, since few games ever will.

It depends on how much animation you want, really.  A lo-fi and especially turn-based game can get away with very little.

Yes, please.  These links really clutter the page, especially for browser games, where they overlap the player window if not maximized.  This is becoming a consideration for me over whether to submit existing projects to bundle/showcase type jams, and I have also considered doing as you say and removing certain old submissions.  It's noise.

I'm not opposed to the link being present, since it does (slightly) benefit mutual discoverability after the fact, but the placement of it is bad.  Maybe the theme editor can provide an option to toggle between the "badge" style and a list of links placed at the bottom of the page above the comment section, where they don't interfere with the actual page content.

Or, another idea could be to have one collapsed "Jam Submissions (3)" badge that the user can click to expand or collapse again.  As a user browsing games, I rarely care about what jams a game has been submitted to anyway.  I can easily expand the list if I really want to know.

There's also another issue with these links, which is that they remain even when the jam is no longer accessible, like this one:

The user who created this jam is long gone, and the link to the jam is dead.  Clicking it generates a 404 error.

Is this more for proof-of-concept / tech demos as opposed to finished games?

I can see that existing projects are technically allowed, but that doesn't seem to be the intent.

Interesting ideas.  I use spreadsheets for some crude manual forecasting, but I hadn't thought of generating reports like that.  That would give you a lot of data to identify the pain points.

Outside of raw numbers though, I wonder how to get feedback on content and design.  For my previous game, I was able to get a good bit of feedback to improve the early game, but relatively little beyond that.  And that's fair enough, because 30m of peoples' time is already a lot to ask for, but it does leave me uncertain about what (if anything) I'm doing well and what needs to improve.

What approach do people take towards playtesting and balancing?  RPGs can be long and involved, so there's a lot to consider, and soliciting feedback on such potentially large projects isn't necessarily feasible.