Advertisement

Release early, release often: This won't work for unoriginal and ported games

Started by April 11, 2014 12:24 PM
6 comments, last by tom_mai78101 10 years, 6 months ago

Currently, I am working on porting an old classic game to Java. The project began with the RERO software programming philosophy, hoping that I get user feedback on improving/adding game mechanics.

When I started, a few users were hyped about it. After a couple of days later since the project started, the hype waned so fast, I feel as if I am alone in the world.

It is now taking its toll on me, and I feel very demotivated when it all happened.

Note to others who are just starting out on game development or their projects, do not use RERO (Release early, release often). Users interested in your project wanted fully-playable demos, and not games with half-baked features such as mine.

I am not sure if this counts as a public service announcement. It could have been other reasons causing this, like my game, or something.

So, yeah.

EDIT: No, I'm not talking about professionally done ports. I'm talking about user-created, amateur hobby projects.


Users interested in your project wanted fully-playable demos, and not games with half-baked features such as mine.

Sounds like you just took the RERO philosophy too far.

Release early means you don't have to wait until the game is 100% complete to give it to your customers, but what you give to your customers should still have a significant amount of functionality. half-baked features != significant amount of functionality. If you can't provide a fully playable demo, then it's way too early to release under any philosophy.

Advertisement


Users interested in your project wanted fully-playable demos, and not games with half-baked features such as mine.

Sounds like you just took the RERO philosophy too far.

Exactly. I'm still learning the ropes, so looking on the bright side, I learned a lesson.

I prefer the idea of releasing when it works well. I certainly don't want a bad/incomplete/featureless/boring game realeased early and often.

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32

--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy

I think it depends on the audience. I agree it doesn't work so well on mainstream or general gamer audiences, especially places like Google Play where your game can be forever stung by 1 star reviews from people expecting a full game. On the other hand, I think it can work well for audiences more geared towards things like development, Linux or Open Source (e.g., releasing on places like Freecode, Sourceforge, or indeed advertising here on Gamedev).

I also agree with the comments that RERO shouldn't mean releasing something that's fundamentally incomplete. One of the nice things about RERO I think is that it focuses you to make something playable/fun as soon as possible, rather than spending months/years doing something that you're "still working on", but still isn't actually playable...

http://erebusrpg.sourceforge.net/ - Erebus, Open Source RPG for Windows/Linux/Android
http://conquests.sourceforge.net/ - Conquests, Open Source Civ-like Game for Windows/Linux

Ínteresting...
Advertisement


Users interested in your project wanted fully-playable demos, and not games with half-baked features such as mine.

Sounds like you just took the RERO philosophy too far.

Release early means you don't have to wait until the game is 100% complete to give it to your customers, but what you give to your customers should still have a significant amount of functionality. half-baked features != significant amount of functionality. If you can't provide a fully playable demo, then it's way too early to release under any philosophy.

I agree. The other advantage of RERO is that as users find bugs that you or your team (assuming you are in a team) may have missed you can then go in and fix them for the next release. That is one point of betas, to find where the bugs are on systems and fix them before the game is 100% complete. Although, I do feel RERO works across the board because of being able to release updates and patches on every system (just have to allow for the approval time).

Isn't that something similar to Scrum?

This topic is closed to new replies.

Advertisement