Bitki referans projesi

Bitki oyuncuların tohumları ektiği ve su verdikleri bir referans deneyimdir, böylece daha sonra elde edilen bitkileri hasat edip satabilirler.

Proje, Roblox'ta bir deney geliştirirken karşılaşabileceğiniz yaygın kullanım durumlarına odaklanır.Uygulanabilirse, takaslar, uzlaşmalar ve çeşitli uygulama seçeneklerinin mantığı hakkında notlar bulacaksınız, böylece kendi deneyimleriniz için en iyi kararı verebilirsiniz.

Dosyayı alın

1. Bitki deneyim sayfasına yönlendirin.
2. ⋯ düğmesine tıklayın ve Stüdyoda Düzenle .

Durumları kullan

Bitki aşağıdaki kullanım durumlarını kapsar:

• Oturum verileri ve oyuncu verileri kalıcılığı
• Arayüz görüş yönetimi
• İstemci-sunucu ağı
• İlk Kez Kullanıcı Deneyimi (FTUE)
• Sert ve yumuşak para satın alımları

Ayrıca, bu proje, şunlar dahil olmak üzere birçok deneyime uygulanabilen daha dar bir dizi sorunu çözer:

• Bir oyuncuilişkili bir alanın özelleştirilmesi
• Oyuncu karakterinin hareket hızını yönetme
• Karakterleri etrafında takip eden bir nesne oluşturma
• Bir karakterin dünyanın hangi bölümünde olduğunu tespit etmek

Bu deneyimde çok küçük, çok niche veya ilginç bir tasarım meydan okumasına çözüm göstermeyen birkaç kullanım durumu olduğunu unutmayın; bunlar kapsanmıyor.

Proje yapısı

Deneyim oluştururken ilk karar, öncelikle belirli örneklerin veri modeline yerleştirilmesi ve istemci ve sunucu kodu için giriş noktalarının nasıl düzenleneceği ve yapılandırılacağına karar vermektir.

Veri modeli

Aşağıdaki tablo, veri modeli örneklerinde hangi konteyner hizmetlerinin yerleştirildiğini açıklar.

Giriş noktaları

Çoğu proje, tüm kod tabanı boyunca ithal edilebilen yeniden kullanılabilir ModuleScripts kod içinde kodu düzenler.ModuleScripts yeniden kullanılabilir, ancak kendi başına çalışmazlar; bir Script veya LocalScript tarafından ithal edilmeleri gerekir.Birçok Roblox projesi, oyundaki bir davranış veya belirli bir sisteme ait büyük sayıda Script ve LocalScript nesneye sahip olacak ve birden fazla giriş noktası oluşturacak.

Bitki mikro oyunu için, tüm istemci kodu için giriş noktası olan tek bir LocalScript ve tüm sunucu kodu için giriş noktası olan tek bir Script uygulanır.Projeniz için doğru yaklaşım gereksinimlerinize bağlıdır, ancak tek bir giriş noktası, sistemlerin yürütüldüğü sıraya daha fazla kontrol sağlar.

Aşağıdaki listeler her iki yaklaşımın dezavantajlarını açıklar:

• Tek bir Script ve tek bir LocalScript sunucu ve istemci kodunu kapsar.
• Farklı sistemlerin başlatıldığı sıraya daha fazla kontrol, çünkü tüm kod tek bir senaryodan başlatılır.
• Sistemler arasında referansla nesneler geçebilir.

Yüksek seviye sistem mimarisi

Projedeki üst düzey sistemler aşağıda ayrıntılı olarak tanımlanmıştır.Bu sistemlerin bazıları diğerlerinden çok daha karmaşıktır ve birçok durumda işlevsellikleri diğer sınıfların bir hiyerarşisinde soyutlanır.

Bu sistemlerin her biri bir "tek"tir, çünkü bunlar, yerine ilgili istemci veya sunucu tarafından başlatılan anlık olmayan bir sınıftır start .Daha sonra bu rehberde tek boyutlu model hakkında daha fazla bilgi edinebilirsiniz.

Sunucu

Aşağıdaki sistemler sunucu ile ilişkilidir.

Müşteri

Aşağıdaki sistemler istemci ile ilişkilidir.

Client-server iletişimi

Çoğu Roblox deneyimi, müşteri ve sunucu arasında bir iletişim öğesi içerir.Buna, sunucunun belirli bir eylem yapmasını isteyen istemci ve sunucunun müşteriye güncelleştirmeler yapması dahil olabilir.

Bu projede, istemci-sunucu iletişimi mümkün olduğunca genel olarak tutulur, böylece izlenmesi gereken özel kural miktarı azaltılır. RemoteEvent ve RemoteFunction nesnelerinin kullanımı sınırlandırılarak.Bu proje, tercihe göre aşağıdaki yöntemleri kullanır:

• oyuncu veri sistemi üzerinden replikasyon .
• öznitelikleri aracılığıyla replikasyon.
• Etiketler aracılığıyla replikasyon .
• Mesajlaşma doğrudan Ağ modülü aracılığıyla.

Oyuncu veri sistemi aracılığıyla replikasyon

The oyuncu veri sistemi verilerin kaydetme seansları arasında kalan oyuna bağlanmasına izin verir.Bu sistem, verileri sorgulamak ve değişikliklere abone olmak için kullanılabilecek bir dizi API ile sunucudan müşteriye yedekleme sağlar ve böylece oyuncu durumundaki değişiklikleri sunucudan müşteriye yedekleme ideal hale getirir.

Örneğin, müşteriye kaç tane para sahip olduğunu söylemek için özel bir UpdateCoins``Class.RemoteEvent ateşlemek yerine, aşağıdakileri çağırabilir ve müşterinin buna PlayerDataClient.updated etkinliği aracılığıyla abone olmasına izin verebilirsiniz.

PlayerDataServer:setValue(player, "coins", 5)

Tabii ki, bu yalnızca sunucudan müşteri yeniden yazma ve seanslar arasında sürekli tutmak istediğiniz değerler için yararlıdır, ancak projede şaşırtıcı sayıda durum için geçerlidir:

• Mevcut FTUE aşaması
• oyuncuenvanteri
• Oyuncunun sahip olduğu para miktarı
• oyuncuçiftliğinin durumu

Öznitelikler aracılığıyla yeniden yazma

Sunucunun belirli bir Instance için müşteriye özel bir değeri yeniden yazması gereken durumlarda, öznitelikleri kullanabilirsiniz.Roblox otomatik olarak özellik değerlerini yeniden yazdırır, bu nedenle bir nesne ile ilişkili durumu yeniden yazmak için herhangi bir kod yolu korumana gerek yoktur.Bir başka avantaj, bu yeniden yazma işleminin kendi örneğinin yanında gerçekleşmesidir.

Bu, çalışma sırasında oluşturulan örnekler için özellikle yararlıdır, çünkü veri modeline eşlenmeden önce yeni bir örnek üzerinde ayarlanan öznitelikler, örnekle aynı anda atomik olarak yeniden üretilecektir.Bu, ekstra verilerin bir RemoteEvent veya StringValue üzerinden yeniden yazılmasını beklemek için kod yazma gereksinimini ortadan kaldırır.

Veri modelinden doğrudan öznitelikleri okuyabilir, istemci veya sunucudan, GetAttribute() yöntemi ile ve GetAttributeChangedSignal() yöntemi ile değişikliklere abone olabilirsiniz.Bitki projesinde, bu yaklaşım, diğer şeylerin yanı sıra, mevcut bitki durumunu müşterilere yeniden yansıtmak için kullanılır.

Etiketler aracılığıyla yeniden yazma

CollectionService bir Instance 'a bir dize etiketi uygulamanıza izin verir. Bu, durumları kategorize etmek ve bu kategorizasyonu müşteriye yeniden yansıtmak için yararlıdır.

Örneğin, CanPlant etiketi, bir verinin alınabilir olduğunu müşteriye bildirmek için sunucuya uygulanır ve verilen bir tencere bir bitki alabilir.

Ağ modülü aracılığıyla doğrudan mesaj iletme

Önceki seçeneklerden hiçbiri uygulanmayan durumlarda, Ağ modülü aracılığıyla özel ağ çağrıları kullanabilirsiniz.Bu, projede istemci-sunucu iletişimine izin veren tek seçenek ve bu nedenle istemci isteklerinin gönderilmesi ve bir sunucu yanıtı alınması için en yararlı olanıdır.

Bitki çeşitli müşteri istekleri için doğrudan ağ çağrıları kullanır, şunlar da dahil:

• Bir bitkiyi sulama
• Bir tohum ekinme
• Bir öğe satın alma

Bu yaklaşımın dezavantajı, her bir mesajın projenin karmaşıklığını artırabilecek özel bir yapılandırmaya ihtiyacı olmasıdır, ancak mümkün olduğunca bunlardan kaçınılmıştır, özellikle de sunucu-müşteri iletişimi için.

Sınıflar ve singletonlar

Roblox'taki örnekler gibi Bitki projesindeki sınıflar oluşturulabilir ve yok edilebilir.Sınıf mantığı, nesne yönlü programlama için bir dizi değişiklikle ilgili idiomatik Lua yaklaşımından ilham alır ve sıkı tip kontrolü desteğini etkinleştirmek için bir dizi değişiklik yapar.

Hemenleştirme

Projedeki birçok sınıf bir veya daha fazla Instances ile ilişkilidir.Verilen sınıfın nesneleri, new() yöntemi kullanılarak oluşturulur ve Roblox'ta örneklerin oluşturulmasıyla uyumludur Instance.new().

Bu model genellikle sınıfın veri modelinde fiziksel bir temsiline sahip olduğu nesneler için kullanılır ve sınıf işlevselliğini genişletir.İyi bir örnek, verilen iki nesne arasında bir nesnesi oluşturan ve ışınların daima yukarı doğru yönlendirilmesini sağlayan örnektir.Bu örnekler, ReplicatedStorage önceden üretilmiş bir sürümden klonlanabilir veya bir argüman olarak new() nesneye geçirilebilir ve self altında nesnenin içine saklanabilir.

Eşleşen örnekler

Yukarıda belirtildiği gibi, bu projedeki birçok sınıfın bir veri model temsiline sahiptir, sınıfa karşılık gelen bir örnek ve onun tarafından manipüle edilir.

Bir sınıf nesnesi yerleştirildiğinde bu örnekleri oluşturmak yerine, kod genellikle Clone() önceden üretilmiş bir versiyonun Instance altında depolandığı ReplicatedStorage veya ServerStorage içinde saklandığını seçer.Bu durumlardaki özelliklerin serialize edilmesi ve sıfırdan sınıfta oluşturulması mümkün olsa da, bunu yapmak nesnelerin düzenlenmesini zorlaştırır ve bir okuyucunun onları daha zor okumasını sağlar.Ayrıca, bir örneği klonlamak genellikle yeni bir örnek oluşturmak ve yürütme sırasında özelliklerini özelleştirmekten daha hızlı bir işlemdir.

Yapım

Miras, metatabloları kullanarak Luau'da mümkün olsa da, proje yerine sınıfların birbirlerini kompozisyonla uzatmasına izin vermeyi tercih ediyor.Kompozisyon yoluyla sınıfları birleştirirken, "çocuk" nesnesi sınıfın new() yönteminde instanslaştırılır ve self altında bir üye olarak dahil edilir.

Bunun aksiyonbir örneği için, CloseButton sınıfını sarıp Button sınıfını kaplayan sınıfı görün.

Temizleme

Bir ile nasıl yok edilebileceğine benzer şekilde, çalıştırılabilecek sınıflar da yok edilebilir.Proje sınıfları için yok edici yöntemi, kod tabanının yöntemleri arasında tutarlılık sağlamak ve ayrıca proje sınıfları ve Roblox örnekleri arasında ayrım yapmak için küçük harfli ile dir.

destroy() yönteminin rolü, nesne tarafından oluşturulan herhangi bir örneği yok etmek, herhangi bir bağlantıyı koparmak ve herhangi bir çocuk nesneye destroy() çağırmaktır.Bu, bağlantılar için özellikle önemlidir, çünkü aktif bağlantıları olan örnekler Luau atık toplayıcı tarafından temizlenmez, örnek veya bağlantılara hiçbir referans kalmasa bile.

Tek boyutlular

Tek boyutlu nesneler, adından da anlaşılacağı gibi, yalnızca bir nesnenin var olabileceği sınıflardır.Projenin Roblox'un Hizmetlerine eşdeğeridir.Tek başına nesneye bir referans depolamak ve bunu Luau kodunda dolaştırmaktan ziyade, Bitki bir ModuleScript geri döndürülen değerin gerektirmesi avantajından yararlanır.Bu, farklı yerlerden aynı singletonun ModuleScript gerektirilmesinin, aynı döndürülen nesneyi tutarlı bir şekilde sağladığını gösterir.Bu kuralın tek istisnası, farklı çevrelerin (istemci veya sunucu) ModuleScript 'e erişmesi olurdu.

Tek boyutlu sınıflar, bir new() yöntemleri olmadığı için sabit sınıflardan ayırt edilir.Bunun yerine, yöntemleri ve durumu ile birlikte nesne doğrudan ModuleScript üzerinden geri döndürülür.Tek boyutlu nesneler yok sayıldığından, self söz dizimi kullanılmaz ve yöntemler bir nokta ( . ) yerine bir nokta ile çağrılır ( : ).

Sıkı tür tahmini

Luau yavaş yazma desteği sağlar, bu da bazı veya tüm kodunuza seçici tür tanımları eklemekte özgür olduğunuzu gösterir.Bu projede, strict her kript için tip denetimi kullanılır.Bu, Roblox'un senaryo analiz aracı için en az izin veren seçenek ve dolayısıyla yürütmeden önce hata türlerini yakalama olasılığı en yüksek olanıdır.

Yazılı sınıf sözdizimi

Lua'da sınıflar oluşturmak için belirlenen yaklaşım iyi belgelenmiştir, ancak güçlü Luau tiplemesi için uygun değildir.Luau'da, bir sınıfın türünü almak için en basit yaklaşım typeof() yöntemi:

type ClassType = typeof(Class.new())

Bu çalışır, ancak sınıfın yalnızca çalışma sırasında mevcut olan değerlerle başlatıldığında yararlı değildir, örneğin Player nesneler.Ayrıca, idiomatik Lua sınıf mantığında yapılan varsayım, bir sınıfta yöntem ilan etmenin daima o sınıfın bir örneği olacağıdır; bu, tip tahmin motorunun yapabileceği bir varsayım değildir.

Sıkı tür çıkarımını desteklemek için, Bitki projesi bir dizi şekilde idiomatik Lua sınıf söz diziminden farklı bir çözüm kullanır, bazıları mantıksız gelebilir:

• self tanımı, hem tip deklarasyonunda hem de yapıcıda yinelenir.Bu, bakım yükü getirir, ancak iki tanım birbirine geçersiz kalırsa uyarılar işaretlenecektir.
• Sınıf yöntemleri bir nokta ile ilan edilir, bu nedenle self açıkça ClassType tipi olarak ilan edilebilir.Yöntemler hala beklenen bir virgülle çağrılabilir.

--!sıkıntılı

local MyClass = {}
MyClass.__index = MyClass

export type ClassType = typeof(setmetatable(
	{} :: {
		property: number,
	},
	MyClass
))

function MyClass.new(property: number): ClassType
	local self = {
		property = property,
	}

	setmetatable(self, MyClass)

	return self
end

function MyClass.addOne(self: ClassType)
	self.property += 1
end

return MyClass

Mantıksal koruyucuların ardından türler yansıtın

Yazma sırasında, bir değerin türü bir koruma koşul ifadesinden sonra daraltılmaz.Örneğin, aşağıdaki koruyucuyu takip ederek, optionalParameter türü number kısıtlanmaz.

--!sıkıntılı

local function foo(optionalParameter: number?)
	if not optionalParameter then
		return
	end

	print(optionalParameter + 1)
end

Bunu azaltmak için, bu koruyucuların türleri açıkça yansıtıldıktan sonra yeni değişkenler oluşturulur.

--!sıkıntılı

local function foo(optionalParameter: number?)
	if not optionalParameter then
		return
	end

	local parameter = optionalParameter :: number

	print(parameter + 1)
end

Veri Modeli hiyerarşilerini geçme

Bazı durumlarda, kod tabanı çalışma sırasında oluşturulan nesne ağacının veri modeli hiyerarşisini geçmelidir.Bu, tip kontrolü için ilginç bir meydan okuma sunar.Yazılırken, genel bir veri modeli hiyerarşisini bir yazolarak tanımlamak mümkün değildir.sonuç, bir veri modeli yapısı için mevcut tek tip bilgi, üst seviye örneğin türüdür.

Bu meydan okumaya bir yaklaşım, any 'ye fırlatmak ve ardından keskinleştirmektir. Örneğin:

local function enableVendor(vendor: Model)
	local zonePart: BasePart = (vendor :: any).ZonePart
end

Bu yaklaşımın sorunu, okunabilirliği etkilemesidir.Bunun yerine, proje veri modeli hiyerarşilerini içeri aktaran genel bir modül olan getInstance kullanır any içeri aktarma için.

local function enableVendor(vendor: Model)
	local zonePart: BasePart = getInstance(vendor, "ZonePart")
end

Veri modelinin anlayışı geliştikçe tip motorunun, bu tür kalıpların artık gerekli olmayacağı olasıdır.

Kullanıcı arayüzü

Bitki çeşitli karmaşık ve basit 2D kullanıcı arayüzlerini içerir.Bunlar arasında para sayacı ve dükkân gibi etkileşimsiz başlıklar ve karmaşık etkileşimli menüler gibi alışveriş yapgibi etkileşimli öğeler bulunur.

UI yaklaşımı

Roblox UI ile HTML DOM'u genel olarak karşılaştırabilirsiniz, çünkü kullanıcının ne görmesi gerektiğini tanımlayan bir nesne hierarhisidir.Roblox UI'yi oluşturma ve güncelleme yaklaşımları geniş ölçüde zorunlu ve ilan edici uygulamalara ayrılmıştır.

Bitki bir zorunlu yaklaşımını kullanır ve dönüşümleri doğrudan göstermek, Roblox'ta UI'nın nasıl oluşturulduğunu ve manipüle edildiğini daha etkili bir genel bakış verir.Bu, ilan edici bir yaklaşımla mümkün olmayacaktır.Bazı tekrarlanan UI yapıları ve mantıkları da zorunlu UI tasarımında ortak bir hata kaçınmak için yeniden kullanılabilir bileşenlere aktarılır.

Yüksek düzey mimari

Katman ve bileşenler

In Bitki , tüm UI yapıları ya bir Layer ya da bir Component dır.

• Layer önceden üretilmiş UI yapılarını ReplicatedStorage içine sararak tanımlanır bir üst düzey grupman olarak.Bir katman bir dizi bileşen içerebilir veya kendi mantığını tümüyle kaplayabilir.Katman örnekleri envanter menüsü veya başlıklar üzerindeki para sayısı göstergesidir.
• Component yeniden kullanılabilir bir UI öğesidir.Yeni bir bileşen nesnesi instanslaştırıldığında, önceden üretilmiş bir şablonu ReplicatedStorage 'dan klonlar.Bileşenler kendi içinde başka bileşenler içerebilir.Komponent örnekleri genel bir düğme sınıfı veya bir liste öğesi konseptidir.

Görüntüleme işleme göster

Ortak bir UI yönetim sorunu, görüntü işlemedir.Bu proje, bir dizi menü ve HUD öğesine sahiptir ve bunlardan bazıları kullanıcı girişini dinler ve görünür veya etkinleştirildiğinde dikkatli yönetim gereklidir.

Bitki bu sorunu, bir UI katmanının ne zaman görünür veya görünmez olması gerektiğini yöneten UIHandler sistemiyle yaklaşır.Oyundaki tüm UI katmanları HUD veya Menu olarak sınıflandırılır ve görünürlükleri aşağıdaki kurallar tarafından yönetilir:

• Etkin durum Menu ve HUD katmanları değiştirilebilir.
• Etkinleştirilmiş HUD katmanları yalnızca Menu katmanları etkinleştirilmediğinde gösterilir.
• Etkin Menu katmanlar bir yığında depolanır ve aynı anda yalnızca bir Menu katmanı görülebilir.Menu bir katman etkinleştirildiğinde, yığının önüne yerleştirilir ve gösterilir.Bir Menu katmanı devre dışı bırakıldığında, yığından kaldırılır ve sırada bir sonraki etkin Menu katmanı gösterilir.

Bu yaklaşım mantıklıdır çünkü menülerin tarih ile gezinti yapmasına izin verir.Bir menü başka bir menüden açılırsa, yeni menüyü kapatmak eski menüyü tekrar gösterecektir.

Kullanıcı arayüzü katmanı tek boyutlu kendilerini UIHandler ile kaydeder ve görünürlüğü değişmesi gerektiğinde ateşleyecek bir sinyal sağlanır.

Daha fazla okuma

Bitki projesinin bu kapsamlı genel bakışından, ilgili konseptler ve konular üzerinde daha fazla derinleşen aşağıdaki rehberleri keşfetmek isteyebilirsiniz.

• İstemci-Sunucu Modeli — Roblox'ta istemci-sunucu modelinin genel bir bakışı.
• Luau — Luau'ya ilişkin ayrıntılar Luau , Roblox tarafından oluşturulan kodlama dili Lua 5.1 'den aşağıya indirildi.
• Uzak Etkinlikler ve Geri Çağrılar — Tüm uzak ağ etkinlikleri ve istemci-sunucu sınırı arasında iletişim için geri çağrılar.
• Kullanıcı arayüzü nesneleri ve Roblox'ta tasarım ayrıntıları — Kullanıcı arayüzü nesneleri ve Roblox'ta tasarım ayrıntıları.