Live data from Hacker News

Elevator Saga – An elevator programming game

play.elevatorsaga.com

81–90 of 108 posts

Re: Elevator Saga – An elevator programming game

#81
post #74

A couple of problems with the API. First, why do you have to call checkDestinationQueue after modifying the queue? It's awfully redundant. I assume this is due to some kind of limitation. And second, goingUpIndicator and goingDownIndicator are kind of sketchy. Can you activate both at the same time? What effect would that have? There should be a single property, directionIndicator of an enum type with the possible va…

I'm not a developer of the game but:

DestinationQueue handling: It is not redundant, those are different options. Just to give an valid example: Add something to the queue, sort the queue, make the elevator run the updated and sorted queue.

Having both goingUpIndicator and goingDownIndicator is probabaly necessary to get this abritrary third state (both enabled / both disabled) which essentially indicates that the elevator will go in both directions.

Re: Elevator Saga – An elevator programming game

#82
I think it would be a lot easier if idle elevators have idle fire every time someone presses a button.

That way the elevator can evaluate the new situation. Now you have to look up an elevator in the button event, and the API does not specify many properties, only events.

Re: Elevator Saga – An elevator programming game

#83

Wow. I want so many more of these kind of things for my kids. It's so close to using code to solve real problems. How about an assembly line version where many parts have to come together in the correct order? Or an air traffic control one? Subway scheduling? Pizza delivery? More please!

Yeah! Something I think about occasionally is traffic-light optimization problems, optimizing for throughput, wait-time, safety etc. I think it could work well in a packaging similar to Elevator Saga.

Re: Elevator Saga – An elevator programming game

#84
Developer here! Thanks for all the feedback. Appreciate all of it, including bug reports! Pull requests also welcome.

Especially I would appreciate help with adding more challenges, and/or making them all balanced and interesting, for a good and reasonable difficulty curve.

It is very simple to tweak them - they are defined at the bottom of challenges.js: https://github.com/magwo/elevatorsaga/blob/master/challenges...

Re: Elevator Saga – An elevator programming game

#85
post #81
post #74

A couple of problems with the API. First, why do you have to call checkDestinationQueue after modifying the queue? It's awfully redundant. I assume this is due to some kind of limitation. And second, goingUpIndicator and goingDownIndicator are kind of sketchy. Can you activate both at the same time? What effect would that have? There should be a single property, directionIndicator of an enum type with the possible va…

I'm not a developer of the game but: DestinationQueue handling: It is not redundant, those are different options. Just to give an valid example: Add something to the queue, sort the queue, make the elevator run the updated and sorted queue. Having both goingUpIndicator and goingDownIndicator is probabaly necessary to get this abritrary third state (both enabled / both disabled) which essentially indicates that the el…

Yeah this is basically correct. There is nothing really preventing an elevator from reporting that it's going both up and down. The up/down indicators are used for two things: 1. To shut off the up/down request indicators correctly on the floor when the elevator arrives. 2. By passengers to decide whether to get on an elevator or not.

Re: Elevator Saga – An elevator programming game

#87
post #43

// works well enough: { currentFloor: 0, init: function(elevators, floors) { var elevator = elevators[0]; // Let's use the first elevator elevator.on("idle", function() { // The elevator is idle, so let's go to all the floors (or did we forget one?) var nextFloor; do nextFloor = Math.round(Math.random() * 2); while (nextFloor == this.currentFloor); elevator.goToFloor(this.currentFloor = nextFloor); }); }, update: fun…

Okay, didn't read or look (currentFloor is already defined) and this won't work in this context.

Here is another approach that brought me through till challenge #7:

    {   
        init: function(elevators, floors)  // hook up events
        {
            // these are the global wish lists that idle elevators choose from (key are floor numbers, values are number of people): 
            var wishListUp = {}, wishListDown = {}; 

            for (var i = 0, l = elevators.length; i  0)
                    {
                        this.destinationQueue = this.destinationQueue.filter(function(d) { return d != floorNum; });  // remove from later
                        this.destinationQueue.unshift(floorNum);  // add as immediate next destination
                        this.checkDestinationQueue();  // announce modification
                    }
                    else if (this.loadFactor()  0)  // assume capacity for 10 people with regular weight
                                    //    delete wishListUp[floorNum];  // mark as visited
                                    this.destinationQueue.unshift(floorNum);  // add as immediate next destination
                                    this.checkDestinationQueue();  // announce modification
                                }
                                break;
                            case -1: // going down
                                if (wishListDown[floorNum])  // are people waiting to go down from here?
                                {
                                    //if ((1.0 - this.loadFactor()) * 10.0 - wishListDown[floorNum] > 0)  // assume capacity for 10 people with regular weight
                                    //    delete wishListDown[floorNum];  // mark as visited
                                    this.destinationQueue.unshift(floorNum);  // add as immediate next destination
                                    this.checkDestinationQueue();  // announce modification
                                }
                                break;
                            case 0:  // final destination
                            default: 
                                break; 
                        }
                    }
                }); 

                elevator.on("stopped_at_floor", function(floorNum)  // one destination reached
                {
                    processWishList(); 
                    updateIndicators(this);  // next direction
                });
            }

            for (var i = 0, l = floors.length; i 

Re: Elevator Saga – An elevator programming game

#88
post #84

Developer here! Thanks for all the feedback. Appreciate all of it, including bug reports! Pull requests also welcome. Especially I would appreciate help with adding more challenges, and/or making them all balanced and interesting, for a good and reasonable difficulty curve. It is very simple to tweak them - they are defined at the bottom of challenges.js: https://github.com/magwo/elevatorsaga/blob/master/challenges..…

What I would've loved to have seen in some of the later levels is a very clear "you now need to use this new API call to accomplish the goal. Here's how that call works."

For example: in level 2, what if people only ever came to the second floor trying to go to the third floor, so you had to look at where buttons were being pushed and where they wanted to go?

Re: Elevator Saga – An elevator programming game

#90
post #54

Earlier quoted context omitted.

I believe some people really need think in term of comparations and, for those, adding a "==" symbol make sense, even if the resultant code doesn't make any sense at all!! Also, I can never understand why people write .. if (foo()) { return true; } else { return false; } .. or things like extra parens on conditionals, or weird styles like: return (false); I strongly believe people write as they talk, and talk as they…

Many languages are expressions (as opposed to statements) including C-like languages. I've always thought that 'return' itself was redundant. If a compound statement was defined to return the value of the final (executed) statement, then functional methods would get much simpler. And remove the need for the '?' operator for instance. e.g. int foo(int x) { bar(x,y); } or x = {if (foo() > 9) true; else false; }

I think one problem with statements-as-expression is that is not always evident which should be their result.

for instance:

    bool r = if (test()) {
      false;
    } else {
      true;
    }
what r should be set to? true or false?

I don't see the point of adding such complexity.. it's waaay more clear to be explicit

    bool r = test();
    if (r) {
      false;
    } else {
      true;
    }
or, if you intended the other way

    bool r;
    if (test()) {
      r = false;
    } else {
      r = true;
    }
I guess that's why you need to be strictly correct, or highly opinionated, to design a language.
Post reply on HN