[OSX] AcChen - Arcade Automaten Clone von Match-It ( Finde das passende Teil Spiel )

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • [OSX] AcChen - Arcade Automaten Clone von Match-It ( Finde das passende Teil Spiel )

    Moin moin,

    seit gestern ist AcChen für OSX im Appstore verfügbar - optisch ähnelt es Mahjong, spielt sich aber komplett anders. Die einzelnen Levels lassen sich recht schnell 'erledigen' sodass AcChen ideal für zwischendurch ist - etwas mehr 'Arcade-like' eben...

    Das erste mal habe ich das Spielprinziep bei dem Arcade-Automaten 'Match-It' gesehen ( hab den Automaten mit diversen Mark-Stücken gefütternt :D ) . Ich habe das Konzept auf drei Ebenen erweitert und noch einige Extras eingebaut.

    Die erste Version haben wir vor Unzeiten mit einem kleinen Team für den Atari ST und Amiga geschrieben. Danach habe ich eine Version für den NeXT, Nintendo DS und das iPhone/iPad fabriziert. Nun hat der 'Dino' den Weg auf den Mac gefunden :)

    Screenshot:
    [Blockierte Grafik: http://miscstuff.de/wp-content/uploads/2010/08/sc1.png]

    Link zum Appstore:
    itunes.apple.com/de/app/acchen/id808339969?mt=12

    Hier sind einige Promo-Codes:
    46NXNM6KA4P7
    LJR7JK6XMFAE
    FKWYFKLFATXA
    4NPHKFNMT6EK
    E9KPM3MFMLFP

    Viel Spaß beim Spielen...
    Stefan
  • Habs jetzt 5 min angespielt und 2 sachen sind mir aufgefallen:

    1. ich versteh nicht warum manche (komplett von anderen eingeschlossene) paare aufgelöst werden können, andere jedoch nicht (welche regel steckt dahinter?)

    2. mir fehlt die pause-funktion. vor allem weil es ja ein spiel für zwischendurch ist, schaltet man schnell mal ins mailprogramm rüber um eine angekommene mail zu lesen/beantworten oder schnell auf eine nachricht im messenger zu antworten. optimal wäre also wenn die app automatisch in den pausenmodus gehen würde wenn sie inaktiv wird. falls es gegen das spielprinzip ist, dass dann weiterhin die paare angeschaut und zusammengesucht werden können, kann man diese ja gerne ausblenden oder irgendwas "drüberlegen" ;)

    ich werds mir abends oder so nochmals anschauen (läuft hier auf dem produktionsrechner mit 10.6 ja nicht)
  • Danke erstmal für das Ausprobieren :thumbup:

    gritsch schrieb:


    1. ich versteh nicht warum manche (komplett von anderen eingeschlossene) paare aufgelöst werden können, andere jedoch nicht (welche regel steckt dahinter?)

    Das klappt entweder wenn die zwei Steine mit gleichem Symbol direkt nebeneinander liegen, oder wenn die beiden Steine auf unterschiedlichen Ebenen liegen. Wenn man Steine von unterschiedlichen Ebenen kombiniert, wird immer die Ebene als 'Weg-Such-Ebene' benutzt in der der oberste ausgewählte Stein liegt ( drittes Bild im Help-Screen ). Eine weitere Möglichkeit wäre ein Bug von dem ich nix weiss :rolleyes:

    gritsch schrieb:


    optimal wäre also wenn die app automatisch in den pausenmodus gehen würde wenn sie inaktiv wird. falls es gegen das spielprinzip ist, dass dann weiterhin die paare angeschaut und zusammengesucht werden können, kann man diese ja gerne ausblenden oder irgendwas "drüberlegen" ;)

    Jup - stimmt das wär ne gute Sache. Bau ich in das nächste Update ein.
  • Das Problem mit den eingeschlossenen ist mir auch aufgefallen.
    Wenn ein Spielstein komplett eingeschlossen ist, daneben einer auf einer höheren Ebene liegt kann der eingeschlossene entfernt werden wenn man ihn mit einem aus einer höheren Ebene verbindet.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • Chris schrieb:

    Das Problem mit den eingeschlossenen ist mir auch aufgefallen.
    Wenn ein Spielstein komplett eingeschlossen ist, daneben einer auf einer höheren Ebene liegt kann der eingeschlossene entfernt werden wenn man ihn mit einem aus einer höheren Ebene verbindet.
    Chris


    Genauso ist es auch 'gewollt'. Der Stein aus der unteren Ebene wird für den Suchalgorithmus zu einem Stein aus der oberen Ebene.
    Ansonsten müsste man die unteren Ebenen erst freischaufeln bevor man Steine von verschiedenen Ebenen kombinieren könnte. Wäre sicher auch möglich - könnte man mal testen :)
  • MCDan schrieb:

    Sehr schön gemacht und man muss aufpassen, dass man nicht stundenlang spielt. :)

    Sind die Steine einzelne Views oder verwendest Du Sprite Kit?


    Freut mich, wenn es gefällt :)

    Die Ausgabe wird in einen openGL View gerendert - mit mehr oder weniger nur einer 'drawSprite' Funktion. Die Engine ist in C++ geschrieben... Also kein SpriteKit
  • Kay schrieb:

    Eigentlich sollte das gelöscht werden. Das ist kein Werbeforum für Apps. Wenn Du über eine App schreibst, solltest Du auch auf die Entwicklung eingehen.

    8|

    Die Links im OP enthalten etwas Hintergrund zur der Entwicklung des Projektes und natürlich beantworte ich gerne Fragen dazu, möchte da aber ungerne ungefragt langweilen ;). Persönlich finde ich dieses 'Unterforum' sehr interessant, da man sieht was die Entwicklerkollegen so produzieren.

    <ot>
    Zum 'Werbevorwurf':
    Ich sehe keinen substanziellen Unterschied zwischen meinem Posting und den Anderen in dieser Forums-Kategorie.
    'Werbung' impliziert u.A. eine Gewinnabsicht/Förderung und sorry, dazu ist ein Entwicklerforum für ein sehr spezielles Produkt nicht das geeignete Mittel. Wenn man die Zeit für das Posting berücksichtigt, 'arbeitet man rückwärts' wenn man das wirtschaftlich sehen wollte. Die Hoffnung, dass diese Art der App Entwicklung irgendwie wirtschaftlich ist, habe ich lange zu den Akten gelegt - ist nur ein Hobby/Ausgleichssport für mich. ;)
    </ot>
  • preussie schrieb:

    Die Ausgabe wird in einen openGL View gerendert - mit mehr oder weniger nur einer 'drawSprite' Funktion. Die Engine ist in C++ geschrieben... Also kein SpriteKit

    Hui, Diskussionsstoff. =)

    OpenGL ist ja durchaus schön und auch ein verständlicher Weg zur Umsetzung. Aber warum gerade C++?
    Liegt das darin begründet, dass die alten Atari Sourcen nur in C++ vorlagen und Du keine Lust hattest es umzuschreiben?
    Oder bist Du ein C++ Verfechter der alten Schule und siehst es überhaupt nicht ein Dich umzugewöhnen?
    Haben vielleicht diverse Tests ergeben, dass es so wesentlich schneller geht als mit Objective-C?

    Mich persönlich interessiert brennend, warum Du bei der Umsetzung vom De-Facto-Standard Objective-C abgewichen bist.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • preussie schrieb:

    Die Ausgabe wird in einen openGL View gerendert - mit mehr oder weniger nur einer 'drawSprite' Funktion. Die Engine ist in C++ geschrieben... Also kein SpriteKit

    Marco Feltmann schrieb:

    Hui, Diskussionsstoff. =)

    :D

    Marco Feltmann schrieb:

    OpenGL ist ja durchaus schön und auch ein verständlicher Weg zur Umsetzung. Aber warum gerade C++?
    Liegt das darin begründet, dass die alten Atari Sourcen nur in C++ vorlagen und Du keine Lust hattest es umzuschreiben?

    Ja so ähnlich. Die Atari Version ist in 68k Assembler geschrieben. Damals ging es nicht anders, wenn man ordentliche Framerates schaffen wollte. :whistling:
    Die NeXT Version war tatsächlich in ObjC geschrieben ( Ausgabe mit NSImage ) - allerdings nicht sehr gut. Leider sind die Sourcen im Daten-Nirvana gelandet :(

    Die C/C++ Version ist mit der Nintendo DS Umsetzung entstanden. Da habe ich mir einen ( möglichst ) wiederverwendbaren Framework gebastelt. Mit dem Homebrew Kit der DS kommt der gcc mit, da ist es dann C/C++ geworden. Es hat sich herausgestellt, dass es für die Portierbarkeit eine gute Wahl war... :D

    Marco Feltmann schrieb:

    Oder bist Du ein C++ Verfechter der alten Schule und siehst es überhaupt nicht ein Dich umzugewöhnen?

    Nee so garnicht, ich versuche die Sprache zu benutzen, die mir für den jeweiligen Zweick am Besten erscheint. C/C++ war in diesem Fall 'nur' historisch bedingt.

    Marco Feltmann schrieb:

    Haben vielleicht diverse Tests ergeben, dass es so wesentlich schneller geht als mit Objective-C?

    Ich glaube die Performance spielt in den meissten Fällen bei den heutigen 'Höllenmaschinen' keine wesentliche Rolle und wenn man *wirklich* Performance braucht, muss man IMO u.A. dynamische Speicherverwaltung minimieren - und das ist ObjC nicht grad der King denke ich...