LÖVE

LÖVElike - A Roguelike Engine ("BÄRRELike" flavour)
Status: RIP / Halted / Semi-abandoned / Undefined Status

WARNING: This project is halted/abandoned/closed and probably won't be updated anymore since (almost) no one seems interested on doing roguelikes in LÖVE. Feel free to use any good part to do something "roguelikish" in LÖVE or in something else similar. And never forget that "making an entire other Lua roguelike engine" is worthless when "when the super awesome T-Engine exists" (Lap "dixit").

NOTE: I used the text editor Fraise (MAC) to indent and align code. Code should be aligned in other MAC code editors but in Windows ones probably all tabs and comment info are misaligned.

This project is optmized for LÖVE 0.62. Nightly build 0.70 misplace LÖVElike text.

-------------------
Concept and status

OBJECTIVE: Achieve a small prototype/engine of a roguelike game (turn-based hack'n'slash RPG with random map conception) done in LÖVE.

DONE: A very basic and minimal skeleton. For be truly a roguelike still misses random map generation. It's was tested enough and no bugs are present to my knowledge. You can play, move, destroy several "races" of barrels (random choices starting level 2) and kill final mob (at level 10) that blocks the final exit. All the map or mob parameters can be easily changed and you can easily switch graphics, enlarge/reduce map (at least 9x9 tilesize is advised for proper info/text read), change some mob parameters and final "escape" exit.

-------------------
Instructions for this example prototype:

PLOT: You are a barrel (no kidding). You went on mission to an archipelago to fill urself with Sacred Water. When you were returning back to home you notice someone sabotaged your comeback. You must destroy other barrels in order to get rips of wood and fix the broken bridge. Good Luck

KEYS: In game press 'h' (help) to updated key information
-------------------
Changelog

Replaced by 0.055 - Null, Paused, Help and Quit states/modes added. Extended Movement added. Flag to switch Extended Movement on/off. Additional keys set added.
Replaced by v0.054 - Offset really working. Increased map to test auto-expandability of the engine.
Replaced by v0.053 - Hypothetical boss bug avoided. Revised comments. Ended development.
Replaced by v0.052 - Even more revised and clean code.
Replaced by v0.051 - Cleaned and commented code for anyone who wants to use it or follow with the work.

Replaced by v0.050 - Intro/RIP/Endgame screens. Several bugs resolved. Fully playable now! Here ends first step of dev.
Replaced by v0.049 - Major bugs fixed.
Replaced by v0.048 - Converted to GameState switch. Totally broken.
Replaced by v0.047 - Endgame with final boss and escape, custom level mobs selection, another UI restyling, RIP/Sucess screens ("not working") and a lot more.
Replaced by v0.041 - XP Leveling, Leveling HP bonus, UI restyling, minor fixes.
Replaced by v0.040 - Sound Edition (movement and combat), minor fixes.
Replaced by v0.039 - Mob placement corrected, proper random values (thx Elvenrix), minor fixes and changes.

(...) older changelog removed

...................

yay! I love roguelike games (Angband is my fav)

Sugestion for the random seed:

mouse map scrolling is sweet.
You packaged the love wrong though.

TechnoCat wrote:mouse map scrolling is sweet.
You packaged the love wrong though.

Thanx. Did I? Well I warned to unzip and don't rename it. I download it for testing and all seem fine. A bit hard do it in another way on the Mac.

Elvenrix wrote:yay! I love roguelike games (Angband is my fav).

Well, that one was awesome years ago but no more a favorite any longer. And thanks for the tip. It did well the job. Things are fixed now.

Oh hell yes. Really excited to see where this one heads; I love me some roguelikes.

Guys, I really need help on this now! :/

Well, it could either be that your if in love.draw isn't right, or it could be the fact that you draw the debriefingScreen for exactly 1 frame.

arquivista wrote:
NOTE: Need Help! This is fully playable but have now the problem that I can't present the RIP and the Endgame Debriefing screens because I don't know how to pause and resume later with a key without Map display get over the Debriefing. Probably I have some problem I can't notice. I confess haven't figure out how to deal with pauses that clash with realtime love.draw and love.update. Can anyone tell me how to fix this? Also there is a tutorial that explain the LOVE way of "flow" code?

In programming we sometimes talk of state machines when dealing with solutions to problems like this. In game programming we also talk of game modes.

I think you need some game modes right now. People have written code to handle this for their libraries, so I'll let them show you how their solutions work, if any of them happen to be reading. I can explain one way to do it like this:

The basic idea goes as follows. You can set a new callback at any time by assigning to the suitable field. For example, to change the drawing code, just write love.draw = myNewShinyDrawingFunction and from that point on, every call to love.draw goes to the new function. Similarly, if you want to handle keyboard completely differently in your main menu as opposed to the actual game, you can have to love.keypressed/released callbacks and set them for use at the right times like so.

Every mode your game can be in is defined by what callbacks function are currently active. Transitions between modes may have further effects. You may want to stop or pause your music using love.audio.pause() or stop() at some point, for example. Every time your game has to change modes, you can just call a procedure that makes the appropriate changes. How exactly you organize this is up to you, but the people with libraries do have definite views for you if you want them.

If you think in terms of OO, you may want to define just one callback of each kind, and have it call a method in an object to handle the input, drawing, update or what have you. Then you just substitute the object with one that gives you the game mode behavior for each mode you need. Reading about the State pattern and MVC architecture will give you a lot more to go on. There's a bunch written about these topics. Remember that you don't have to over-engineer it for a fairly simple game, though.

Sorry for not posting code. I'm a bit too busy to write any now, and what I have written earlier isn't really suitable as examples.

In my "LoveWars" prototype I use HUMP Gamestate (gamestate.lua)
Are very easy and 'clean'
look here: http://bitbucket.org/bartoleo/lovewars/src

You don't have to 'work against' love.update and love.draw. You have to work with them

Game states is probably the way you should go. Have one 'Play' state and one 'Pause' state, and make love.draw and love.update do completely different things depending on the state the game is in.

The simplest way to do this is by using a variable.
Possibly refactoring if-elses out:
The same would happen with love.update, or any other function whose behaviour depends on GameState.

This structure is repeated so often in videogames that I've decided to provide a more high-level way of doing it, using MindState. See the "Game controller" example on that wiki page, if you are interested.