It has been three weeks since the last blog post, and much has changed in Vengeful since that time. I’ll run down a few of those changes/improvements.

I’ve added a field of view to limit the visibility of the area to that which the player can see.  This changes the gameplay significantly as the player no longer knows what is around the corner.

Monsters can now occasionally drop items, and some now have natural attacks such as sharp teeth, horns, acidic ooze, etc.

The title screen now uses an actual font for the title instead of the previous sprite title text. Many improvements have also been made to the UI which will continue to be improved.

I’ve added some armor items that will sometimes absorb damage from attacks. I still have much to do in this areas as I want to retool the combat and inventory mechanics to depend on strength in a different way.

There is now a choice to make when you best a level boss upon which I plan to build some interesting abilities,curses, detrimental effects, etc.  I also fixed an issue with the path finding and now monsters can cut corners. The player will also take advantage of this when using click to move.  The cave generation algorithm has also been refactored to allow for more flexibility. I want to eventually have locked doors and special rooms procedurally generated. I’ve also made the item system much more flexible by adding scripting to them. This opens up a whole new world of possibilities which I’m looking forward to exploring. In the coming weeks I’ll be working more on the item scripting system as well as dungeon generation refinements, and of course more bug fixes, etc.

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 …

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 …