How difficult it is to make what we wish for?

Feature requests and ideas for the new unofficial versions of Elma and general talk related to those.

Moderator: Moporators

Post Reply
edg
Kuski
Posts: 5
Joined: 14 Sep 2004, 16:37

How difficult it is to make what we wish for?

Post by edg »

When I saw the list on http://www.moposite.com/info_elasto_man ... rsions.php the first thing that came to my mind was "Too much". There is a rather great possibility that it's exactly what Balazs thinks of when visiting that page (I guess he hasn't forgotten Elma and does visit Mopolauta occasionaly).

I'd suggest sorting the wishes in small groups, so that it doesn't appear so much. For example:

Elma 1.3
- ...
- ...

Elma 1.4
- ...
- ...

And sorting could be done in a way that Balazs would just look at the first (Elma 1.3 or so) and think "Hey, that's not much. I can do that even right now!"

Here comes the need of knowing what is easy to be done and what is difficult. I'm no professional but could give just a little try to approximate human time needed for the requirements (wishes).

Before I do that, there are two assumptions:
1. The game should not be done from the scratch, it will be an upgrade to the existing one. The overall time will be much greater this way (very much actually) but the idea to have versions 1.3, 1.4 is so much better than imagining Balazs creating version 2.0 for 3 years and then realizing the requirements were too much for him, aborting the project for the sake of other things.
2. The game engine will not be rewriten. C'mon, the slesk jumps and stuff like that - it's a part of the beauty. Therefore the game stays to be fullscreen mode, bla bla bla...

I'll be using this format: (P.X:XX D.X:XX), which means Projecting time and Development time (Coding+Testing) in Hours:Minutes. Some might find the projecting times too large but they are based on understanding that Balazs has long forgotten the design of Elma (but I presume he remembers at least something, so he could quite easily find places in the code where this or that happens). Also, don't forget that implementing a function is not only creating the functionality itself, it is also the user interface including configuration of the function. Oh, one more thing: the times are not only very inaccurate, they also vary from ppl to ppl, so it might take 5x slower of 5x faster. And I've noticed myself making too overconfident predictions about long time works. For example, 5h is most probably 10h, while 10mins could be 2mins or 30min (50x overconfidence would be bad for the first (when no projecting has been done yet) software project time evaluating, 5x is good).

So, here we go.

First, a wish of my own:
* Create an official version of 1.2, having the functionality of the existing non-official version.

- Lev-packs. (not included, because there will be many folder lev and rec listing later)
- Fast search in menus (improved since 1.11h). (P.0:20 D.0:05)
- Merging replays. (UI (=User Interface) (P.1:00 D.0:30) F (=Functionality) (P.0:30 D.1:00))
- Alovolt key. (P.0:50 D.0:20)
- Brake alias key. (P.0:10 D.0:10) <- after altvolt it should be ez because they are both of a kind.
- Esc alias key. (P.0:10 D.0:10)
- VCR-style controls when watching replays. (P.2:00 D.1:30)

Options: (UI (P.1:00 D.1:00))
- Screen resolution. (P.0:30 D.0:20)
- Zoom. This option can make ElastoMania crash in some levels, please read "Known problems". (P.1:00 D.0:30) (this is if zooming is some drop-down list. having a number entered makes the development 0:10 or so more, plus, it's confising for beginers)
- Centered camera. (P.0:10 D.0:20)
- Navigator size. (P.0:10 D.0:20) (i believe it should be a small-average-big kind of user friendly and understandable kind of drop down list)
- Navigator zoom. (P.0:10 D.0:10)
- Main menu configuration: lets you remove lines from the main menu. (not included because against any common practice in user interface designing. elements of user interface should be hidden only if it is absolutely obvious why they're not there any more or there is an obvious way of getting the element back again (like a big red button saying "Click here to see all the menu"). I doubt someone has ever found this functionality so very useful that it should be somehow difficultly (when comparing to gains) implemented so that it still would not be a possible problem to beginers)
- Default ground/sky: use the "ground" and "sky" textures in every LEV. (P.0:20 D.0:20)
- Still food. Apples and flowers stop moving up and down. (P.0:20 D.0:30)
- Replay saving reminder: reminds you of saving a replay when you've made a best time and select something else than "Save play". (P.0:30 D.0:20)
- Pictures in background. All the pictures (trees etc.) are displayed behind the bike. (P.0:20 D.0:20)
- Edit locked LEVs. (not implemented, because is against of the meaning of locking levs)

I'd also suggest graphic options to be changeable during the game (that means game pause in itself, therefore game pause could and should also be added. with penalty seconds... also, to make pause more difficult instrument for cheaters, the game screen should not be visible during the pause). (P.1:00 D.1:00)

Total: 8:45 + 8:40 = 17:25 hours.

If working together with the creators of the unofficial, it might take up to 5x (more like 1,5x) less time.


And here the wishes from the http://www.moposite.com/info_elasto_man ... rsions.php
* 50-100 brand new levels. It should be so that NONE of the old levels are used for the next version. That because it's annoying if you have played much one track in Across 1.1 & 1.2 or Elma and then you have to play it again. And no speedloops please. (if good level designers are assembled, they could create the levs, afterwards they could just be "put" in the Elma. Team gathering could be a matter of a week or a couple, still this takes almost none of the programming time. Level inclusion is never a difficult problem. The difficulty is only a matter of how easily can the tools for including be used. (P.0:30 D.0:30) (The time of reviewing the levs and stuff like that not included, because I simply have no idea of how that goes on in reality) Btw, I think not including the old levels at all is such a waste. Yes, the main levels should all be new, but the old should be found under the OLD folder. Here comes the inlcuding of other popular levs as well (like OLP, ALP, ...).
* Only use the sky as the background in the internals, bricks are annoying for eyes. (no, this comes as an option i've talked about before. beautiful backgrounds (shut off the brick thinking, imagine different other new backgrounds) are good to users who don't play for many hours a day)
* Water traps (P.2:00 D.1:00) (this will probably be a new kind of grass, having it's own texture (of course, animated!). don't know what large-scale problems this could have, but problems just like to appear from nowhere.)
* Remembers settings after closing elma (like map [on/off], time [on/off], position of the cursor in replay menu). (P.1:00 D.1:00) (this is listing the settings, designing the settings file for this, how the options file works, coding, testing)
* Better protection/crypting for state.dat (this is a tough one. to eliminate the possibility of simple autoplays and saveloads the .rec file should have timings (there are various ways of getting times. if many used, it is much easier to tell the .rec is cheated) + keystrokes (again, there could be additional keystroke readings used like straight from the port), when the game started, ended, blabla, current bike position, rearing and so on as it is now already. it should save and read the data to/from various places (example: roaring of the bike from the bit that makes it happen as well from the audio pre-output [that would make it obligatory to create audio output even when it's turned off. of course, it would be created but not played actually]). well, the rec file could also contain varoious data like .exe crc, maybe the screenshot of finishing level. even for the most obvious cracking attempts, the program should never warn the user or give any other hints for the cracker. i have a very weak understanding of what's inside the current recs. surely the anti-cracking team with their experience could list lots of suggestions based on the discovered cracking attempts until now.) (P.4:00 D.4:00) This is as difficult as good we want the protection. the 8 hours is a big guess (at least, bigger than anything before now).
* When you go to the Save Replay screen, the filename would be inserted there, so you don't have to guess which level you were playing. (and also your name could be put at the begining. like <name>_lev-<lev>_time-<mins>m<secs>s.rec. whatever we want it to be, it should be about the same. (P.0:30 D.0:30).
* External level list could be a table where stands level name, file name, designer, best time, best time's driver, driving date, level designing date, link to more statistics, used lgr and all other necessary info. (this looks like quite a wide table for a full-screen game. some sort of vertical scrolling would have to be made. (P.2:00 D.1:30))
* If you select a lev, the game would show all the recs you have for that lev. (i don't completely understand how it's wished to look and function like. if it's a link (near best times) to the list of records (and of course, the functionality as in the complete record list (and a link "All records"), then about... (P.2:30 D.2:00))
* Some online mode(s) like gaming over internet and intranet, maybe elma server (battles)? Could be a multiplayer-patch so the regular game file doesn't expand too much. (omg! but it's more simple than it looks at first. elma could simply send .rec data to server. here comes the menu functionality, various options of connection. server could receive the data, check for cheating (as this such checking is as a manual for cracker to understand how the anti-cheating works, there should be no anti-cheating included directly in the server. instead, the server calls custom dll which filters the incoming record stream, giving appropriate signals if the record is cheated). the server should then send out positions to all the other clients (like quake server). and all the game creating, everything what comes... ok, it's as difficult as it looks at first. i'm not even approximating this one, it could take up to a few months of serious work. it's a bit easier with the LAN. UDP packets could be sent out in a Carmageddon style. that means no anti-cheating, still ability to play over the LAN (P.20:00 D.13:00). oh, it just came in my mind: maybe you don't think of multiplayer like i do. i think of it as simulateously playing the same map. if only the battle-like "thing" should be invented then it's (P.10:00 D.8:00) (that is connecting to server, retrieving a map, starting battle, continuously playing the map while time is not ended, sending out .rec automatically after the battle, getting top. that asks for a chat as well (30mins of the time is for chat)
* Ability to play multiplayer with two computer like the current multimode but both would have own screen. (that's included in the carmageddon-style multiplayer. if only this functionality created, then it's about (P.7:00 D.6:00))
* To be able to hold down on the "Page Down/Up" button to get to the bottom or top of the list of recs or levs quicker like in Across. (P.0:20 D.0:10)
* Longer replays, over 10 minutes or even unlimited. (if the variable type must be changed (for example, if it's miliseconds now, then 10mins is 60000 which fits in an unsigned 2-byte variable. if should be changed to 4 bytes in that matter) (P.0:40 D.0:20) (needs only changing the type whereever it is needed. that means finding the places, correcting, possible offset calculating problems with .rec file if it's left as it is now, could be problems debugging, oh right - showing larger time on the screen). if the variable type must not be changed, it's only showing the the screen (that's about 5mins or so).
* Exact time in replays! ctrl-alt-enter must work perfectly! (P.1:00 D.0:30)
* Infomartion in replays: driver name, time :), driven date. (if you mean that the information is shown on the screen (P.0:30 D.1:00). if you mean it's written in the .rec file, then it's (P.0:20 D.0:30)
* It would also be nice to get rid of the ancient 8-char limit on filenames. (imho this is a must. (P.0:10 D.0:50) (the 50mins comes of finding all the (for (i=0;i++;i<8) and such places in the text. in those old times nobody thought of that the filename could be longer)
* Different grounds like ice and mud (only in external levels?) to slow the bike. (if the water is already implemented, this could be much easier because the concept of different "grasses" would be already done. so, if there is, there's left the problem of different reacion of hitting the ground. the mud could be done easier, because, if i recall correctly, there is a constant that tells the resistance of the ground. therefore it's (P.0:30 D.0:30). the ice could be a problem. does the bike ever slide? it is possible to make little bounces, smaller than a pixel, but the bike doesn't support sliding. and more - when it's gearing on the ground, it's rear wheel is kind of "stuck" to the ground. when flipping around (space) and pressing gas, it will never slide. a whole new idea of touching the ground should be created. that depends on the game engine. dunno, maybe 5 hours. i'm definately against changing the game engine in this manner. then better rework it completely and do an elma 2.0)
* When choosing a rec or lev file inside Elma, you could access any directory on your PC so that you don't have to copy Elma into several dirs so that in one you could play OLPs, in another your own externals, then in third your best friend's externals, the fourth for World Cup etc (same with replays). (P.0:30 D.0:30)
* Ability to change LGRs inside the game. (don't know. skipping this one)
* Ability to delete whatever time u want in all externals and internals. (that makes best times evolve from a list to some interactive list. (P.0:45 D.1:00) (imho, this is not a good option. it messes with the meaning of best times. even with the cheating. yes, you have the .rec file, but creating an inbuilt functionality for messing up best records list... c'mon)
* Fixing a state merging: if you merge a state where are more than one same time in one level the merging doesn't work well. (i've never done that merging. don't know)
* state.dat back-upping (this is surely a must if best times can be deleted. (P.1:00 D.1:00)

Without the stuff I did not want to try to approximate, and without the muliplayer thing, complete time in my approximation is about: 50 hours. Why so little? Well, now I have an urge to multiply all the times by 3 :P

Normally a programmer works an 8 hour work day. That could be approximately 4 hours of pure work. Doubt that Balazs would ever give more than 1 hour (if we're optimists then 2 hours) of work a day. That makes 50 days. But it's not true. There is a thing of leaving work half-done. If you have something to be done in 3 hours and you do 1 hour the first day. Then next day won't be just 2 hours, there will be additional time needed to remember what you did yesterday. It varies from ppl to ppl but when the result may still go up to 70 days. Yeah, there are other works apart pure programming - distributing, elastomania.com upgrading, getting in touch with level designers and so on. That is at least 10 days more. So, it comes to 80 days. It is normal for a person not to want to code at all occasionaly (yes, sometimes he can code 3 hours instead of one, but it's rare). Every fifth day could be left out (that's normal). Then it's 95 days already. Now, let's take it to 100 days to count in the stuff I've forgotten about. Now, how many days do a week do you think Balazs could code? After work he might not want to see computer at all. In weekend he might not want to do anythink (instead of relaxing after the long week and doing home-stuff). But let's suppose he's still going to code that hour a day after work. Then it's 5 days a week = 20 weeks = 4 months. When you tell a programmer, he has a 4 months of work, he KNOWS it will be 8 months, so Balazs obviously would say: "No way I'm going to waste so much time for this!".

That's why I suggest the 1.3, 1.4, ... version system. Then Balazs would look at it and say: "Oh, they think it's a day? Let's think about it... Hmm, could be three days. Still not much. I could do that even now!"

The thing is I don't have any wish to make that version list. Would you, after so much writing? Someone could do it for me, YOU for example :) Well, if you disagree with the timings, change as you wish. I intend this topic for discussing the difficuly of the updates (if anybody is interesed in the updates, of course).

P.S. This big post comes after you've done exams and can't stop after all the late homeworks written...
User avatar
AusDerReihe
Kuski
Posts: 41
Joined: 20 Jun 2005, 22:26
Location: Norway

Post by AusDerReihe »

this is the most thought through expression of opinion i've read in a long time on a forum, you even have knowledege of interaction design! you have no idea how pleased i am right now.

if i were developing the next elma i would hire you as my project manager immediately. i just need to ask, have you read Alan Cooper?
edg
Kuski
Posts: 5
Joined: 14 Sep 2004, 16:37

Post by edg »

Haha, someone could even read that large amount of text. I admit, I couldn't re-read it myself.

No, I haven't read Alan Cooper, but if you mean this book:
http://www.amazon.com/exec/obidos/tg/de ... 9?v=glance
then it seems quite interesting. Though, I've got a large list of to-do with higher priority right now...

And I'm not much of a project manager. (quote myself: "I'm no professional") Just finished my 2nd year in Computer Sciences. We had to do some project during the last semester. And guess what - we did much of a nothing the first 4 months in a strong belief that everything is going fine. And when only 3 weeks were left, I realized we're in deep trouble (it's a truly amazing story of how we "finished" the project, but that would be too much offtopic) Since those 3 weeks ago I always calculate the project time. And it proves to be quite close to my real speed (2 projects - accuracy was below 20% each (of course, a lot of luck involved)). Still, I've no idea how can I compare to an average programmer, since I've never seen any data of it. That means I've no idea how long Balazs would take on the project.
User avatar
AusDerReihe
Kuski
Posts: 41
Joined: 20 Jun 2005, 22:26
Location: Norway

Post by AusDerReihe »

that is the book i was thinking of, yes. i'm not finished with it yet, but it is a very good book to read if you plan on doing any serious programming. i'm not a programmmer myself, but i'm a "theory" kind of person, which causes me to learn stuff about things i'll never use ;)

i didn't actually close ready everything you worte, i didn't have to. i could understand you just by fast reading it. i will read it closely though.

nice job :)
<b>There are 10 kinds of people in this world, those who can read binaries, and those who can't.</b>
teajay
Donator duck
Posts: 10043
Joined: 3 Apr 2003, 17:53

Post by teajay »

This is much more usable for balazs than just simple ideas. I have no more things to add.
User avatar
AusDerReihe
Kuski
Posts: 41
Joined: 20 Jun 2005, 22:26
Location: Norway

Post by AusDerReihe »

tijsjoris wrote:This is much more usable for balazs than just simple ideas. I have no more things to add.
if balazs gets no input from users, ideas if you like, how can he improve or even do the improvements people want? wouldn't it be better to air ideas here, get a feeling for how people think of them and THEN giving them to him? what if someone sent him ideas that he used, without even presenting it to the users, and the game turned out to be very different than what people wanted? someone would complain, and he'd say "sorry, no one told me anything, so i made the new game just the way i thought it should be"

i think it would be kind of selfish to give balazs ideas without telling the community.
<b>There are 10 kinds of people in this world, those who can read binaries, and those who can't.</b>
User avatar
John
first 35tt
Posts: 4738
Joined: 28 Sep 2002, 19:42
Team: WNO
Location: Luleå, Sweden

Post by John »

I think tijs meant that edg's detailed walkthrough of the new features is more helpful than just the simple ideas explained in one line, like "we whane totaltime counter in game"...
Image
User avatar
AusDerReihe
Kuski
Posts: 41
Joined: 20 Jun 2005, 22:26
Location: Norway

Post by AusDerReihe »

John wrote:I think tijs meant that edg's detailed walkthrough of the new features is more helpful than just the simple ideas explained in one line, like "we whane totaltime counter in game"...
now that you mention it, i think you are absolutely right. my apologies to tijsjoris.

unfortunate effect of sleep deprivation, reading what isn't there. and maybe the habit of interpreting the words, rather than just reading. it's not desireable, but happens when you've read a gazillion post from users all over the world with varying knowledge of english. those sentences where words are in the wrong place, and could mean several things, when taking the "international" side of the web into account.

again, sorry.
<b>There are 10 kinds of people in this world, those who can read binaries, and those who can't.</b>
User avatar
twipley
Kuski
Posts: 756
Joined: 20 Nov 2004, 19:43

Post by twipley »

decontract my man 8) take a walk to teh beach ! :wink:
teajay
Donator duck
Posts: 10043
Joined: 3 Apr 2003, 17:53

Post by teajay »

Well, apologies accepted. But did I formulate something wrong?
User avatar
AusDerReihe
Kuski
Posts: 41
Joined: 20 Jun 2005, 22:26
Location: Norway

Post by AusDerReihe »

tijsjoris wrote:Well, apologies accepted. But did I formulate something wrong?
no, not at all. the mistake was all mine :)
<b>There are 10 kinds of people in this world, those who can read binaries, and those who can't.</b>
Post Reply