오늘은 메뉴를 구현해봤다.메뉴부터 사람들이 재밌을 게임인지 아닌지를 골라낼 수도 있기 때문에 많은 고민을 했다.그래서 처음에는 직관적이면서 쉽게 접근할 수 있는 메뉴 구성을 만들려 했는데...아니! 평범한게 아닌 좀 메뉴부터 기깔나게 만들어보고 싶었다.그래서 일지 제목이 저런것이다... ㅡ ㅡ이제 어떻게 개발을 했는지 자세하게는 못하지만 중요한 부분들만 한번 말해보겠습니다.기깔나게 만들기 위한 첫걸음은 유튜브를 돌아보는 것이었다.일단 레퍼런스가 언더테일이기에 언더테일에 관련된 유튜브를 돌아보았다.그렇게...2000년이란 시간이 지난 후...엄청난 것을 찾아냈다!바로! 팬 애니메이션이였다! 언더테일의 전투장면 처럼 좀 더 퀄리티 있게 만든 애니메이션이였다.그 부분에서 버튼이 이동을 하고 텍스트가 변경되며 ..

첫 발걸음을 내디며! 오늘은 스플래시 화면을 개발해 볼려합니다! 짝짝짝스플래시 화면에는 어떤것이 들어가야 할까요?제가 찬양하고 있는 갓무위키로 찾아본 결과!라고 합니다. 역시 갓무위키 난 있을거라고 믿고 있었어!한번 저의 게임에 적용을 해봅시다.저는 일단 먼저 순서도로 표현을 해보겠습니다.이런식으로 순서가 진행되도록 개발해 보겠습니다.[SerializeField] private Image panel;먼저 슬라이드와 페이드 인이 되실 panel이라는 Image 변수를 만들었습니다.private void StartSplashSequence(){ AnimationUtility.SlideAnimation(this, panel, 5f, 0.5f, 1, 0, 0, null, OnSlideComplete);}이..

현재 ShootingTale에서 알파? 데모? 느낌으로 개발을 완료했었는데...이게 참... 제가 봐도 너무 구조적으로 엉망이라서 재개발을 해서 더 좋은 게임으로 만들려합니다!원래는 구조가 잘 짜여져서 유지보수를 높여주면 좋겠지만...처음부터 그럴수는 없겠...죠? ㅎㅎ그렇기에 구조를 변경해서 다시 개발 해볼려합니다!이번에는 개발 일지를 써보며 가능하다면...보시는 분이 있다면...피드백도 받아서 참고하고 싶네요!잘 부탁드립니다!

나는 노래를 듣는 것이 좋다! 그래서 노래를 들으며 개발 할 때도 있는데, 이게 정말 도움이 될까? 생각해 봤다. 일단 한마디로 말하자면 너 원하는 대로 해라~ 이게 사람마다 다르기 때문에 솔직히 정답을 꼽기는 힘들다...게임으로 비유해보자!내 기준으로 설명하면 음악을 들으면 버프를 얻을 때가 있고, 디버프를 얻을 때가 있다.버프를 얻을 때는 기분이 좋아져서 개발에 흥을 느끼며 하는데,디버프를 얻을 때는 버그가 난 곳이 어디인지 몰라 찾고 있을 때 집중이 잘 되지 않는다.지금 솔직히 내 말에 공감하는 사람이 있을 것이다.그래 당신은 F성향을 가지고 있는 것이야 ㅋㅋ흠...혹시 내 경험과 다른 경험이 있다면 댓글로 남겨주길...같이 공감해봅시다!

개요항상 UI 애니메이션은 Dotween이나 유니티 자체 애니메이션 시스템을 써서 구현해왔습니다.두 방법 다 장단점이 있지만, 프로젝트가 커질수록 불편한 점이 자꾸 생기더라구요...1. Dotween을 사용할 때의 불편함Dotween Pro를 주로 사용했는데, 대부분 컴포넌트로 붙여서 사용했어요.그래서 코드로 실행은 편했지만, 애니메이션을 수정할 일이 생기면 하나하나 찾아 들어가야 하는 번거로움이꽤 컸습니다.2. Unity 애니메이션의 단점Unity 애니메이션 시스템도 물론 좋지만, 타이밍이 중요한 애니메이션에서는 조정이 너무 번거로웠어요.예를 들어 Image가 오른쪽으로 이동한 다음에 Slide가 끝나야 한다면각 Clip의 타이밍을 수동으로 계속 조정해야 해서 일일이 애니메이션을 손으로 맞추는 노가다 ..

드디어! SOLID의 마지막 원칙이다!!!바로 DIP(Dependency Inversion Principle) 의존 역전 원칙 이다.처음 이 이름부터 봤을 때는 인터페이스 분리 원칙과 다르게 이게 뭘 하는 원칙인지 감이 안 잡혔다.그래서 넘어가자~그러면 게임의 아이템 시스템 구조를 짜다가 머리를 뜯게 만든 장본인이라는 것을 알게 될 것이다.(내 이야기임...)그래서 의존 역전 원칙이 무엇이냐...상위 모듈이 하위 모듈에 의존하면 안 된다. 둘 다 추상화에 의존해야 한다. 이러고 있네...그게 무슨 말인지 알기 위해 내가 짰던 코드를 되집어 보자...public class GameManager : MonoBehaviour{ private ItemDatabase itemDB = new ItemDatab..

SOLID 원칙 중에서 ISP(Interface Segregation Principle) 인터페이스 분리 원칙을 처음 봤을 때는이건 그냥 인터페이스 관련된 원칙인가 보네 하며 넘겼다.근데 실제로 내가 작성한 유니티 코드를 보다가, 와... 이거 ISP를 제대로 안 지켜서 진짜 난장판이네 하고 뒤늦게 반성했다.그때 만든 모든 기능을 다 갖춘 슈퍼 클래스가 아닌 슈퍼 인터페이스 때문에, 유지보수가 HELL...그래서 인터페이스 분리 원칙이 뭐냐?클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 것인데 말이 너무 어렵잖아...그래서 그냥 내가 만들었던 시스템을 따와서 보자처음에는 IUnit 이라는 인터페이스를 정의했다.public interface IUnit{ void Move(); ..

요즘 객체지향 설계를 좀 더 제대로 이해하고 싶어서 SOLID 원칙을 공부중이다.그중에 LSP(Liskov Substitution Principle) 리스코프 치환 원칙이라는 게 있는데...처음에는 이름부터 이게 뭔지 싶었다. 약간 외국 사람 이름을 따온 듯한느낌?...근데 진짜 이름을 따온 거네? ㅋㅋ그래서 이 리스코프 치환 원칙이 뭐냐부모 클래스를 사용하는 곳에 자식 클래스를 넣어도 문제가 생기면 안 된다는 것인데... 예를 들어, 내가 이런 상속 구조를 만들었다고 가정해보자public class Bird{ public virtual void Fly() { Debug.Log("새가 난다요!"); }} 그런데 나는 Penguin도 Bird니까 그냥 상속해버림public c..

게임개발 중 몬스터가 플레이어를 공격하는 로직을 만들고 있었다.처음에는 몬스터가 그냥 근접공격만 해서 if문과 enum을 조합한 로직으로 개발하고 있었다.if(attackType == AttackType.Melee){ MeleeAttack();}근데 나중에 원거리 공격, 범위 공격, 도트 공격 등 여러 공격이 추가되며 if문을 switch-case문으로 변경하였다.switch(attackType){ case AttackType.Melee: MeleeAttack(); break; case AttackType.Ranged: RangedAttack(); break; case AttackType.Aoe: AreaAttack..

요즘 만들고 있던 캐릭터 시스템이 점점 코드 덩어리가 되어가고 있었다.PlayerManager라는 클래스 하나에 만들고 있던 캐릭터 시스템이 점점 코드 덩어리가 되어가고 있었다.PlayerManager라는 클래스 하나에 스탯, UI등 다 몰아넣었더니...수정 할 때마다 코드가 꼬이며 내가 짠 코드인데도 뭐가 뭔지 모르게 되어가고 있었다.그래서 내가 짠 코드가 잘못된게 아닐까 싶어서 찾아보다가SRP(Single Responsibility Principle) 이라는 단일 책임 원칙이라는 것을 알게 됐다.단일 책임 원칙이라는 것은 하나의 클래스는 하나의 책임만 가져야 한다는 것이다.예를 들면 스탯, UI등을 하나의 클래스에 모두 때려 박는 것이 아니라 각 클래스를 만들어서 다뤄야만 하는 것이다.이건 내가 바꾸..