Commercial Game ideas

[Rachael]

Also would MAPINFO re-routing like that actually work? Care to post an example? I'm guessing this would still require the user to leave the map and re-enter it in-game?

Original mapinfo:

Code: Select all

map map03 "it's the third map"
{
next "map04"
}

map map04 "fourth map here"
{
... etc ...
}

Patched MAPINFO:

Code: Select all

map map03 "it's the third map"
{
next "map04a"
}

map map04 "fourth map here"
{
... etc for old version...
}

map map04a "fourth map here"
{
... etc for new version...
}

[kevansevans]

That doesn't really address the issue if the player is in Map04, then Map04 gets updated to Map04a. What happens to the player? If he's stuck in the old map, how do we get him out? And we can't leave old maps in the game, that would bloat the game with needless info.

Black Mesa had a similar problem, where when the game was updated, older saves just flat out didn't work. The work around this was to just not allow an old save to be loaded, and force the player to start a new game at the chapter they last left off, and the game would automatically give you what it would assume be within your inventory at that moment. However, this only works with games that are linear.

We might need to fork a build for this so we can comfortably adapt it to a platform that auto-updates for the player, because we can not just patch it like Zandronum does.

The more I think about this, the more I realize GZDoom is not well equipped to make a commercial game.

[Rachael]

I think you're seeing more of a problem than there really is, here. And with that kind of attitude you're going to go into something like this spending more time preemptively fixing mistakes than actually making any real progress on development. Maps by themselves don't bloat the game quite as much as you might think, and even so I've seen other game developers do way worse things.

Even if the player is stuck on the defective map, there is no pressing need to "get him out ASAP" - in fact, you don't have to get him out at all. If the player wants to play the fixed version of the map they can start a new game or you can introduce some way for them to reset the map to the new version. Otherwise - the save game is in the save game spot, glitches and all.

[Nash]

The "just start a new game" advice might be okay for simple arcade-y projects, but what about larger projects, like an RPG or something, let's just take Strife for example. For a Strife-like project with a long storyline, or even a Hexen-like project, it'd be frustrating for customers to force them to start a new game every time a map update patch is deployed...

Also the problem with map redirection is that the "fixed" map is technically a new map, so any actors in the previous map would be lost. Existing corpses, existing state of the level (previously opened doors or pressed switches, etc)...

[Rachael]

I already addressed that and I feel like I am repeating myself here, so I won't. If we can't move on from this, I feel like this is going to go nowhere.

[kevansevans]

What if it's a really critical bug like an unavoidable soft lock, or say under certain circumstances exiting the level guarantees a crash? That's not fun for the player to deal with, and it's a little unprofessional saying "get over it and start a new game", Especially if the game is really really big, and the patch occurs near the end. 6 hours put into a game is not fun to lose in the least bit. This isn't preemptively fixing problems, that's a genuine flaw in the engine we need to be extremely aware of when building the game.

[Rachael]

I am not going to be saying "get over it and start a new game". I will be offering options for players in the affected maps to progress no matter what. I already said I would be doing that. There's more ways to affect a map than opening it in GZDB and modifying it.

Also: Issues like this are why games need to be thoroughly beta-tested. While beta testing cannot conceivably get rid of every single bug, it does afford you the luxury of resetting a player's progress because beta testers come into it knowing that that can happen at any time.

[YukiHerz]

For this proposed small project I don't think it's too big of a deal, if it comes down to it, there could be scripted autosaves that save in different slots at different points in the game so players always have somewhere to go back to in case they find a problem.

[Reactor]

Another pretty important question is - how do we share the money once, let's say, the whole development team is assembled, everything goes fine and dandy, and the game becomes at least a moderate success? I mean, we live in different countries, and by experience I know that when it comes to the cuts everyone earned, there tends to be bickering and huge disagreements. And since we are an online community, not a company, we cannot really assemble contracts and such. I believe this is an essential topic to discuss, and we would love to avoid all financial conflicts which may emerge during a commercial release.
Eruanna, you must make sure you go along the right decisions once our endeavors reach this point.

[Rachael]

Who said you can't assemble contracts without a corporation?

I haven't really decided yet how to cut the profits from the game but I was thinking of giving everyone equal share, if possible, at least for the first one. It's very hard to fairly quantify an individual's work, and it's not fair to give a larger disbursement to one person just because they're louder and think they're justified for it when the rest of the team may disagree.

[Reactor]

Very well then, I am convinced It is good that you thought about this, as - let's be honest - the financial part can be the most problematic when indie developers fix something together without them actually being in a company. You know people, there will be individuals who'll claim bigger cut because they worked more and harder than others (to some extent, this is justified, as a programmer's task is usually the hardest), and if we could assemble this little development team of ours, an outbreak of a money-related debate could be devastating. I am impressed you thought about this part as well You know how important this is, and once the game itself is working perfectly fine, it would be a huge disappointment if the development team would suddenly turn against each other in financial questions.

[Kostov]

I can help out with voice acting, some audio editing, and translations to Swedish and possibly Russian, if needed.

[zrrion the insect]

I'm certainly interested in the idea (and have been chipping away at my own indie project for a while) but am unsure how much I would be able to commit. I could do art/mapping/coding/maybe va if needed.

[arookas]

I think this is a promising idea and hope to see only the best come of it.

For those who are caught on bugged-map "problem": if we use gzdoom or similar as a base, we can always edit the source of the engine to support restarting a specific map from the beginning, or make special load/save code to better support future patches in the event of an RPG-style game. It is open source, after all. I think storing player status upon entering the map, as well as storing map's current status, would allow for an easy "reset map to original entry" mechanic in event the current map has been patched. I think a possible negative this niche is fruitless to get caught over.

I'd join as a possible programmer or composer, but alas my own game project and hobby project keep me busy outside of work. It wouldn't be fair to join and not be able to contribute. I still wish the future team best of luck with this project.

[Rachael]

Thank you for the kind words, Arookas, and wish you the best of luck on your projects, as well!

As I've announced in Discord I've picked a team, but the team itself is not yet final. If you are interested I would definitely encourage you to still post as such here - people may resign, or I may need to expand the team, so the possibilities are still open. (Or someone else may pick you up for their project. )