Skapa en strategi från grunden - en detaljerad guide. Smart eller dum klient? Skapa en turbaserad strategi

nöjespark:
Jag kommer att behöva:
bygga sprite
sprite-menyn
SPRITES AV OLIKA KNAPPAR SOM:
skriv med inskriptionen (konstruktion, konstruktion, bygg, etc.)
ett fönster som visas
byggnadsritning,
1) vi lägger till resten själva
2) ordet förfalskning - skapat av mig själv, eftersom vi måste fejka det för att matcha vår källa)
IILlåt oss komma igång:
1) skapa allt som är skrivet i punkt I utom 1)
Låt oss skapa en global variabel som kallas pengar, ställ in valfri initial summa pengar
Vi kommer också att skapa ett mus- och tangentbordsobjekt
Låt oss skapa en text, kalla den info, skapa en alltid-händelse och skapa en åtgärd i den:
välj info i åtgärdsval välj ställ in text i texten skriv detta:
"pengar: " &(global("pengar".
2) lägg till en meny, huvuduppgiften för menyn är inte att störa, utan att hjälpa spelaren att navigera (hur kan det störa? - det är lätt om du placerar det mitt i spelet); innan vi gör menyn, kommer att skapa ett nytt lager, som vi kallar meny, i dess proportioner (inställningar, alternativ) i visningsobjektet skriver vi:


vi kommer att lägga till en sprite i den och ta bilden av menyn som fanns i förproduktionsmaterialet (punkt I) och placera vår meny på en avskild plats där den inte kommer att störa, utan kommer att synas på skärmen
Låt oss också placera en knapp gjord av förbearbetningsmaterial (punkt I) med inskriptionen BUILD (eller något liknande)
låt oss sätta det på menyn
Gå nu till Event Sheet Editor
skapa en händelse (#blah blah blah# - detta är mitt meddelande (förklaring) till dig bara istället för blah blah blah kommer det att finnas min kommentar till dig; >> - action; ll - division av fönster till exempel:

mus&tangentbord ll på objekt klickade ll vänsterklickade till objekt #din menyknapp med inskriptionen BYGGA (eller något liknande)##resten senare (se punkt 3)#
3)nu den svåraste delen(Jag delade upp det här i två punkter så att det inte skulle vara så komplicerat),
skapa en sprite från förbearbetningsmaterial "ett fönster som kommer att dyka upp"
sedan skapar vi en tom sprite som heter p1, flyttar fönstret från skärmen och sätter p1 på den plats där ditt fönster ska visas när du trycker på byggknappen (eller något liknande CHVER)
bra! Gå nu till redigeraren för eventblad
Låt oss skriva ner den oavslutade händelsen till slutet:
Text ll set text ll bla-bla-bla)
mus&tangentbord ll på objekt klickade ll vänsterklickade till objekt #din menyknapp märkt BYGG (eller något liknande)#>>
4)Den andra delen av den svåraste delen:
låt oss skapa en sprite där bilden av byggnaden (förbearbetningsmaterial) kommer att ritas, låt oss kalla det h1
låt oss skapa en tom sprite, kalla den p2, placera den nu på den plats där fönstret ska öppnas,
Låt oss skapa en sprite, också ett fönster (förbearbetningsmaterial), i fönstret skriver vi vackert namnet på byggnaden, dess kostnad och beskrivning (valfritt) och kallar det i1
låt oss skapa en annan tom sprite som heter p3, placera den bredvid p2, bara så att den bara vidrör p2 med det övre vänstra hörnet
Låt oss nu skapa flera händelser, men först gör vi den föregående händelsen till en ny åtgärd:
mus&tangentbord ll på objekt klickade ll vänsterklickade för att objekt #knappen på din meny med inskriptionen BUILD (eller något liknande)#>> system ll skapa objekt relativt objekt ll #ditt fönster# #lagernummer under namnmenyn# # X ;Y-ändra inte# till objekt p1
>>system ll skapa objekt relativt objekt ll #ditt andra fönster# #lagernummer under namnmenyn# #X;Y-ändra inte# till objekt p2
Vi måste också göra en händelse tillbaka till honom:
kopiera händelsen och invertera den
nytt event
mus&tangentbord ll är över objekt ll h1>>system ll skapa objekt till relativt objekt ll i1 #lagernummer under namnmenyn# #X;Y-ändra inte# till objekt p3
Låt oss göra en sprite med en byggnad (använd förproduktionsmaterial) och kalla det hus
Låt oss skapa ett fönster där våra byggnader kommer att dyka upp när de väljs i menyn, kalla det rlo
evenemang:
mus&tangentbord ll på objekt klickade ll vänsterklickade till h1>>system ll skapa till objekt relativt objekt ll hus #lagernummer under namnmenyn# #X;Y-ändra inte# till objekt rlo
>> systemet kommer att subtrahera från värdet ll #summa pengar som bör tas bort under konstruktionen#
Nu var det omöjligt att bygga upp ett event
Jag ska berätta om min tidigare metod för förbud (när jag är klar med att skriva kommer jag att utforska en annan metod som gjorde mig blå när jag kom ihåg spelets temaparksvärld)
evenemang:
hus ll vid kollision med ett annat föremål ll till hus
>>hus kommer att förstöra
>> system ll subtrahera från värde ll - #dubbla summan pengar som togs bort under konstruktionen##notera att du måste ange - kvantitet#
i princip allt.
III vad jag vill säga:

Jag var väldigt upprörd över kollapsen av mitt spel. Det var ett strategispel, och den här artikeln sammanställdes enligt dess schema. Jag ber dig att inte kritisera för mycket, jag skrev länge, om du hittar talfel, skriv och rätta till dem
och här är även källkoden för ditt tittarglädje, titta, i princip är allt detsamma som det står här, bara detta var en demoversion av spelet. Huvudsaken är att inte ändra någonting, annars blir det buggigt !
använd det, experimentera, kolla det, gör vad du vill, det är okej för mig

KaMiKaZa:
Alla "system"-uttryck måste inkluderas i "Code"-taggen.
Då tror jag att det blir bättre.
Dessutom verkar det som om skärmdumpar inte skulle skada här. Och även källkoden, för nybörjare.

nöjespark:
Jag vet inte hur man tar skärmdumpar av händelser.

Tja, det är inte nödvändigt.

iamnp:
theme_park , det finns en speciell knapp på tangentbordet - PrintScreen

nöjespark:
Jag vet att vissa människor bara gör det annorlunda. Dessutom har alla sin egen sprite
och om jag sätter upp alla dessa sprites kommer få människor att förstå.
Nåväl, kanske någon ger ett plus? Inte konstigt att jag kämpade?

burlachenko:
För att en sådan lektion ska vara av intresse för någon måste den formateras därefter, men här "var det i alla fall."
Och ändå, om du vill, lite i taget, när du har tid, snälla "försköna" det.

nöjespark:
ok, jag kommer hem från skolan och gör mig i ordning.
PS. tillagd källa

Serega Lebedev:

iamnp, vart tar dessa skärmdumpar vägen senare?

KaMiKaZa:

Till klippbordet.
Gå till någon textredigerare, och utför åtgärden "Klistra in", eller tryck på Ctrl+V.

I den här artikeln kommer jag sannolikt inte att beröra något okänt. Alla beräkningar är enkla och begripliga för alla som vet vad Ajax är. Jag har redan skrivit en artikel om hur man kombinerar en klient med en server i realtidsspel (). I den här artikeln tar jag upp samma problem som de gäller för turbaserade spel.

Så vad är det turbaserat spel? Följande definition finns på Wikipedia turbaserad strategi - är en genre av dataspel vars huvuddrag är att spelare turas om att göra rörelser, till skillnad från realtidsstrategi. Jag skulle förenkla denna definition lite:

• Steg-för-steg-strategi - är ett turbaserat strategispel.
• Strategispel - Detta är en spelgenre där nyckeln till att uppnå seger är planering och strategiskt tänkande..
• Turbaserat spel - är en spelgenre vars huvuddrag är att spelarna turas om att göra drag.

Turn-baserade spel inkluderar:

• Turbaserade strategier
• Kortspel
• Brädspel (schack, go, monopol, etc.)

Jag noterar att turbaserade spel lägger färre begränsningar på interaktionsprotokollets komplexitet jämfört med realtidsspel. Nämligen, reaktionstid på en viss händelse spelar ingen nyckelroll. Spelaren får vanligtvis 10 sekunder på sig att fatta ett beslut. Även om pingen är gigantisk, säg 3 sekunder, så har spelaren fortfarande 7 sekunder på sig att tänka. Dessutom kan pingen hoppa och hoppa, men vi bryr oss inte om detta alls (i realtidsspel dödar den här situationen praktiskt taget alla protokoll).

Vanligtvis (i 95 % av turbaserade spel) fattar exakt en spelare beslutet vid varje given tidpunkt. Följaktligen minskar antalet förfrågningar som vi måste svara på adekvat sätt.

När vi skapar ett protokoll kommer vi därför främst att fokusera på hur lätt det är att implementera och stödja det. Detta gör att vi kan tjäna mer på kortare tid.

Ovanstående resonemang bygger på 2-månadersutvecklingen av ett visst kortspel.

Smart eller dum klient?

Låt oss först bestämma hur "smarta" vår kund kan vara. Jag diskuterar om det är värt att duplicera applikationslogiken (spelreglerna) på klienten. Självklart måste servern vara smart för att förhindra eventuell hackning av applikationen. Men är det värt att lära kunden affärslogik?

Detta beror direkt på hur mycket hela mängden data om ditt spels tillstånd väger. Om denna mängd data är stor, tar lång tid att samla in på servern och överförs till klienten, är det vettigt att implementera en del av logiken på klienten för att avlasta servern. Till exempel, i Civilization är den använda minnesmätaren alltid utanför sjökorten. Kan du skapa något liknande och bara lämna gränssnittet kvar på klienten?

Å andra sidan, ju smartare klienten är, desto dyrare blir spelutvecklingen. Låt mig notera att serverns utvecklingstid inte på något sätt beror på klientens kunskap. Även om klienten är super-duper-mega smart, om användaren vill ladda om webbläsarfönstret, måste servern samla in och samla all data om spelet för att överföra den till klienten. A la "Laddar ett sparat spel". Slutsats: En smart klient kan snabba upp en applikation, men det kommer alltid att kräva ytterligare resurser för att utveckla applikationen.

Jag föreslår följande testa:

1. Tillåter kanalvolymen?

Uppskatta medelvikten för hela mängden spelstatusdata. Multiplicera sedan med det genomsnittliga antalet förfrågningar till servern per sekund. Om det resulterande antalet överskrider den utgående datakanalens kapacitet, är den dumma klienten oacceptabel. Om denna siffra överstiger 20% av den utgående kanalen, så bör du fundera på om det kommer att fungera?

2. Är det arbetsintensivt?

Uppskatta komplexiteten i spelets datainsamlingsalgoritm (i bråkdelar av en sekund). Ta här hänsyn till alla frågor till databasen. Multiplicera sedan med det genomsnittliga antalet förfrågningar till servern per sekund. Om tiden överstiger en sekund är en dum klient oacceptabel. Om detta antal överstiger 200 ms, så bör du fundera på om det kommer att hålla?

Fortsättning:

Hej alla! Nu ska jag berätta hur man gör en enkel RTS (RTS - Real Time Strategy, det vill säga en realtidsstrategi) öppnar en hängmatta 8.1 (operabilitet garanteras inte på 8.0) skapar ett objControl-objekt, det vill säga detta kommer att vara vårt huvudobjekt, skapa en skapande händelse ( Skapa) Lägg till händelse => Skapande (Lägg till händelse => Skapa) skapande händelsen görs endast en gång - när du skapar, klicka på kontrollfliken till höger vertikal meny och högerklicka på Execute code och skriv koden (det är bäst att inte kopiera koden, men att skriva den själv, det är mycket lättare att komma ihåg):

200?"200px":""+(this.scrollHeight+5)+"px");">startx=0; //Deklarera en variabel för startpunkten för x
starty=0; //Deklarera en variabel för början av punkten med y
draw_rect=falskt; //Rita inte en markeringsrektangel

Variabel: En bit minne som innehåller information. De har ett eget namn som du kan kontakta dem med. Variabler i GML kan innehålla ett reellt tal eller en sträng. Till exempel är ett bord en variabel, trä eller glas är ett värde
Nu skapar vi en steghändelse (Step, Add Event => Step) och utför operationen igen (högerklicka på Execute code):

200?"200px":""+(this.scrollHeight+5)+"px");">
if mouse_check_button_pressed(mb_left) //Om LMB trycks ned
{
draw_rect=sant; //Vi ritar en rektangel
startx=mus_x; //Start x position = mus x position
starty=mus_y; //Startposition = musposition
med alla valda=false; //Detta är ännu inte en deklarerad variabel, vi kommer att ta reda på vad den kommer att göra senare
}

Om mouse_check_button_released(mb_left) //Om LMB släpps
{
draw_rect=falskt; //Vi ritar inte en rektangel
för(i=0;i<=instance_number(par);i+=1) //Читайте про цикл for ниже
{
ii=instance_find(par,i); //Vi letar efter ett föremål som ännu inte är tillverkat
if(collision_rectangle(startx,starty,mouse_x,mouse_y,ii,true,false)) //Här är vår kollisionsrektangel (kontakt)
{
ii.selected=true;
}
}
}

Koden är stor och komplex medan vi lär oss om villkorssatsen if:
Koden med if exekveras så här:

200?"200px":""+(this.scrollHeight+5)+"px");">
om (skick)
{
handling
}

Den kan också innehålla en else-sats (annars), till exempel:

200?"200px":""+(this.scrollHeight+5)+"px");">if (skick)
{
handling
}
annan
{
åtgärd 2
}

Och för är en loopoperator, exekveras den så här:

200?"200px":""+(this.scrollHeight+5)+"px");">
för (<переменная> ; <выражение> ;<действие переменной>)
{
<действия>
}

For-operatören är en mycket kraftfull sak, den hjälper mycket i svåra situationer

Operatör - åtgärder inbyggda i språket, till exempel, de vanligaste är int, if, else, string, switch, for, case, break, exit, etc., etc., etc.

Nu skapar vi även en rithändelse (draw) och skriver på samma sätt:

200?"200px":""+(this.scrollHeight+5)+"px");">if draw_rect=true
{
alfa=0,8;
draw_rectangle_color(startx,starty,mouse_x,mouse_y,c_green,c_green,c_green,c_green,true);
}

Allt är enkelt här, här är samma sak bara på ryska:
om vi behöver rita en rektangel, väljer vi genomskinlighet och ritar en rektangel
här är argumenten

200?"200px":""+(this.scrollHeight+5)+"px");">draw_rectangle_color(x1,y1,x2,y2,färg 1, färg 2, färg 3, färg 4, kontur)

kontur - om bara kanten (sant) eller den fyllda rektangeln (falsk) kommer att ritas
Vi hittade ett nytt ord - konstant, detta är ett numeriskt uttryck eller kod som ersatts av ett ord, hängmattan har inbyggda konstanter:

200?"200px":""+(this.scrollHeight+5)+"px");">sant - 1
falskt - 0
pi - 3,1415...

Tja, vi kom på det, nu måste vi skapa ett nytt objekt - ett överordnat objekt som kommer att ansluta till sina barn. Låt oss kalla det par (för att ändra namnet måste du ändra koden i kontrollobjektets steghändelse), skriv i skapandehändelsen:

200?"200px":""+(this.scrollHeight+5)+"px");">selected=false; //Här är vår variabel, om objektet är valt

Detta är allt. Nu behöver vi förstås ett objekt som kan röra sig, vi kallar det objTest, och skriver koden i skapelsehändelsen:

200?"200px":""+(this.scrollHeight+5)+"px");">gox=x; //Vart ska man gå...
goy=y; //av y
vald=falskt; //Vi är inte utvalda =)
object_set_parent(self,par) //Här är valet av förälder

Ny åtgärd:

200?"200px":""+(this.scrollHeight+5)+"px");">object_set_parent(ind,obj)

Ställer in det överordnade objektet till objektet med namnet ind.
Och en ny operatör: själv, det betyder att handlingen kommer att gå till sig själv
Var inte rädd, det finns fortfarande lite kvar i stegeventet:

200?"200px":""+(this.scrollHeight+5)+"px");">om avstånd_till_punkt(gox,goy) > 20
{
mp_potential_step(gox,goy,6,solid);
}
if(selected=true) && mouse_check_button_pressed(mb_right)
{
gox=mus_x;
goy=mus_y;

Utformning av strategi
Du kan inte lita på amatörer:
deras planer kan oväntat fungera,
och ingen är redo för detta.

(A. Cuningham)

I de två tidigare numren lärde vi oss göra enkla 2D-spel, kontrollera sprites, rulla spelskärmen, spåra kollisioner av spelobjekt, bygg ett gränssnitt (knappar, mus, tangentbord, textområden) och arbeta i helskärmsläge och fönsterläge. Allt detta gjordes med ett arkadspel som exempel.

Den här gången kommer vi att gå från arkadspel till en mer "seriös" genre - strategier. Här kommer vi att behöva bemästra en hel rad nya mekanismer, men det blir inget komplicerat här heller. I denna artikel har vi Låt oss studera strukturen för en turbaserad strategi(och även realtidsstrategi- det är ännu enklare att göra det med LKI-Creator) och vi kommer att göra ett spel som ett exempel, men designat endast för flera användare läge (och även kartredigerare för henne). Vi kommer att ta itu med enspelarläget i nästa nummer av vår kolumn - tillägnad grunderna i artificiell intelligens.

Eftersom detta redan är den tredje lektionen går vi inte in på detaljer Allt exempelkod - lyckligtvis har mycket gjorts på exakt samma sätt som de två tidigare gångerna. Som referens finns det ett exempelprogram (det finns många kommentarer i det) och tidigare artiklar.

Tja, du kan hitta materialet från våra tidigare klasser på vår CD, i avsnittet "Gör det själv" speciellt skapat för detta ändamål.

Formulering av problemet

Låt oss skriva ett strategispel som består av en strid mellan två fantasiarméer. Målet med striden är att fånga flera obelisker, placerad på kartan. Innan striden sätter vi in ​​våra trupper, bestående av 6 svärdsmän, 4 bågskyttar, 2 riddare, 2 magiker och 1 spöke, inom det territorium som tilldelats oss. Utöver dem finns det neutrala på kartan drakar.

Egenskaper för fighters
Kämpe	Rörelse	Träffar	Räckvidd	Skada	Skydd	Förmågor
Fäktare	4	8	1	7	2	-
Archer	4	5	7	5	1	-
Riddare	3	15	1	9	4	Healing, Knight's Strike
magiker	3	12	5	6	0	Eldboll
Spöke	4	7	2	5	5	Regeneration
Draken	6	30	2	12	5	Flyg

Fighters egenskaper presenteras i tabellen. Behandling- detta är rätten att hela en närliggande krigare (förutom ett spöke) till full hälsa en gång per strid. Knight's Strike- Rätten att tillfoga trippel skada en gång per match. Eldboll- trollkarlens attack tar bort träffpunkter inte bara från det omedelbara målet, utan också från omgivande rutor. Regeneration- återhämtning av 1 träff per varv. Flyg- rätten att förflytta sig över hinder.

Spelet spelas i multiplayer-läge, i Hot Seat-versionen (spela från en dator, fyller en i taget). Efter att spelarna vänder sig gör neutrala drakar sin tur och attackerar alla fiender inom en radie av 7 celler.

Festen slutar när den ena sidan antingen fångar mer än hälften av obelisken som finns på kartan eller dör helt.

Kartan sattes från början i kartredigeraren. Det finns obelisker, drakar och hinder (föremål genom vilka du inte kan röra dig eller attackera).

Förbereder för arbete

Innan vi börjar måste vi installera om paketet LKI-Creator. Faktum är att det har gjorts många ändringar och tillägg jämfört med förra gången.

(Jag hoppas det Delphi du redan har installerat; Om inte, läs sedan rekommendationer om detta ämne i vår tidigare artikel - i juninumret av tidningen eller på CD:n till detta nummer eller på webbplatsen.)

Det är viktigt: den tidigare versionen av LKI-Creator hade vissa kompatibilitetsproblem med nya versioner av Delphi. I denna version är de eliminerade.

Ta filen med programtexter och bilder från vår CD (avsnittet "Spel med egna händer") och packa upp den i projektkatalogen.

Nu kan du ladda ner nödvändiga filer härifrån .

Vi borde ha tre underkataloger. One - Units - lagrar DirectX-bibliotek och moduler i LKI-Creator-paketet. I ett annat - Projekt - kommer vi att arbeta; bilderna som vi kommer att behöva placeras där i förväg, och föregående version vår arkad. I det tredje - Escort - ett färdigt program som vi ska lyckas med.

Låt oss nu installera (ominstallera) LKI-Creator. I Delphi-menyn, öppna objektet Komponent och välj Installera komponent. Om du redan har installerat detta paket, stanna kvar på Into exist package-fliken, annars gå till Into new package-fliken och fyll i de tomma raderna som visas i figuren (i den översta raden är det enklaste sättet att välja LKI2dEngine. pas-fil med hjälp av Bläddra-knappen, och skriv ner LKI längst ned. Klicka sedan på OK och välj Installera. Du bör nu se LKI-fliken i Delphis topppanel.

Nu återstår bara att ladda upp vårt projekt. I Arkiv-menyn, välj Öppna, öppna filen Project\Obelisk.dpr...

Var är kartan, Billy? Vi behöver en karta!

Men innan vi kommer in på de stora sakerna måste vi arbeta lite mer med grafikmotorn.

I Star Escort, vårt tidigare projekt, hade "kartan" ingen betydelse: stjärnorna placerades slumpmässigt och påverkade ingenting, och positionen för andra objekt specificerades antingen direkt i koden eller bestämdes av en slump. Detta är inte lämpligt för alla projekt. Det betyder att det är dags för oss att lägga till vår motor områdeskarta.

Du kan säkert redan gissa hur det kommer att se ut - vi lägger ett kartobjekt i projektfönstret och registrerar det sedan i fastigheten Karta vår motor.

Det är så det är... men vi har mer än en kortklass. Låt oss ta en närmare titt...

Typer av kort

Kartan består av något landskap Och föremål installerad på den. Landskapet är oftast (men inte alltid) indelat i celler som kallas kakel- kakel.

Som vi vet från en skolgeometrikurs kan ett plan täckas utan luckor eller överlappar med regelbundna polygoner av tre typer: triangel (liksidig), kvadratisk, hexagon. Triangulära fält är inte särskilt bekväma, så kvadratiska celler eller hexagoner används oftare.

På sätt och vis är det lättare att leva med kvadrater: om vi har en tvådimensionell uppsättning celler är det omedelbart klart hur man hittar cellerna intill en given cell. Dessa är +1 och -1 för vart och ett av de två indexen. Med hexagoner är allt lite mer komplicerat... men den hexagonala brädan har en mycket värdefull egenskap: alla riktningar i den är desamma. Detta är inte fallet med ett kvadratiskt rutnät: diagonalerna skiljer sig väsentligt från de horisontella och vertikala. Därför, för seriösa strategiska beräkningar, kan hexagoner vara bättre än kvadrater.

Det finns också kort utan kakel. LKI-Creator stöder två typer: graf och lapptäcke.

En grafkarta är en karta där endast ett fåtal nyckelpunkter har betydelse, plus kanske speciella områden (till exempel oframkomliga), och resten är bara ett mönster som inte har någon speleffekt. Så här görs ofta stjärnkartor, som i till exempel Master of Orion: stjärnor och svarta hål är nyckelpunkter, resten är bakgrund. I det här läget gör de ibland globala kartor, till exempel för ett rollspel.

Lapptäckskartan är indelad i områden och inom området är alla punkter lika, du kan inte röra dig längs med "lapptäcket". Detta är bra för globala strategier, där en provins är den minsta territoriets enhet.

Exempel på kort från olika spel, som anger typen, finns på bilderna.

Majoriteten alltså tvådimensionell kartor (tredimensionella - en speciell artikel) kan delas in i fyra klasser:

• Rektangulär- TLKIRectMap. Detta är en sida vid sida, cellerna är kvadrater. En sådan karta, till exempel i Civilization III.
• Hexagonal- TLKIHexMap. Kaklad karta med hexagonala celler. Används i många krigsspel, och inte bara: detta är till exempel hur stridskartan Heroes of Might & Magic traditionellt gjordes.

  Dessa två typer av kort är ättlingar till den allmänna klassen TLKITileMap.

• Graphovaya- TLKIGraphMap. Detta kort har bakgrund (bakgrundsegenskap) och nyckelpunkterna som markeras på den är statiska objekt. Positionen för andra objekt på denna karta uttrycks antingen av vanliga koordinater (som ett rymdskepp i interstellärt rymden) eller genom referens till ett objekt (samma skepp i omloppsbana om en planet). Dessa är korten Master of Orion, Arcanum (global) och så vidare.
• Patchwork- TLKIClusterMap. Den har en bakgrundsegenskap, som grafen en, och en andra egenskap - mask, som avgör vilken punkt som hör till vilken region och fastigheten Gränser, som definierar kopplingarna mellan "bitarna". Så är kartor ordnade till exempel i Medieval: Total War eller Victoria.

Det är viktigt: kartklasser beskrivs inte i LKI2dEngine-modulen, utan i LKI2dMap.

Lutningsvinklar

Men om du tror att detta tar slut på LKI-Creators möjligheter att visa kartor, så har du mycket fel.

Kartan kan presenteras toppvy eller isometrisk- titta i en vinkel mot vertikalen. Till exempel är kartan över Civilization III eller Heroes of Might & Magic IV isometrisk, men Civilization I har en vy uppifrån och ned.

Vanligtvis används isometri för sida vid sida med kartor, medan grafkartor används med ovanifrån, eftersom skalan på grafkartor vanligtvis är mindre. Men det finns undantag: till exempel i Medieval: Total War finns en isometrisk lapptäckskarta.

Kartegenskapen ansvarar för isometricitet IsIsometrisk och två parametrar som ställer in vinkeln som vår kamera tittar på: Phi Och Theta.

Den första är ansvarig för kartans rotation i förhållande till den vertikala axeln: om du till exempel ställer in den på 45 grader (den mäts i grader), kommer den rektangulära rutnätscellen att vara orienterad med en uppåtgående vinkel, som i Civilization . Vid Phi=0 kommer en av sidorna av cellen att vara horisontell.

Den andra styr kamerans lutning i förhållande till vertikalen. För enkelhetens skull anges det som förhållandet mellan horisontella och vertikala längdenheter. Låt oss säga att om vi vill att vår cell ska dras hälften så hög som den är bred, måste vi ställa in Theta på 2.

Med en sida vid sida får vi inte välja dessa vinklar godtyckligt: ​​vi har trots allt inte (ännu) 3D. De beror direkt på brickornas parametrar. Till exempel, om vi har en rombformad axel med en uppåtgående vinkel och den vertikala axeln är hälften så stor som den horisontella axeln, måste vi ställa in parametrarna 45 och 2.

Men graf- och lapptäckskartor ger dig rätt att tilldela dessa parametrar som du vill (och till och med, om så önskas, ändra dem under processen), men du bör inte ryckas med detta - förutom att sådana svängar tar en mycket tid, de ser inte heller särskilt coola ut. Och glöm inte att om din karta är konstnärlig, med bilder, inskriptioner etc., så kommer de att vända med den... I allmänhet är det ibland lättare att rita en lapptäckskarta med hänsyn till den nödvändiga rotationen - lyckligtvis avstånd spelar ofta ingen roll där.

Fogar

Patchworkkarta, ovanifrån.

Kakelkartor har ett annat problem - brickfogning. Den styrs av parametern TileBorderStyle. Oftast detta kakelRak, ett läge där brickorna helt enkelt passar ihop utan några kanteffekter, eller tileBorder, där linjer ritas som skiljer en bricka från en annan - gränserna för cellerna (i det senare fallet, glöm inte att definiera Färg gitter i parameter TileBorderColor).

Men det finns ett mer listigt alternativ, när identiska brickor ligger intill varandra utan ändringar, och olika används med en speciell "övergångsbricka". Detta görs vanligtvis om kartan huvudsakligen består av vidsträckta områden av en typ av territorium, säg stora grönområden, och en enskild cell inte är viktig och bör inte uppmärksammas av spelaren. Detta är Heroes of Might Magic-kortet. Men om varje cell bearbetas separat, som i Civilization, är den här metoden inte lämplig, och det är bättre att tydligt separera cellerna från varandra. "Fused" teknologi (även kallad mask) anges av TileBorderStyle-värdet lika med tileMasked. Vi kommer att prata om deras struktur en annan gång - det här är ett ganska komplext ämne.

Bricka

Kartelement - klassobjekt TLKITile- har en enkel struktur. Den innehåller till en början: koordinater, en sprite som ritar den, en kod för bricktyp (som bestämmer vad vi har här - en kulle, en öken, en väg, ett hav?) och patency (detta är relevant i de flesta spel). Det senare är antalet flyttenheter det kostar att flytta över den brickan. landa trupp. För oframkomliga brickor är detta ett negativt tal.

En annan parameter - Föremål, en lista över objekt som finns på denna bricka (typ TLKIGameObject).

För att ta reda på vilken cell som klickades på har kartan en metod Musplatta(x,y) returnerar den valda brickan.

Kakel metoder inkluderar Är Granne(Kakel, Avstånd). Den här funktionen returnerar sant om brickan inte är mer än avståndsceller från den givna brickan (som standard är denna parameter lika med en, det vill säga om du bara skriver IsNeighbour(Tile), kommer funktionen att returnera sant för brickan omedelbart intill För ett kvadratiskt rutnät anses de brickor som gränsar diagonalt också som "grannar".

Funktioner FirstNeighbour Och Nästa granne används för att kontrollera alla celler som gränsar till en given. Den första av dem pekar på någon granncell, och den andra kan bara anropas efter att den första har ringts, och den ger ut nästa grannar, en i taget.

Uppräkning av grannar

// Att orsaka skada på en cell

procedur TObeliskTile.Damage(dmg: heltal);

om(Objekt.Antal > 0) och// Vi kanske har

// inte mer än ett objekt per cell

(Objekt.ID > 0) // Passiva föremål

// inte skadad

Dec(Objects.Hits,

// Dra automatiskt bort skydd från skador

Max(0,dmg-(Objekt som TObeliskGameObject).Försvar);

om Objects.Hitsthen Die; // Vi tar bort de döda

// Fireball attack

procedur TObeliskTile.Fireball;

var Granne: TObeliskTile;

Neighbor:= FirstNeighbour som TObeliskTile;

Neighbor.Damage(6);

Neighbor:= NextNeighbour som TObeliskTile;

fram tills Granne = noll; // Tills grannarna tar slut

Ett exempel finns i sidofältet "Räkna upp grannar". Denna procedur beräknar eldklotet som träffar en cell och alla dess grannar.

Det här är intressant: för hennes arbete det spelar ingen roll alls, vi har ett sexkantigt gitter eller ett kvadratiskt.

Ofta behöver vi några andra parametrar, och vanligtvis klassen av brickor som utgör kartan - ättling TLKITile. Så i exemplet - är TObeliskTile från TLKITile.

Det är viktigt: Om vi ​​tar med en sida vid sida till vår spelskärm, börjar koordinaterna, såväl som de avståndsrelaterade TLKIGameObject-metoderna, som standard att mäta avstånd i brickor istället för poäng. Koordinaterna för knappar, ikoner etc. fortsätt att mätas i pixlar! Men det här läget kan stängas av - det kan vara användbart för realtidsstrategier.

Att välja ett kort

Så låt oss börja med ett rektangulärt gitter (TLKIRectMap), en isometrisk mappning (vinkelparametrar 0, 1,5). Låt rutnätet ritas (tileBorder-stil). Låt oss tala om för motorn att just den här kartan ska visas. Hittills har alla nödvändiga åtgärder genomförts utan att skriva en enda kodrad.

Dessa operationer måste göras innan motorinitiering, samt teckensnittsdeklaration.

Vi kommer att deklarera figurerna, som tidigare, som sprites.

Kartredigerare

Patchworkkarta, isometrisk.

Det finns en del svårigheter här. Exakt samma motor, samma brickdeklarationer... Gränssnittet, som att välja en bricka, ladda/spara, etc., kan enkelt göras standardmedel Delphi: ingen tvingar oss att översätta det till fullskärmsläge. Vi kommer inte att analysera detta här - allt finns i exempelfilen. Exempelkoden användes medvetet det enklaste sättet; Om så önskas kan du till exempel göra objektpaletten och brickpaletten grafisk.

Redaktören har bara två funktioner som är obekanta för oss. Den första är ganska enkel: det är en ny musfunktion som är designad speciellt för kakelkartor. Fungera TLKIRectMap.SelectTile returnerar en pekare till den exakta brickan som klickades på, så att vi enkelt kan hantera klicket.

Men den andra nya produkten förtjänar mer noggrant övervägande.

Faktum är att det finns många sätt att spara data till och läsa data från den. Vi valde metoden kodad i filen CannonBase. Cannon är ett verktyg för att läsa och skriva efterkommande objekt TCannonObject med typkontroll och några andra funktioner.

Låt oss titta på koden ("Skriv kort").

Spela in ett kort procedur TObeliskMap.Save; var i,j: heltal; InitSave(FName); WriteStr(MapName); Write(Map.Width, SizeOf(Map.Width)); Write(Map.Height, SizeOf(Map.Height)); för i:=0 till Karta.Bredd-1 do för j:=0 till Karta.Höjd-1 do Write(Map.Tiles.Code, SizeOf(heltal);

Så här fungerar det. Först måste du öppna filen med en speciell procedur InitSave, vars enda parameter är filnamnet. Sedan sparar vi rubriken för typkontroll med en speciell procedur WriteHeader. Sedan skriver vi ner allt vi behöver med hjälp av proceduren WriteStr för strängar och för alla andra fält - Skriva(dess andra parameter är storleken på skrivna data i byte). Du kan skriva dina egna procedurer för objektfält efter behov Spara med en rubrikpost. Slutligen stänger vi filen med proceduren FinSave.

Alla objekt som har en egen rubrik måste deklareras separat. I kapitel Initialisering modul (valfritt avsnitt som kommer efter Genomförande, som innehåller kommandon som måste köras i början, när du startar programmet), bör du skriva följande rad, till exempel:

RegisterUserName(tpMap, "TObeliskMap");

TpMapär en konstant som du också måste deklarera. Jämställ det, säg, till 1. Och i konstruktorn för TObeliskMap-objektet, tilldela värdet på denna konstant till parametern TypID.

Varför allt detta tjafs? Förutom typmatchning får du en mycket viktig fördel.

Om filformatet ändras, till exempel på grund av att nya fält har lagts till, behöver du inte skriva några "konverterare" som konverterar de gamla filerna till nya. Din kod läser dem automatiskt.

Denna kod kommer automatiskt att initialisera det nya fältet som tomt om det inte sparas i filen. Och du kan skriva en fil genom att helt enkelt lägga till WriteStr(Name)-raden till slutet.

Kommentar: Om du fortfarande inte förstår vad den här processen är till för, oroa dig inte. Du kan använda mer konventionella inspelnings- och sparmetoder. Men i verkligt storskaliga spelprojekt ger denna väg betydande fördelar.

Låt oss spela

Först och främst måste vi skapa en ny klass härledd från TLKIGameObject. Vi kommer att sakna egenskaperna hos den gamla. I den nya klassen måste du lägga till fält för huvudegenskaperna: räckvidd, rörelse och så vidare.

Det är viktigt: Vår gamla hastighetsparameter finns kvar, men den indikerar hastigheten på pjäsen som rör sig över skärmen, och inte sträckan den kommer att färdas per varv. Om vi ​​skulle göra en realtidsstrategi skulle vi inte behöva en ny parameter, men annars måste vi införa den.

På vår skärm kommer vi att använda TLKIBnappknappar i form av bågskyttar, svärdsmän, magiker, spöken, riddare.

Först har vi arrangemanget. Låt oss definiera placeringszonen för en sida som de tre översta "linjerna" på kartan, för den andra - som de tre nedersta "linjerna".

Koden fungerar så här. När du trycker på någon av knapparna aktiveras installationen av motsvarande fighter; Genom att klicka på en ledig ruta i placeringsområdet placeras figuren där och knappen inaktiveras. Så snart alla knappar är inaktiverade överförs draget till fienden.

I början av varje nytt drag slås alla knappar på igen: detta görs så att det är lättare för en person att märka vem han ännu inte har likt. Följaktligen, genom att klicka på knappen väljs figuren, och så snart ett drag görs försvinner knappen. En annan knapp - "Avsluta sväng" - visas först efter placeringsfasen.

Förra gången gjorde vi redan operationer för att aktivera och inaktivera gränssnittselement, så vi kommer inte att analysera denna operation i detalj - titta på exempelkoden.

Flytta av figuren

// Om den valda cellen är ockuperad av fienden attackerar vi,

// om vi är lediga rör vi oss, om vi är upptagna med vårt eget

// eller ett hinder - ignorera klicket

Tile:= Map.MouseTile(MouseX, MouseY);

om(Kakel = noll)// Klicka utanför spelfönstret

sedan utgång;

// Rör på sig

om(Tile.Objects.Count = 0)

och(Dist (Själv)

och inte Rörd sedan

// Låt oss kolla om vi kan komma dit

om inte HasWay (Tegel) sedan utgång;

MoveObj(ID, Tile.x, Tile.y);

// Spelet är turbaserat - flytta omedelbart

Flyttade:= sant;

//

om Attackerad sedan

Icon.IsVisible:= falsk;

// Ge sig på

om(Tile.Objects.Count > 0)

och(Dist (Själv)

och inte Attackerad sedan

Obj:= Tile.Objects;

// Vi attackerar bara fiender

om Obj.Side = Side sedan utgång;

Obj.Damage(dmg);

Attackerad:= sant;

// Om flytten är klar, ta bort ikonen

om Rörd sedan

Icon.IsVisible:= falsk;

Flytten bearbetas enligt följande (se "Piece move"). Den klickade cellen finns. Om det finns en fiende på den, och de är inom räckhåll, skadas han; om den är tom och inom räckhåll rör sig pjäsen (om hinder tillåter); om den är ockuperad, men inte av en fiende, ignoreras klicket .

När båda sidor närmade sig agerade drakarna. De fungerar väldigt enkelt: de väljer den närmaste icke-draken som är inom 7 rutor från dem och attackerar. Se Dragon Actions-koden.

Drakeaktioner

// Kontrollera brickor inom 7 rutor från draken

för i:= Max(0, x - 7) till Min(MaxSize, x + 7) do

för j:= Max(0, y - 7) till Min(MaxSize, y + 7) do

if (Map.Tiles.Objects.Count > 0) och

(Map.Tiles.Objects.Code>1)

// 0 - hinderkod, 1 - drake

sedan Börja

// Välja en punkt att flytta

om x=i sedan ax:=i

annan om x>i sedan ax:=i+2

annan ax:= i-2;

om y=j sedan ja:= j

annan om y>j sedan ay:= j+2

annan ay:= j-2;

MoveObj(NEJ, ax, ay);

// Låt oss attackera

Map.Ties.Damage(12);

// Att bryta cykeln: inte mer än en attack

// varje drake per omgång

Slutligen återstår bara att kontrollera om mer än hälften av obeliskerne är ockuperade av trupper från ena sidan - och om de är det, stoppa spelet och utse vinnaren!

Så vi har ett strategispel. Men för fullständig lycka är det först och främst artificiell intelligens som saknas, vilket gör det möjligt att ge spelet ett enspelarläge (vi anser inte det enklaste förfarandet för att kontrollera drakar). Det är vad vi ska göra nästa gång. Vi ses om en månad!

I kommande nummer

I följande nummer kommer vi att prata om:

• partikelsystem för att visa rök, gnistor etc.;
• arbeta med transparens;
• tredimensionella motorer;
• AI grunderna;
• felsökning av programmet;
• skapa en spelplan och manus,
• skriva ett designdokument;
• spelbalans;
• tänka igenom spelkaraktärer och deras linjer;
• arbeta med Photoshop och 3D-paket;
• animationer;
• musik och röstskådespeleri;
• och mycket mer.

Det är fullt möjligt att lära sig hur man gör allt detta med egna händer. Du kommer snart att se detta.

Skriv till oss…

För den som tror att paketet kan kompletteras med något: för det första, glöm inte att det finns nr Slutversion paketet, men bara det som implementerar funktionerna som beskrivs i våra artiklar. Kanske har några av dina idéer redan implementerats och väntar på sin tur (se sidofältet "I framtida nummer"). Och i alla fall: när du ger oss en idé, försök motivera varför ditt förslag är användbart för många spel samtidigt, och inte bara för ditt specifika.

För självständigt arbete

I väntan på nästa nummer kan du arbeta med ditt eget projekt, eller så kan du försöka förbättra detta. Här är några idéer för din egen implementering:

• dela upp hinderföremål i förstörbara (träd och buskar) och oförstörbara (stenar), och se till att eldklot och drakens andedräkt bränner växtligheten;
• skapa gropar (brun cell) eller en brand som flammar i flera varv (röd cell) på den plats där brandattacken utlöstes;
• tillåt svärdsmän och riddare att täcka sina grannar, ge dem +1 till försvar;
• gör figurernas rörelser på skärmen smidig.

Vad händer om i realtid?

Det är inte svårare att göra ett strategispel i realtid om du bara ger spelarna olika inmatningsmedel. Det enklaste sättet att göra detta på är via nätverket - vi kommer att prata om detta i ett av de kommande numren. Följande ändringar kommer också att behövas:

• inget fält behövs Spelhastighet på klassen TObeliskObject- använd Speed ​​​​från basmotorn (hastigheten för rörelse över skärmen är lika med spelets hastighet);
• heltalsberäkning av avstånd är inaktiverad;
• figurens rörelsekod skrivs om, med hänsyn till det faktum att det är nödvändigt att rita en bana runt hinder;
• Knappen "slut på drag" tas bort.

Det är allt. Kommer du att försöka göra det själv?

Nuförtiden kan du enkelt hitta en hel del handelsstrategier, problemet är bara att de flesta antingen inte fungerar eller inte är tillräckligt effektiva. I en sådan situation är att skapa en strategi från början en utmärkt lösning på problemet.

Och även om skapandet av ett fordon i varje specifik situation kommer att vara annorlunda, förblir huvudstadierna desamma. Det vill säga, du kan skapa något som en universell guide, sekventiellt gå igenom alla stadier, och i slutet kommer vi att få ett helt fungerande system.

Även om vi kommer att överväga alternativet att skapa en strategi från grunden, börja med en idé och sluta med införandet av ett filter och den slutliga utvecklingen av fordonet, betyder det inte att alla färdiga system omedelbart ska kasseras som uppenbart ineffektiva . Ett antal TS kan användas som bas och helt enkelt lägga till några filter för att sålla bort falska signaler.

Huvudstadier för att skapa en strategi

Om du tar 5-7 indikatorer slumpmässigt och försöker skapa ett fungerande fordon från dem, är det osannolikt att något användbart kommer ut. Först måste du tänka igenom strategins huvudidé och först sedan gå vidare till att välja verktyg. Följande sekvens av åtgärder kan föreslås:

• om systemet skapas från grunden, då är det första steget att arbeta med idén. I detta skede behöver du bara bestämma vad din handelsstil kommer att vara, till exempel om transaktioner kommer att genomföras längs trenden eller mot den, eller kanske strategin är planerad uteslutande för breakout. Vi tänker inte på detaljerna ännu;
• Efter att ha valt lämplig handelsstil kan du börja räkna ut detaljerna. Innan du väljer instrument måste du tydligt bestämma fungerande valutapar och tidsramar, handelstid, etc.;

Viktig! När man väljer en tidsram är det inte tillrådligt att gå för lite, särskilt om handlaren inte har erfarenhet av spekulation på små tidsintervall. För nybörjare är det generellt sett bättre att inte gå under H1-H4, du kan läsa mer om att välja det optimala tidsintervallet.

• nästa steg är valet av lämpliga instrument, och här kan överflöd av valmöjligheter spela ett grymt skämt på handlaren, eftersom han har dussintals indikatorer till sitt förfogande, förmågan att använda ljusstake, våg, teknisk och fundamental analys. Från all denna variation måste du välja flera instrument som bäst passar din tänkta handelsstil;
• En av huvudreglerna för varje strategi är att den mottagna signalen måste bekräftas av flera filter, men det är tillrådligt att begränsa deras antal. Till exempel, för indikatorstrategier, är det oönskat att antalet indikatorer överstiger 3-4, annars kommer det att uppstå förvirring i signalerna, och om du planerar att arbeta med teknisk analys, kommer indikatorerna att spela en stödjande roll;
• regler för positionsstöd utvecklas, resultatet bör vara en algoritm av åtgärder för varje scenario;
• det sista steget är att köra fordonet först på ett historikkonto och sedan på ett demokonto, eller ännu bättre, på ett riktigt cent-konto. Huvudmålet är att testa strategins lönsamhet under verkliga förhållanden, och ett riktigt konto (även en cent) gör att du kan känna hela spektrumet av känslor, från eufori till förlusternas bitterhet.

Du kan också råda dig att inte hänga upp dig på fordonets komplexitet. Praxis visar att överdriven komplexitet inte alls är en indikator på effektivitet. Hur enklare system, desto lättare är det att handla.

Vad ska ingå i fordonet

Att skapa en strategi är lite som en byggsats, du behöver bara välja rätt delar. När du skapar ett fordon kan och bör du använda:

• indikatorer. Dessutom bör du inte jaga varken deras antal eller överdriven komplexitet; även i helt mekaniska fordon räcker 3-5 stycken;
• grafiska mönster - välkända flaggor, vimplar, trianglar, huvud och axlar, dubbla bottnar och toppar fungerar fortfarande bra;
• grafiska konstruktioner;
• Fibo-nivåer;
• delar av fundamental analys - nu är det svårt att tjäna pengar enbart på nyheter, men det är nödvändigt att ta hänsyn till den ekonomiska kalendern vid handel. Åtminstone bara flytta transaktioner till break-even innan släppet av viktig statistik för USA eller Europa, eller till och med stänga vinsten helt.

Det finns också ett antal tekniker, vars fördelar är tveksamma:

• Martingale är en initialt olönsam taktik, den enda chansen att lyckas är att du innan förlusten kommer att kunna få tillbaka insättningsbeloppet och tjäna lite;

• Det är också oönskat att använda låsning om det inte är absolut nödvändigt, då är det ganska svårt att lämna slottet;
• Det är också bättre att inte använda signaler utifrån. Signaler utifrån innebär till exempel en jämförelse av antalet säljare/köpare, olika index på humöret hos flertalet handlare etc. Men det finns också en rad resurser som du kan lyssna på till exempel Autochartist ger bra signaler baserade på grafiska mönster;
• Det är också bättre att inte använda delar av våganalys (åtminstone för nybörjare). Även om det finns undantag här så bygger till exempel handel på Wolfe Waves just på våganalys, men det är inte speciellt komplext.

Utveckling av en enkel indikatorstrategi

Låt oss anta att huvudidén med strategin är att handla uteslutande i trendens riktning. Dessutom kommer du in på marknaden inte i ögonblicket för uppkomsten av en trend, vilket är ganska riskabelt, utan efter att en liten korrigering är klar.

Strategin bör fungera på nästan alla valutapar, detta är nödvändigt eftersom, på grund av den långa tidsramen, kommer signaler inte att inträffa särskilt ofta. Så situationen kommer att bedömas med 5-7 valutapar samtidigt. När det gäller tidsramen är D1 lämplig; vi utgår från det faktum att Forex i det inledande skedet bara är ett tillägg till huvudarbetet, därför kommer vi att handla med dagliga ljus.

Nu måste du bestämma hur exakt tidpunkten för inträde ska bestämmas. Det finns många alternativ för att identifiera en trend:

• visuellt - men ögonsten låter dig inte utveckla tydliga handelsregler;
• använda ett eller flera glidande medelvärden;
• enligt värdet på ADX-indikatorn, om mer än 30, så finns det en stark trend, mindre än 20, marknaden är lugn;
• använda grafiska konstruktioner;
• Bollinger Bands låter dig bedöma styrkan i en trend efter avståndet mellan kanalens övre och nedre gränser.

Generellt finns det många alternativ, men eftersom strategin behöver vara så enkel som möjligt kommer vi att fokusera på glidande medelvärden. Eller snarare, en MA, vi kommer att bedöma trendens riktning efter prisets position i förhållande till det. Du kan börja med perioder som ger ett genomsnitt av priset över en hel tidsperiod (vecka, månad, kvartal, etc.), till exempel kommer 20 att ha ett genomsnitt av priset under den senaste månaden. Det svåraste är att välja lämplig MA-period, men här måste du gå vidare med försök och misstag.

Huvudidén med handel kommer att vara följande: vi väntar på att trendrörelsen ska dyka upp, sedan följer en korrigering inom en dag, efter att en affär har slutförts. Om allt detta presenteras i form av tydliga regler, kommer algoritmen för åtgärder att se ut så här (med exemplet med köp):

• först kontrollerar vi prispositionen i förhållande till MA, priset bör vara över linjen;
• Därefter måste vi hitta en trendrörelse, vi behöver ett ljus med en stor kropp och små skuggor (det är tillrådligt att värdet på skuggan inte överstiger 10-15% av ljuskroppens storlek);
• det bör följas av ett ljus med en liten daglig räckvidd (avstånd från högt till nära). Stängningspriset bör inte nå nivån på 50 % av föregående dag - den här dagen sker priskorrigeringen.

I det här fallet kan korrigering ske enligt två scenarier:

• När ett ljus med en lång skugga nedan bildas, kan du öppna en handel direkt vid slutet av dagen. Denna form av ljuset indikerar att korrigeringen redan har slutförts;
• ett möjligt alternativ är när korrigeringsljuset stänger på ett minimum, d.v.s. återställningen har ännu inte slutförts, i det här fallet måste du vänta tills nästa ljus stängs; om det är vitt kan du öppna en lång position.

När det gäller att upprätthålla positionen och skyddsorder bör stoppförlusten placeras åtminstone utanför mitten av ljuset med en stor kropp. För att få målnivån räcker det att avsätta värdet av samma ljus från inköpsnivån, du kan använda ett efterföljande stopp.

Reglerna för strategin har utformats, allt som återstår är att testa den i handling. Övning visar att även en så enkel algoritm producerar mer än hälften av lönsamma affärer (och om du överför affären till noll tidigt, minskar sannolikheten för en förlust).

Inträde i början av en trend

Den TS som föreslagits ovan missar en del av trendrörelsen, men kräver inte mycket tid för marknadsanalys. Om det är möjligt att övervaka beteendet för dagens pris, kan du försöka rida på trenden i början av dess bildande. Så huvudtanken med strategin är att komma in på marknaden efter att priset börjar lämna den horisontella kanalen.

Och här är det mycket viktigt att få en pålitlig signal i tid, i början av trenden. Rörliga medelvärden kan återigen komma till undsättning, men de kommer att användas något annorlunda än i den tidigare strategin. Du kan ta flera MA med olika perioder och bedöma bildandet av en trend efter deras läge i förhållande till varandra.

Detta är inte ett revolutionerande tillvägagångssätt; Bill Williams använde något liknande i sin berömda Alligator. Så denna indikator kan till och med tas som grund för TS.

Om vi ​​lägger till Alligator med standardinställningar till H1 kan vi se att det ger många falska signaler, vår uppgift är att rensa bort dem. För att göra detta kommer vi att gå in på marknaden med en väntande order, och nivån på dess placering kommer att bestämmas med hjälp av fraktaler.

Som ett resultat kommer arbetsflödet att se ut så här (med exemplet med köp):

• Vi letar efter ett plant område på sjökortet (alla Alligator-linjer är kaotiskt sammanflätade med varandra);
• Därefter behöver du ett fraktalljus (och det ska vara placerat ovanför linjerna, utan att ens röra dem med den nedre skuggan);
• en köpstopporder placeras strax över dess maximum, och en skyddsorder placeras bortom den nedre gränsen av konsolideringszonen;
• TP är antingen fast (50-70 p), eller använd ett efterstopp. I allmänhet är det ganska svårt att förutsäga styrkan hos en trendrörelse, så det är bättre att använda ett efterstopp än en fast TP eller bestämma målnivån med samma tekniska analys.

Detta exempel är inte att utveckla en strategi från grunden, utan snarare en liten anpassning av en redan känd strategi till den moderna marknaden.

Exempel på ett enkelt kombinerat system

Tanken är fortfarande densamma - inträde i slutet av korrigeringen, men vi kommer att lösa det här problemet på ett annat sätt. Målet förblir detsamma - att bestämma ögonblicket för slutförandet av korrigeringen och gå in i trendens riktning, men om vi tidigare använde det glidande medelvärdet, kommer vi nu att använda Fibo-nivåer och oscillatorn för att bestämma slutförandet av återställningen.

Vi kommer att vara intresserade av en uttalad trendrörelse, den kan också bestämmas visuellt. Efter detta behöver du bara sträcka ut Fibo-nivåerna till det, detta är nödvändigt för att bestämma de potentiella nivåerna för att slutföra korrigeringen. Den mest betydande korrigeringsnivån är 38,2 %; det är tillåtet att handla på returer från 50 % och 61,8 %.

Men det faktum att priset tangerar Fibo-nivån räcker inte, det behövs en bekräftelse. Stochastic klarar denna uppgift ganska bra (du kan prova att använda RSI för samma ändamål). Till exempel, för en köptransaktion måste priset vara nära korrigeringsnivån, och Stokastiska vid den tidpunkten måste vara i den översålda zonen.

Efter att priset nått nivån väntar vi tills Stokastiska lämnar den översålda zonen och köper. Stoppet kan placeras bortom nästa korrigeringsnivå, och TP kan placeras åtminstone på den senaste högsta nivån före starten av pullbacken.

Fibo-nivåer och en oscillator är bara det minsta som krävs för att ta emot en signal. Om så önskas kan du komplicera systemet genom att införa ytterligare filter.

Strategier baserade på teknisk analys

Om teknisk analys används i sin rena form blir uppgiften något enklare, det är inte längre nödvändigt att utveckla ett fordon från grunden. Det finns ett antal tekniker och verktyg, vars effektivitet har testats under åren, och handlaren kan bara välja de lämpliga och använda dem i konstruktioner.
I princip räcker det för framgångsrik handel:

• trendlinjer - vi bygger dem på olika tidsramar, börjar med den högsta och gradvis sjunkande till den fungerande;
• Fibo-nivåer bör de sträckas till betydande prisrörelser i historien. Korrigeringsnivåer på 38,2, 50 och 61,8 % kommer att vara av avgörande betydelse, praxis visar att korrigeringen oftast slutar vid dessa markeringar;
• MT4 implementerar även ett antal andra tekniska analysverktyg, till exempel Andrews pitchforks, en uppsättning Gann-verktyg, flera typer av kanaler, etc.

Men för en ganska exakt prognos räcker det med Fibo-nivåer och trendlinjer, områden med koncentrationer av nivåer och linjer fungerar vanligtvis som stöd/motstånd. Handel kan utföras både för en breakout och för en rebound från nivåer och linjer.

När det gäller ytterligare filter kan du lägga till ljusstakemönster och någon form av indikator för att söka efter divergenser (samma Stokastiska eller MACD). Du kan läsa mer om användningen av teknisk analys.

Filter för handelssystem

Alla handelsfordon, även om idén fungerar och handel generellt är lönsam, genererar många signaler och några av dem är olönsamma. Efter att systemreglerna har formats kan du använda ett antal universella filter som hjälper till att förbättra förhållandet mellan lönsamma/olönsamma transaktioner.

Det finns ett antal filter som passar nästan alla strategier:

• situation på högre tidsramar. Om strategin till exempel genomförs på H1 enligt en mekanisk strategi, så skulle det inte vara fel att titta på vad som händer på H4 och D1;
• genomsnittligt dagligt intervall, vilket betyder avståndet som priset i genomsnitt färdas per dag; vid handel inom dagen kommer detta att hjälpa till att filtrera ett antal signaler. Låt oss föreställa oss att priset under dagen rör sig i genomsnitt 100-120 punkter, om en av dagarna priset på kvällen redan hade passerat 90-100 punkter i en riktning, och TS ger en signal att gå in på marknaden i samma riktning, då är det vettigt att ignorera det, statistik säger att trafiken sannolikt inte kommer att fortsätta denna dag;

Viktig! Efterlevnad av denna regel kommer att leda till att vissa lönsamma affärer missas, men förhållandet mellan lönsamma/förlustaffärer kommer att öka.

• Antalet ljus efter att signalen bildas spelar också roll; det finns till och med ett filter med 5 ljus, som vi kommer att uppehålla oss vid mer i detalj.

När TS ger en signal, bör situationen idealiskt börja utvecklas till vår fördel nästan omedelbart efter att transaktionen avslutats (vilket betyder på nästa 1-3 ljus). Om detta inte sker, desto mer tid som har gått sedan transaktionen slutfördes, desto mindre kommer inflytandet på marknaden att vara de faktorer som spelade roll när näringsidkaren gick in på marknaden. Deras inflytande bleknar med tiden.

Du kan ta 5 ljus som ett kriterium; om priset efter att ha slutit en affär inte har rört sig i en lönsam riktning för 5 ljus, är det bättre att stänga affären manuellt. Detta innebär ett scenario där diagrammet förblir på plats, men om priset har gått till den olönsamma sidan, så tillämpas inte detta filter.

Detta villkor gäller för nästan alla tidsramar (med undantag för m1-m5). Naturligtvis finns det fortfarande en möjlighet att priset, efter att ha svävat runt ett märke, kommer att röra sig i rätt riktning, men vårt val är stabilitet. Det är bättre att offra ett par lönsamma affärer, men undvik 3-5 olönsamma.

Sammanfattande

Att börja arbeta utan ett handelssystem är som döden, varje handlare bör komma ihåg detta. I det här fallet är det bara en tidsfråga att förlora insättningen.

Att välja ett lämpligt fordon är inte svårt, dessutom kan du hitta bra fungerande system i det offentliga området. Du kan också oroa dig för att skapa din egen strategi, speciellt eftersom detta inte kräver kunskaper i programmeringsspråk, du behöver bara ha en idé och åtminstone grundläggande kunskap om hur marknaden fungerar och vilka indikatorer som används för vilka syften.

Processen i sig påminner om att montera en byggsats - först ställer vi ett problem, och sedan väljer vi helt enkelt de nödvändiga verktygen för att lösa det. Efter att ha kontrollerat historiken kan du fortsätta till TS-testet på ett demo- eller centkonto.