Vengeful Part 1

This past couple weeks I’ve worked on fleshing out my failed 7-day roguelike game: Vengeful.  Its been gratifying to see how much I’ve been able to get done, but there is also much to be finished. For some reason though I feel like I’m making more progress than I seem to with some of the other prototypes that I have in my library and that’s a good thing. The first thing I got up and running was a crude inventory system because every roguelike needs an inventory of some kind right? The next thing was implementing path-finding for monsters. This turned out to have a secondary benefit as I was able to use the same path-finding to enable click to  move for the player.

Mouse Input Test + Nicer Tiles

The inventory worked pretty well and I continued to find and squash bugs with it. One thing, though, that annoyed me was the use of modal windows when equipping, dropping, or using items.

More inventory stuff, still with modal windows

The next thing I turned my attention to was the lack of a title screen and save-game capability. With some of my previously-written Unity libraries, the user save-game turned out to be pretty easy. The title screen, while fairly simple was fun to do and as an extra benefit, caused me to improve some of my existing library code for screen fades.

The title screen as it is currently

Not bad I thought. The next thing was to improve the inventory and UI system some more. I added some inventory buttons, moved the player’s stats panel to the upper right of the screen and removed the modal windows.  Adding items to the game isn’t too difficult but I wanted more flexibility, so I took a look at Moonsharp and integrated it into the game. It’s a version of Lua written in .NET and compatible with Unity. It’s working out quite nicely and now I can do all sorts of interesting things with items and whatnot when I get around to it.  Because of the UI changes I was also able to compile and play it for Android. Exciting!

No more modal windows … at least not for the inventory UI

My current dungeon generation uses cellular automata to dig out the level, but today I started looking at a different approach. I’ll leave you with a screenshot of some prototyping I’ve been doing today in regards to that. The little animated guy is just for the prototype … although … some animation would be cool … hmmm …

Posted in Blog, Development

The 7-Day Roguelike (2017 Edition)

I’ve entered … hold on … let me check … 23 Ludum Dares and completed 23 compo entries. I feel good about that, so when this year’s 7-day Roguelike compo began, I went for it. I had worked on something for the 2015 7DRL, but due to a death in the family, I was unable to finish.  To spare you the read, I did not finish this year. If, however, you’re interested in my thoughts about a 7-day game jam, then read on!  Is anyone still here? Oh! I see you raising your hand in the back there … thanks for staying.  Anyway, let me start by saying that I approach every game jam and project with the intention of learning something new whether it’s a new way to code, new language, new tools, new art techniques, or whatever.  With that in mind, even if I don’t ultimately finish a project and manage to submit it, I can still feel like I’ve accomplished something. I’m taking away several of those things from my 2017 7DRL project which I entitled “Vengeful”. I think, though that you might be more interested in what I feel ultimately led to me not completing the 7DRL this year. The thoughts below could apply for any time-limited game jam you may find yourself in.

7 Days is Too Much Time

Coming from Ludum Dare, 7 days seems like a huge amount of time. You should be able to do so much more with that 5 more days, and you can, but not as much as you’d think. Scheduling and prioritizing tasks is pretty crucial in these types of exercises, but there is something different about the craaazy quick pace of development when doing a 48-hour Ludum Dare vs a 168 hour 7DRL project. With only two full days, many ideas for features and additions go into my brain on one side and pass right out the other. The mental filter for features/ideas I can fit into 48 hours keeps all but the most simple things out. Feature creep can debilitate your project and be the difference between a successful submission and a failure.  For some reason, the 5 extra days seemed to loosen that mental filter for me and allow tangents that would sometimes sink several hours. Normally, I write down a list of minimum features and requirements that must be finished for the project to be considered completed.  I do this with Google Keep, and it really does help with the focus aspect. Plus it is fun to be able to cross off items on the list when you finish, so you can see progress. Lesson: Plan your time, use TODO lists and finish the absolute minimum FIRST.

Art? It’s more about the story and RPG mechanics

I though that it would be fun to draw my own art for the game, and it was.  This was one of those decisions that I learned from and got some good pixel art practice, but that contributed to my eventual failure to produce an entry.  According to the rules I could find, you can use existing artwork and I saw several people using existing tilesets from opengameart.org which was a good idea. Roguelikes are somewhat of a different beast than your normal match 3 or platformer games in that there needs be story-driven elements along with an interesting RPG system. The writing element is a much more important part of the process, so much so that, if you have a good story and good game mechanics, the graphics can largely be ignored. That is a key feature of all of the best old-shcool roguelikes (my two favorites are Brogue and ADOM) wchi have ASCII graphics, but interesting storylines and RPG mechanics, procedural generation, random items, etc. Lots of content. Much more than most other games. These elements should not be ignored and certainly not sacrificed for some non-ASCII graphics. Lesson: work on story, RPG mechanics, and content (items, monsters, etc) then if time allows (which it won’t) do your own art

Preparation is Key (when is it not?)

Although I’ve been dabbling in Lua and the Love2D framework, I decided to use Unity3d since I’m quite familiar with it. This was a good decision, but I should have considered the complexities of a roguelike combat system ahead of time.  Making a combat, creature, and item system that is simple, flexible, and enjoyable to play within is not something that I can do in 7 days. Not at least with all the other work that needed to get done.The RPG system code is a crucial piece and not something you see in other genres.  I did have some code I had created for cellular dungeon generation a while ago that I dusted off, but even that required a bunch of fixes/additions.  Aside from my basic generic C# Unity3d game framework, I had to create all the code from scratch, and while fun, was not the best use of my time. The 7DRL rules does allow for use of external libraries and pre-existing code which I did do, but there were still too many other code pieces I ended up having to create during the 7 days.  Lesson: Assemble/create your code base several weeks beforehand so you have time to make it good and solid. That way you won’t sink too much time into improvements/fixes during the competition.

 

Well that’s all I have for now. I’m not sure what I plan on doing with Vengeful. I still have several ideas about mechanics and things that I’d like to add. If I do anything interesting with it I’ll be sure to let you know, but for now I need to get back to work … making games …

Posted in Blog, Development, GameJams

Video production

So far, recording and editing these Love2D YouTube tutorials is fun, but it sucks up a good amount of time. This is especially true when you are doing coding videos and you aren’t exactly sure what your final product is going to be. I’ve found what seems to work best is sitting down, figuring out what I want the episode to be about, writing the code for it and making sure it works, then re-creating that while recording. This essentially means re-writing all the code I just wrote again, and sometimes I’ll change my mind in an episode and write parts of the code in a completely different way. It’s a lot of effort, but it is nice to have a “released product” video or two by the end of the day. I have even finished several episodes and uploaded them only to rethink what I had done and scrapping them. Last week, I also put the code for all the episodes I’ve created to date to a github repository. That took a decent amount of time as I didn’t do a great job of keeping zips of the code for each of the videos, so I had to recreate several of them from scratch. I also improved my VSCode plugin for Love2D by adding the ability to open a webpage for the love2d function the cursor is on. My journey with Love2D has been enjoyable as it is a different beast from Unity 3d, but I will be working on some C# goodness this week as I will try to participate in the 7-day rogue-like challenge 2017. We’ll see how that goes…

Posted in Blog, Development
Social media & sharing icons powered by UltimatelySocial