1

Topic: The Future Model for Neverball

Seeking comments on players' desires and wishes for the direction Neverball should take in the future.

I was a big fan and player of Super Monkey Ball on the Gamecube, and also played a few games on the GBA! but I am not sure if we want to make Neverball feature-identical to SMB, do we?

Once we have warps, secret levels and 2 new mini-games (awww, come on RLK!), that will be accomplished.

Where do any Neverball players see Neverball progressing in terms of the entire gameplay experience?

Currently Playing:
$150 worth of GOG.com classic games

2

Re: The Future Model for Neverball

Sorry for being a bit provocative. I think Neverball/Neverputt is a nice game. Actually my first impression was very good. But when You tried it for some days it gets boring. I know the same goes for most other games as well so don't take this to negative.

In fact I think Neverball/Neverputt is a very good foundation for building a lot of different games. I.e. clones of existing games. This strategy is in my opninion not very good. To really make this a killer, a different approach has to be taken. I don't have the golden answer, but I suggest to take it away from gaming and bringing it into a business framework.

Proposal for a project goal: Make a "never...." application where you can build factories. Factories is a new representation of software programs so factory building substitutes software programming. Input to the software program could be represented as input of raw material into the factory.

Again, sorry for being a bit provocative. But sometimes new ideas arise when you get some unexpected feedback.

If You think it is too stupid, just ignore it :-)

3

Re: The Future Model for Neverball

It is not my goal to produce a feature-complete reproduction of Super Monkey Ball.  Quite the contrary.  I intend for Neverball to remain very focused as a rolling-ball game.

In my mind, it is a question of value.  SMB cost $40.  Before a consumer can be convinced to buy it, they have to be convinced that they will recieve $40 worth of entertainment from it.  At its heart, SMB is a rolling-ball game, but a rolling-ball game might not be worth $40 to many consumers.  SEGA wisely decided to augment this with a variety of mini-games in order to inflate the value of the purchase.  This is a necessity in the modern game economy, and the reason for the ubiquity of mini-games.

In the open source community, we do not have to convince potential users on the basis of percieved value.  It costs them nothing to use our product.  If they grow tired of rolling balls and they want to play a kart racing game, they go download a free racing game.  The existence of a Neverkart mini-game does not sway their perceived value of Neverball.  At the very most, it saves them from having to click on two download URLs instead of one.

Witness MTP Target, a clone of the SMB target mini-game.  It been suggested that MTP Target and Neverball somehow be merged.  This is absurd.  What would be the value of this?  $0 + $0 = $0.  The net affect on the user's percieved value of both games is zero.

In the end, Neverball will remain tightly focused on making the very best rolling-ball game possible.  Focus is a luxury.  I intend to enjoy it.  Other developers are welcome to use any and all Neverball code in whatever open source project they choose.

4 (edited by themacmeister 2005-05-28 00:44:45)

Re: The Future Model for Neverball

But you have to admit, NeverKart does sound wonderful thwomps/smile

Or perhaps NeverBowling? I was a huge fan of MonkeyBowling thwomps/wink

On the subject of SMB and features, do you think a two player race (split-screen) would be possible? It appears that with a split screen and no ball-ball collisions and separate inputs it should be possible.

Cheers, and keep on truckin' down the line!

Currently Playing:
$150 worth of GOG.com classic games

5

Re: The Future Model for Neverball

My oppinion is that, more than wanting to pile up more features to Neverball, I think the most important is to create the conditions to have people create more level sets, otherwise it will all evolve around Mehdi and rlk's levels. (Of course, I like their levels very much, but once you play them 100 times, they get a little boring).
For this, I am creating a level set of my own, for which I have some levels created already, which of course . The problem I am facing is the lack of good documentation (specially for someone who doesn't want to create or play quake levels). Please note I am *not* blaming anyone for this, specially rlk, I can only thank him for the great job he did creating this game in his spare time. However, the current mapping documentation is directed to someone with a broad experience with gtkradiant and the common problems that arise from level creation.

So, I think a better documentation for level creation is a vital issue for neverball's success, and if someone considers forking the game, it will still need docs.
If someone with idle webspace on their hands, that would manage to set up a collaborative documentation effort (like a wiki or similar), to improve the current mapping documentation, I'd be willing to help.


PS: NeverBowling? Funny, I have a level called NeverBowl, which mimics the bowling game. thwomps/smile

6

Re: The Future Model for Neverball

A wiki solution was already propose and I think that's a really good idea. I don't know what rlk think about that, but I'm pretty sure he would agree.

If nobody has got time to set up one, I can try to install such a wiki here if you want. I don't know much about wiki though so if you have any suggestions about a good free(gpl) wiki software...  thwomps/wink

7

Re: The Future Model for Neverball

shinobufan wrote:

A wiki solution was already propose and I think that's a really good idea. I don't know what rlk think about that, but I'm pretty sure he would agree.

If nobody has got time to set up one, I can try to install such a wiki here if you want. I don't know much about wiki though so if you have any suggestions about a good free(gpl) wiki software...  thwomps/wink

Well I'm a bit biased, being an editor for the Wikipedia, but i do like Mediawiki
It is PHP script and requires mysql.
It needs  a mysql database, and a database user account which must be created by your host.  (I'm assuming you do not have root access to the system on which you would be running the wiki.)

To set up media wiki you would follow the instructions on: http://meta.wikimedia.org/wiki/MediaWik … stallation


Especially important is being sure to list the licence for the content appropriately. The default is probably GNU FDL, but there are some good reasons to thing about using a different licence. See http://people.debian.org/~srivasta/Posi … ment.xhtml for more info about that. The GPL is perfectly well suited for a wiki, as the 'source' of document is obviously the code visable when you hit the edit button.

8

Re: The Future Model for Neverball

Yes I love wikipedia and Mediawiki is really a good wiki engine that's true. Maybe it's too much for us ? I don't know ^-^ But I'll try it.

I've been able to install it on the same database as the table and the forum thwomps/wink It's online : http://shinobufan.intuxication.org/neverwiki/

It's empty at the moment thwomps/wink

I chose GNU FDL as other choices are not better (between nothing and CCL I don't know...). That's clearly not perfect, but it seems it cannot be change after installation of WikiMedia. We won't share a big amount of documentation here (not as much as wikipedia thwomps/wink ) so it's not *that* important and fdl will be sufficient don't you think ?

9

Re: The Future Model for Neverball

shinobufan wrote:

Yes I love wikipedia and Mediawiki is really a good wiki engine that's true. Maybe it's too much for us ? I don't know ^-^ But I'll try it.

I've been able to install it on the same database as the table and the forum thwomps/wink It's online : http://shinobufan.intuxication.org/neverwiki/

It's empty at the moment thwomps/wink

I chose GNU FDL as other choices are not better (between nothing and CCL I don't know...). That's clearly not perfect, but it seems it cannot be change after installation of WikiMedia. We won't share a big amount of documentation here (not as much as wikipedia thwomps/wink ) so it's not *that* important and fdl will be sufficient don't you think ?

Using the GFDL works, but is still less than ideal. That said, I doubt it will cause you any headaches so it is really not your worry.

10

Re: The Future Model for Neverball

Indeed, mediawiki seems a little overkill for this. Since I suggested it, I'll think on a solution too.

11

Re: The Future Model for Neverball

I like the current Wiki, but my brother, a computer programmer/analyst states (and I quote!):

"It uses PHP, so I'll give it about 30 pages until it falls over..."

Is his statement correct?

Currently Playing:
$150 worth of GOG.com classic games

12

Re: The Future Model for Neverball

themacmeister wrote:

I like the current Wiki, but my brother, a computer programmer/analyst states (and I quote!):

"It uses PHP, so I'll give it about 30 pages until it falls over..."

Is his statement correct?

The Wikipedia rarely goes down, and when it does it is silly harware things, or due to bandwidth bottlenecks. I've never heard of it failing due to PHP problems.

13

Re: The Future Model for Neverball

Tacvek wrote:

The Wikipedia rarely goes down, and when it does it is silly harware things, or due to bandwidth bottlenecks. I've never heard of it failing due to PHP problems.

I meant the neverwiki, which uses PHP. I don't think wikipedia uses PHP at all.
My brother suggests that PHP cannot handle more than about 30 pages of data before collapsing...

Currently Playing:
$150 worth of GOG.com classic games

14

Re: The Future Model for Neverball

themacmeister wrote:

My brother suggests that PHP cannot handle more than about 30 pages of data before collapsing...

If that was true, this forum was long gone thwomps/smile

15

Re: The Future Model for Neverball

themacmeister wrote:
Tacvek wrote:

The Wikipedia rarely goes down, and when it does it is silly harware things, or due to bandwidth bottlenecks. I've never heard of it failing due to PHP problems.

I meant the neverwiki, which uses PHP. I don't think wikipedia uses PHP at all.
My brother suggests that PHP cannot handle more than about 30 pages of data before collapsing...

Ah. That is your concern. I'm certain that memory issues are not a problem. If it were the Wikipedia would be no more. Wikipedia uses PHP, in fact it runs the exact same wiki softare as neverwiki. That is why i used it as an example.

16

Re: The Future Model for Neverball

[offtopic]
Tacvek, incidently, speaking of wikipedia: Wikipedia Leaks Some Users' Passwords

See if you're not in it.
[/offtopic]

17

Re: The Future Model for Neverball

canuck wrote:

[offtopic]
Tacvek, incidently, speaking of wikipedia: Wikipedia Leaks Some Users' Passwords

See if you're not in it.
[/offtopic]

I've already seen that. It is neither automated nor realy too worrysome. Despite claims that some inoccents were published on that list, I've seen no evidence of it. Based on the backlash, I doubt such a list will ever be published again. The paswords should really be salted. The whole thing was a bit of a stunt to encorage use of more secure passwords, and to remind vandals that use sockpupet accounts that they can still be tracked.

18

Re: The Future Model for Neverball

What is this totally wrong statement about php ? Php is the most used programing language over the web ! The nevertable is written in php, this forum, nearly all forums are too, and php/mysql together are really efficient, so really no problem about that ! Long life to php ! thwomps/cool

19

Re: The Future Model for Neverball

shinobufan wrote:

What is this totally wrong statement about php ? Php is the most used programing language over the web ! The nevertable is written in php, this forum, nearly all forums are too, and php/mysql together are really efficient, so really no problem about that ! Long life to php ! thwomps/cool

The statement is FUD by a PERL programmer no doubt.

20

Re: The Future Model for Neverball

Tacvek wrote:

The statement is FUD by a PERL programmer no doubt.

That is so close to the truth that it's scary!

Currently Playing:
$150 worth of GOG.com classic games

21

Re: The Future Model for Neverball

If you don't stop trolling around, I'll moderate this topic thwomps/wink

22

Re: The Future Model for Neverball

OK, back ontopic!

What type of documentation is needed?

I have already englishified almost all of Gillux's howto on the Wiki, but it is still woefully simplistic.

Any thoughts?

Currently Playing:
$150 worth of GOG.com classic games

23

Re: The Future Model for Neverball

I think it will be great to "merge" rlk documentation into the wiki. Gillux's howto sometimes say "see in the homepage" or something similar and I think it would be better if it was a internal link into another wiki section instead. If rlk agrees giving us his documentation of course !

Then we can imagine some small tutorials about how making some useful standard levels parts, for example how to make good switched train entities or something like that... As I don't create levels myself (yet) I'm not sure about what can be really helpful or not, but small examples can be great I think.

24

Re: The Future Model for Neverball

I would like to see a section on creating half-pipes (even though I hate them) and loop the loops (because I love them). Also needed is a section on each entity used (with example screenshots?) in plain english.

I would love to help out in this regard, except I don't fully understand the documentation as is, and don't understand how GtkRadiant automatically links/names these entities...

(and I suck at level design...)

Currently Playing:
$150 worth of GOG.com classic games

25

Re: The Future Model for Neverball

Of course you can take my documentation.  It was never intended to be anything more than a basic listing of the features available in a Neverball level, plus a checklist of common mistakes that people make.  Now that there exists a body of common practice and technique in Neverball mapping, it makes sense to expand the documentation.