You can download the mp3 of the podcast, play it in the embedded player below, or you can follow us on iTunes.
Topics discussed in this episode include:
- What is libtcod, its features and its history
- The motivation for a roguelike library/toolkit, the limitations of curses, and the failure of attempts at bigger generic engines
- libycod's particular suitability for 7DRLs
- Jotaf's popular python tutorial and other tutorials
- The advantages of python
- The dangers of concentrating too much on eye-candy (but oh how sweet it looks)
- The low number of mid-sized roguelikes, and the inability of many developers to show restraint
- The value of a restricted palette and good colour choices for both design and aesthetics
- Using Colour Scheme Designer for choosing matching colours (check out other web design resources too - they can be quite handy for text games)
- The high number and variety of libtcod projects, including a Wolenstein-esque FPS and a fast-paced scrolling space shooter
- Using Zeno's Necklace of the Eye as a tile frontend for libtcod games or for online capabilities
- Off topic discussion of MMO RLs...
- libtcod on Android
- Why Jeff is stopping using libtcod (for aesthetics)
- Some limitations with non-square fonts
- Comparing and contrasting the *band codebase, libtcod and the T-Engine, and the niches each fill, and the potential for expanded use of Unity in future
- A big thank you to jice for producing a library that has helped dozens of roguelikes get made! And will doubtless be key in several games being made for this year's Seven Day Roguelike Challenge in a few weeks :-)
Next up in our 7DRL 2013 build-up series is a look at how to make a *good* seven day roguelike, with an all-star cast of developers!
Thanks a lot for another great episode guys! LibTCOD was the engine that I first picked up for roguelike development, and like many others I got quickly caught trying to set up a graphics rendering pipeline in it instead of focusing on any gameplay.
ReplyDeleteUnity3D lacks a roguelike template right now, and could really benefit from that in terms of usage in the 7DRL. There are several nice script extensions for it, however, that integrates nice 2D style interfaces to work with, so it's very possible. But the lack of readily available FOV and such does give it a bit of a steep start for roguelike development.
On the other hand, it's got hardware accelerated physics, so doing ray casting test or box/tile collisions is very cheap. It's even got a particle system with collision support! On top of that its also soooo easy to port to multiple platforms. Web, mobiles, Mac, Linux, windows.
There are also so many editor extensions. Visual scripting with Playmaker, Client/Server architecture with all modern requirements in RoarEngine, visual shader scripting, in-editor game testing with pause feature, input handling for mouse/keyboard/gamepad/touchscreen with an abstraction layer... It's script engine is based on Mono also, so it supports scripting with C#, JavaScript or Boo out of the box, with multiple extensions, like python. Thus you can actually compile your scripts and get file/line pointers to errors or warnings... It's just such a complete game engine, but also very very intuitive to work with! The drag and drop feature of modules/components of logic to give game objects behavior really works well, and keeps you in control.
Unity just needs a LibTCOD style script extension for it to take off during the 7DRL I think.
Hi, i was really interested on the topic about why generic purpose engines since now have failed, do you have some more references, or can anyone be contacted on #rgrd to discuss the topic?
ReplyDeleteI don't have any definitive information, but over the years I've seen many many projects crop up saying they will be a next-gen roguelike engine, simulating muscle mass and all sorts. Usually there's a couple of updates to object building before it all goes silent.
DeleteSimple fact is you shouldn't make an engine without a game. It's very hard to stay focused on just an engine, and you have zero idea on what it should do without a game.
but isn't this approach a bit short-sighted ? i mean, in other games mechanics there are different engine that actually work, so why in a roguelike a similar approach shouldn't work? i mean: a framework which offers tools to develop the game mechanics shouldn't be a step forward ? it would allow the developers to put their minds not on the gui, the events, the file / object handling, but just the game and its mechanics
DeleteYeah, my experience is write games, not engines.
Deletehttp://scientificninja.com/blog/write-games-not-engines
It's such an easy trap to fall into though! And honestly, I'm not sure if a framework is enough to really produce larger roguelikes. For that, I could only image you'd want a fully fledged game engine with proper graphical tools set up around an underlying framework, that you can visually analyze and overlook the process.
Once a codebase gets large enough, at least I lose that kind of overview, and really need to rely on other ways of representing the code and data to retain control.
Like, if you have to venture into your codebase to tweak gameobject parameters, or you have to shut down your game and restart to test tweaked values... then that's not good for the long run. Same goes for statistical bits.
If I want to tweak some statistic, watching the curve change graphically really helps in analyzing the effect I'm actually applying to the system. As I understand it, T-Engine has a lot of such player-base analyzing tools in place, and I'm sure that kind of analyzing power has helped DarkGod immensely when balancing and tweaking numbers.
The tools and engine you choose really should depend on your game complexity and requirement though. Making a 7DRL, I doubt you'd really need that complex set of tools as you would making Tome4 :)
stormssont: I think a lot of engines have ended up with design creep - trying to do way too much and be far too generic. And without a game to drive development forward and build up community support it's way too easy for an over-scoped engine to collapse beneath its own weight before it sees the light of day.
DeleteThe T-Engine succeeded because it had a game on top of the engine. Plus the developer had experience of writing actual roguelike games, something many engine makers have never done. Trying to make a generic engine when you've never made a game is pretty stupid, in my opinion.
Trefall and Darren, thank you very much for your opinions, they are much appreciated.
DeleteI actually disagree with your points of view: i have a long answer,and tried to make a full point here if you are interested: http://killerproject.wordpress.com/2013/02/20/engine-or-not-engine/ .
( I put the link because it's a very long answer, please tell me if it's against the rules and i'll copypaste it here )
( i have no idea what i did with the account verification, i am stormssont , i don't know why now it appears the name of the blog )
DeleteI think part of the reason may be that there isn't really all that much *need* for a roguelike engine. It's not really like a 3D graphics or real-time physics engine which require a lot of specialist knowledge outside of what you need to be a decent programmer - for the most part if you're reasonably proficient at writing code, you can probably write a roguelike. In other words, they don't really lower the barrier to entry all that much - if you can make use of the engine you could probably write it yourself, and for a lot of people writing that sort of low-level stuff for themselves is a big part of the fun. I suspect a lot of these 'do everything ' engine projects fail just because there just aren't enough people who actually want them.
DeleteI'd imagine you're right Paul Jeffries when it comes to 7DRLs and smaller games. But the larger the scope of the game, the higher requirement I'd think it would put on the engine and tools you use to make it. Not that I've made a roguelike yet to support that argument :)
DeleteThough roguelikes usually don't have complex visualization or responsiveness issues, they have an unparalleled complexity when it comes to object and envirnoment interaction... and balancing that, or squashing bugs in such an unpredictable and complex environment sounds scary to me without the proper tools to ease the process as much as possible.
It's interesting that you say that, because personally I would go completely the opposite way - It's smaller projects (particularly 7DRLs) where I would find a pre-built engine most appealing since it would help me get up and running much faster. For longer-term projects I would definitely want to do as much as possible myself, since (relatively speaking) it's less of a time investment and so that when the unpredictable complexity stuff that you talk about inevitably causes problems I understand why it's happening and how to fix it rather than just hoping that whoever wrote the engine foresaw that particular issue.
DeleteI fully accept that I may just be a weirdo, however.
Yes, bug-tracking in your own code is quite a bit more comfortable usually. I just don't think I have the ability to write more robust code than a piece of code used by thousands of coders before me (now mainly thinking of Unity3D).
DeleteOf course, if you have a special requirement outside the domain of general approaches, you'll probably have to customize parts to those requirements... but I do like the fact that when I get a bug report, I can usually quite quickly determine whether it's caused by my code, or Unity3D code, and just pass on the bug for someone else to fix if it's Unity3D related (though usually it's not).
I'd guess you have the same thing in T-Engine. Code that has been through a project of the size of TOME4, tested by thousands of play sessions, is probably more robust than something one writes and test oneself, again, unless your project has some special requirement that requires customization of that code (one has to understand the impact-space of changing that code to ones requirements, which can be hard in a huge, complex engine that's written by someone else).
So in that respect I do side with your argument :)
Good episode, its interesting hearing stuff like this. I have dabbled in Libtcod and wish I had found it before I started working on my first, only, and sadly failed 7DRL instead of the random thing I found somewhere. Of course at this point I have successfully been caught in the desire to reinvent the wheel so have been working on getting some SDL thing setup for myself which if finished would probably be some bare bones tile engine thingamajig. Luckily I won't probably have that worked out by the coming 7DRL so I will be able to play around with Libtcod for that.
ReplyDeleteOn the topic of Unity, just wanted to add that there are some excellent noise resources for it.
ReplyDeleteCoherent Noise has an excellent manual I feel should be linked at rogue basin or something: http://chaoscultgames.com/products/CN/CoherentNoiseManual.pdf
Turbulence is another, that's based purely on usage of the GPU, and has a really cool web demo: http://dl.dropbox.com/u/9289442/WebPlayer/WebPlayer.html
So there are some interesting resources for Unity and RL dev there already.
these last two podcasts have been great! I somehow never knew these libraries existed... which is probably why I've only ever finished a single rogue-like before >_>
ReplyDeleteInterresting fact: both libtcod and TE4 are made by french people! :)
ReplyDelete