Làm game developer bạn sợ nhất điều gì? Bạn có đang bị burn out? **1....

Tắt Quảng Cáo [X]

Đăng Nhập để ẩn Tất Cả Quảng Cáo

Làm game developer bạn sợ nhất điều gì? Bạn có đang bị burn out?

**1. Project không có định hướng rõ ràng. Chỉ làm theo ý sếp.**

Một ngày sếp đến nói với bạn rằng: em cứ làm y chang như game này cho anh. Sau 1 tuần sau thì sếp lại nói: anh thấy chức năng game kia hay kìa, làm giống nó đi em. Tuần sau nữa sếp lại nói tiếp: bây giờ là xu hướng battle pass rồi,

game mình phải có battle pass em ạ....

Khi team không có định hướng rõ ràng thì chuyện bạn bị xoay như chong chóng là dễ hiểu. Đành rằng sự thay đổi trong ngành sáng tạo là tất yêu, nhưng mà, code nó không như thế. Người code giỏi lúc nào cũng sẽ phải suy nghĩ code phải có cấu trúc hợp lí sao cho

hạn chế phát sinh vấn đề sau này. Kiến trúc gấu trúc các kiểu cho tốt cho đẹp cuối cùng đùng 1 phát thay đổi chỉ vì sở thích của sếp hoặc thấy game kia mới ra làm hay hơn... thì vỡ mồm thật.

**2. Dự án quá dễ và lặp lại**

Sau nhiều năm tu luyện, bạn bắt đầu xuống núi và tìm một nơi nào đó để làm việc với mong muốn thể hiện hết bản lĩnh của mình. Ban đầu thì dự án có hứng thú 1 chút nhưng chỉ trong vòng vài tháng bạn biết hết mọi ngóc nghách.

Dự án quá dễ đối với bạn và đặt biệt nó lại lặp lại liên tục. Nếu cứ tiếp tục như thế trong thời gian dài sẽ sinh ra tâm lí chán nản vô cùng. Đi làm cứ như là con zombie uể oải không sức sống. Xong việc là muốn bay về nhà làm dự án riêng cho mình.

**3. Làm một lúc nhiều dự án hoặc nhiều việc**

Không gì giết chết performance của 1 chiến binh bằng cách để anh ta làm nhiều việc cùng lúc, nhiều dự án cùng lúc mà cái gì cũng đòi xong ngay, cái gì cũng kêu quan trọng.

Do tính chất dự án, đặc biệt là dự án hyber casual bạn sẽ cân mọi thứ từ UI/UX cho đến gameplay, sfx,... Chưa kể 1 lúc bạn phải fix bug cho dự án A, gắn mediation cho dự án B, code gameplay cho dự án C... khiến cho một ngày trông có vẻ bạn làm rất nhiều thứ nhưng chẳng thứ nào ra thứ nào.

**4. Team đứa sụt đứa trồi**

Dev ai cũng hiểu việc OT làm việc qua đêm để giữ đúng deadline là chuyện bình thường. Nhưng chán nhất là 1 mình mình cố gắng trong khi nhiều người vẫn phè phỡn nhưng kết quả thì lại giống nhau thì chắc là không vui vẻ gì rồi.

Hiệu năng của một nhóm phụ thuộc vào người chậm nhất. Nếu trong team có bạn nào đó chậm chạp, cẩu thả, làm nhiều bug thì nguyên team phải chờ bạn này.

**5. Burn out (kiệt sức)**

Làm trong một dự án lớn và khó sẽ dễ làm bạn bị burn out (kiệt sức). Dự án kéo dài quá lâu, quá phức tạp lại rối rắm. OT liên tục và thường xuyên khiến bạn bị kiệt sức và không tìm thấy niềm vui trong công việc nữa.

**6. Không được công nhận**

Thường thì dev trong nghành game là vai trò khó nhất nhưng lại bị đánh giá không đúng nhất. Nếu có bug, tỉ lệ crash rate/ant rate cao thì hẳn là user sẽ kêu gào 1* ngay, QC cầm lên ra lỗi ngay, và bạn sẽ là người chịu trận đầu tiên. Nhưng khi bạn làm tốt thì sao?

Chức năng chạy mượt mà, tỉ lệ crash thấp, tỉ lệ phản hồi cao, chạy trên rất nhiều device vẫn rất ổn định, start time cực nhỏ,.... thì sếp và user ít khi nhận biết được chuyện này.

Ông art làm đẹp 1 phát là được khen ngay: ôi đẹp quá. Còn mình vắt óc để nghĩ ra 1 thuật toán chỉnh chu, chạy cực nhanh thì có khi lại còn bị nói: sao em làm kĩ làm gì, làm cho chạy là được rồi

**7. Gặp game design không hiểu kĩ thuật**

Thường nếu game designer xuất thân từ các nghành kinh tế hoặc non-tech mới tìm hiểu được vài ngôn ngữ lập trình thì nghĩ rằng: ồ, lập trình nó dễ mà, tụi dev nó toàn làm màu với mình chứ có khó gì đâu thì chết cmn.

Nếu gặp phải game designer/sếp như này thì y như rằng bạn sẽ nhận được các câu: cái này dễ mà, anh nghĩ làm 1-2 ngày là xong,... cho anh nhờ chỉnh cái này xíu thôi sao phải khó thế.

Bạn dev nào tốt tính 1 chút không biết từ chối hoặc không cứng là ăn hành ngập họng.

**8. Giao tiếp trong team kém**

Việc giao tiếp trong game là cực kì quan trọng ảnh hưởng đến toàn dự án. Nếu giao tiếp kém, bạn không hiểu ý game designer/PO hoặc ngược lại đến khi cắm mặt vào code ra hệ thống mới vỡ lỡ ra ý ổng không phải vậy.

Đang làm thì bị chỉnh sửa doc mà không thông báo, không thảo luận trước khi điều chỉnh chức năng,.. Team dev không giao tiếp hàng ngày để dẫm chân lên nhau, thắt nút cổ chại,..

Người VN chúng ta thường giao tiếp kém, cả nể, sợ sung đột đặt biệt là dev,... dẫn đến thường im lặng hoặc bỏ qua hoặc không giao tiếp đến cùng khiến vấn đề không được giải quyết thấu đáo.

**9. Document không rõ ràng**

Có thể nói đây là 1 vấn nạn trong dự án game. Nhất là với những nhóm mới làm việc chung thì doc ông này viết 1 kiểu, ông kia viết 1 kiểu. Ông game designer trước nghỉ giờ ông mới vào viết lại 1 kiểu hoàn toàn mới.

Dự án size lớn hơn 1 chút thì cần có kiến trúc hệ thống, diagram các kiểu để dev giao tiếp thuận lợi nhưng leader không viết, nói miệng.

Khi update document thì không thông báo, lẳng lặng update, không ghi revision,...

--------------------------

Giải pháp để giảm thiểu nỗi sợ

**1.Project không có định hướng rõ ràng. Chỉ làm theo ý sếp.**

Nếu bạn là dev thì hãy dừng ngay sếp lại khi ổng bắt đầu thay đổi tính năng. Yêu cầu giải thích rõ tại sao cần thay đổi. Nếu lúc bắt đầu dự án thì nên tiếp cận theo hướng MVP, code không nên chỉnh chu mà chỉ cần chức năng chính hoạt động.

Mà, nên tránh những công ty làm như thế này vì đa phần những dự án vậy sẽ chết rất nhanh thôi.

Nếu bạn là sếp thì thuê game designer về, chấp nhận đầu tư để team làm quen nhiều năm cách làm việc với nhau. Suy nghĩ, R&D Kĩ trước khi làm 1 dự án vì làm game là cuộc chơi lâu dài. Và nhất là đừng bao giờ lấy ý tưởng cá nhân áp đặt và bắt team làm theo nếu bạn không phải là game designer. Ý tưởng nó khác xa hoàn toàn với việc thiết kế và hoàn thiện nó.

**2.Dự án quá dễ và lặp lại**

Nếu bạn là dev thì bạn cần trao đổi với sếp thẳng thắn và đề nghị làm những tool để những công việc lặp lại được làm tự động. Thời gian rãnh có thể xin sếp cho làm research những cái mới để phục vụ dự án. Không nên để công việc trên công ty nhàm chán.

Nếu bạn là sếp thì cần nói chuyện với member nhiều hơn để biết rõ khi nào họ chán. Thường những team làm outsource hoặc team làm clone sẽ dễ làm dev chán. Nên có những dự án vui vui hoặc research 1 công nghệ gì đó để các dev được học hỏi nhiều hơn xen kẽ với các dự án công ty.

**3. Làm một lúc nhiều dự án hoặc nhiều việc**

Nếu bạn là dev: bạn phải biết từ chối hoặc đặt độ ưu tiên những task của mình. Tất cả các task thêm vào nếu không có độ ưu tiên cao hơn task đang làm thì để sau. Độ ưu tiên cao & quan trọng làm trước, ưu tiên vừa quan trọng làm sau. Không quan trọng thì tìm cách vứt đi.

Nếu bạn là sếp: uống lưỡi 7 lần trước khi thêm bất kì thứ gì cho nhân viên mình làm. Nếu nó không có mang chút lợi ích gì cho user mà chỉ vì bạn thích thì không nên thêm vào. Khi thêm/thay đổi phải theo lộ trình và cần phải confirm với dev trước. Nên tạo thói quen trong sprint không thêm story mới vào.

**4. Team đứa sụt đứa trồi**

Nếu bạn là dev: cần phải thẳng thắng trao đổi với team/leader/người chậm, có thể giao những phần không quan trọng hoặc ít việc cho người này để giảm thiểu rủi ro. Đừng cả nể mà nguyên team phải ăn hành.

Nếu bạn là sếp: đừng vì thiếu tiền mà tuyển mấy dev quá lởm. 3 dev lởm đẵ bằng tiền 1 bạn dev xịn rồi nên cứ mạnh dạn sa thải những bạn yếu này. Sau 2 tháng thử việc cứ mạnh dạng sa thải chứ không 2 năm sau team phải ăn hành đều đều.

**5. Burn out (kiệt sức)**

Nếu bạn là dev: nên xin sếp chuyển qua dự án khác hoặc làm phần khác hoặc xin nghỉ dài ngày để đi chơi lấy lại tinh thần trong điều kiện cho phép.

Nếu bạn là sếp: bạn nên chú ý sự thay đổi của nhân viên. Nếu là start-up thì việc này khó tránh khỏi nên bạn thường xuyên nói chuyện với member của mình. Chọn những thứ quan trọng ảnh hưởng đến kết quả lớn (OKRs) để làm thay vì làm lan man.

Dự án lớn thì nên có milestone rõ ràng, mỗi milestone cần có output rõ ràng để member thấy được kết quả họ làm được.

**6. Không được công nhận**

Nếu bạn là dev: trong các buổi đánh giá hoặc review lương hoặc bất cứ khi nào có cơ hội, thẳng thẳng chỉ ra những tiến bộ của mình thông qua các chỉ số (crash rate/ant rate/review/rating,..) để PR rằng mình đã làm tốt như thế nào. Nếu sếp không chú ý nữa thì chuyển công ty sớm nhe.

Nếu bạn là sếp: theo dõi các chỉ số kĩ thuật để đánh giá công bằng cho team dev của bạn. Khen thưởng kịp thời nếu có tiến bộ qua từng version. Nên nhớ quality của 1 game ảnh hưởng đến organic game đố rất nhiều, cái đó không phải ai cũng thấy được. Thường xuyên theo dõi sự tiến bộ của nhân viên để khen thưởng hợp lí.

Khen thưởng và tôn trọng nhân viên là liều thuốc tăng lực cực kì hiệu quả.

**7.Gặp game design không hiểu kĩ thuật hoặc hiểu rất ít**

Nếu bạn là dev nên quyết liệt giải thích cho designer/sếp hiểu theo cách dễ hiểu nhất. Đưa ra con số hợp lí cho mình & cho sếp để mọi chuyện được nhìn nhận đúng hơn. Cũng đừng bảo vệ lợi ích của mình để thoái thát mà phải đặt lợi ích của dự án.

Đôi khi phải từ chối task để làm cho dự án tập trung và đi đúng hướng.

Nếu là sếp thì cần phải có ít nhất 1 bạn tech leach hoặc technical designer để tư vấn đưa ra quyết định. Nên nhớ là kĩ năng quan trọng của sếp là tin tưởng đúng người và trao quyền đúng chỗ.

**8. Giao tiếp trong team kém**

Nếu là dev: Thường nếu team nào dùng Agile Scrum thì sẽ có buổi họp 10-15 phút mỗi buổi sáng để dev trình bày vấn đề gặp phải, nên tận dụng tối đa buổi này. Nếu không có thì nên đề nghị team/sếp về cuộc họp định kì để trình bày những khó khăn gặp phải.

Nếu là sếp thì bạn nên chọ mô hình làm việc nào đó để khuyến khích dev trình bày ý tưởng hay những vấn đề đang gặp phải một cách thuận tiện nhất, ví dụ như scrum để khai thác tối đa việc giao tiếp giữa các dev.

**9. Document không rõ ràng**

Nếu bạn là dev: trong các cuộc họp dev mạnh dạn nêu vấn đề để được xem xét. Thường document không rõ ràng thì về sau bạn mới bị ăn hành nên lúc đầu cần đề nghị team design viết càng chỉnh chu càng tốt

Nếu bạn là sếp: có qui trình viết doc rõ ràng, ghi rõ revision, qui chuẩn để thống nhất tất cả game designer. Khi update doc cần thông báo cho những người liên quan bằng email/kênh chat,... Nên nhớ là doc càng kĩ, tuy ban đầu mất thời gian nhưng lúc sau lại tiết kiệm rất rất nhiều thời gian.

------------------------

Trên đây là một vài điểm mình nhận thấy trong quá trình làm game với tư cách là 1 dev lẫn game design và là 1 người sếp. Tất nhiên thực tế diễn ra còn phức tạp hơn và tùy vào từng trường hợp mà giải pháp nó khác nhau.

Hi vọng có thể giúp được các anh em.

Và còn 1 giải pháp nữa là anh em nên gia nhập những team chuyên nghiệp, các dev đã có hàng năm làm việc chung với nhau như Wolffun Game chẳn hạn để giảm thiểu các rủi ro nêu trên.

Wolffun đang cần tuyển Unity Developer cho dự án làm về Unity, Google App Engine, GCP, Playfap/Gamesparks, Quantumn,ECs... đủ để anh em tha hồ học hỏi và phát triển trong nhiều năm.

Cv xin gửi về: [email protected] nhe

Vui lòng đăng kí hoặc đăng nhập để thấy liên kết tại BigMMO

Vui lòng đăng kí hoặc đăng nhập để thấy liên kết tại BigMMO

Không phải ở đâu cũng nhận ra tầm quan trọng của developers.

 

Cái số 6: làm art k hề dễ, đặc biệt là 3d, suy nghĩ giảm poly, trải uv đủ kiểu chứ đâu phải cứ art là nghệ thuật k não đâu anh ._. Nhiều lúc art đẹp, hợp lý thì bị kêu: kĩ năng thượng thừa đó, nhưng k cần thiết

 

Đọc bài này rất hay đó anh, mà giống như anh đã làm rất lâu rồi nên có nhiều kinh nghiệm, không biết anh có thể giơis thiệu qua một vài sản phẩm anh hay nhóm anh đã làm được k ạ?

 

hello lại gặp bác ở đây một trong nhưng người test game Heroes Strike khi còn beta ) , mà Wolffun xóa trò tank gì đấy trên google play rồi à hay em nhớ nhầm nhỉ

 

Sự quan trọng của dev game: Dù art có đẹp, dù model có tốt hay là bản nhạc hay đến mấy nhưng nếu không có người lập trình để chúng hoạt động thì cũng như không

 

Dạo này tui đang sợ bị nói đạo ý tuởng vèe thiết kế nhân vật

 

Anh Khánh bữa nào làm 1 bài về Tech Debt được không ạ? Cụ thể là code tốt theo SOLID hay có 1 structure tốt sẽ có lợi gì chẳng hạn.
Em bôn ba 3 năm qua vẫn ấp ức mãi vì teammate hay lead không quan trọng tech debt :'(

 

Sợ deadline