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:
- The T-Engine and Tales of Maj'Eyal reaching version 1.0
- History of the T-Engine and how it was made
- Games (aka "modules") made in the T-Engine to date, including Bone Builder, Hellfire, Fae, Equal in Death, phage, and a whole bunch of Darren's games
- Code from scratch vs using an engine, and in particular the advantage of an engine for a 7DRL
- Why the T-Engine has succeeded where other generic engine attempts have failed, in particular the ability to cannibalise code from ToME
- Flexibility of the engine, and built-in features including easy interface, real time and hex-grid options, particle effects, shaders, cross-platform out of the box, multiple field of views algorithms, map generators, auto-explore, character saving, etc etc.
- Problems with the base example module provided for developers (and some agreement that we should maybe make a better one)
- How to start out in making your own module (mostly muck about and copy-paste till things make sense :-/)
- Some of the help available: the LuaDoc of the engine functions, a wiki guide, the module forums, #tome on irc.rizon.net
- The highs and lows of Lua permissibility, and some tips on bug-fixing in the engine using the Lua console (ctrl+L in-game with cheat enabled), a gdb debugger (remdebug), and short-cuts to restart char (ctrl+shift+alt+R) or restart game (ctrl+shift+alt+N) after editing code whilst the module is running
- So many particle effects! (in true Juice it or Lose it style) And cool shaders too.
- Online and network support (and its limitations)
- The module making competition with a €500 top prize from DarkGod for the best T-Engine game made by November 2013
- Everyone's plans for the Seven Day Roguelike Challenge, which has been announced for March 9th to 17th
- Some other tips and tricks and recommended software for development, including SublimeText
- Licensing, GPL3 (which requires engine games to be open source) and ToME resources
Join us next time for a discussion of libtcod!
Ah! I've been looking forward to the engine coverage! Great to see you're giving each Engine its own episode!
ReplyDeletenice episode, good to learn about t-engine. and the 500 euro contest! will be looking at it for my first 7drl for sure.
ReplyDeleteit's funny to hear you guys arguing about "get it working from the start with hack-and-slash coding" vs a programmer-centric "plan for the future." I think I've had that discussion more often than I can count. for game programming, it's often great to be able to "push paint around on the canvas" as quickly as possible, when you're in that initial frantic stage of design. that said, as a programmer, I know that doing things "the right way" is often a force-multiplier of sorts down the road. the debate continues....
one thing: you mentioned how annoying it is when you misspell a variable, and Lua assumes it's nil and kind of just silently fails later at some point; there's some magic you can include at the top of your code that makes variable usage more strict, and throw an error if you try to access a global variable that doesn't exist: https://gist.github.com/kevinw/4721150 —try it out! it's been super useful in the game I'm developing.
let us know if those t-engine example modules are updated, I'm looking forward to that! also for mass effect the roguelike.
I have about 30 minutes left of this episode, but just wanted to chime in and say I've found it very interesting so far!
ReplyDeleteAt one point you started on the difficulties of tracking errors and debugging in Lua, and I just wanted to point anyone interested to probably the best book on game programming out there, Game Coding Complete, by Mike McShaffry, of Origin Systems and Ultima fame.
In his book he has a chapter on Scripting with Lua, which I can highly recommend reading, where he touches on debugging. He presents one solution above any else, which is a complete Lua-centered IDE solution called Decoda by Unknown Worlds. Let me list some of it's features:
- Edit text with color coding.
- Set breakpoints, halting execution of the main program.
- Edit and view data on the fly (even tables!).
- Manager files within a project.
- Integrate with source control.
- Walk the call stack.
- Step into, out of, and over functions.
- Debug multiple virtual machines.
- Support dynamically linked or statically linked Lua libraries.
- You can even attach a (code) debugger to the process during runtime.
...all within a single self-contained editor.
You can check it out here:
http://unknownworlds.com/decoda/
Sounds interesting! However, I will note that some people like me use the T-Engine because we're not that comfortable with advance coding stuff and just want to hack around and make stuff work. Fancy IDEs can have a lot of nice features, but also get in the way immensely. I am most at comfort with just Notepad++ ;)
DeleteNotepad++ or Sublime are excellent editors too no doubt :) When I used Lua last, I never bothered with Decoda either, and just ran with Notepad++. The sound of proper intellicense and auto-complete do sound very tempting though, and would be of great help regarding those nil variables.
DeleteI see the same thing with Unity3D. There is a plugin for Visual Studio that allows you to break into the script code and watch variables, etc. But I still use the Mono Develop IDE, which is quite similar to Notepad++, for most of my scripting, and resort to printing to the console window to debug things... It's nice to have the slightly more advanced debugging option at the ready though when you're tracking those particularly nasty bugs that can be almost impossible to find without proper tools.
When doing my C++ coding, I use Notepad++ for all my CMake project setup. Love how wide support Notepad++ has for color coding all sorts of languages and syntax.
GVim. It's a graphical version of Vim, the spiritual successor to the famous UNIX editor 'vi'. Of course, if you want to use it right you'll avoid using anything other than the keyboard (that's where the power comes from).
DeleteYou've never been as productive as this fellas. I can guarantee you that if you can just get into the *basics* of Vim you will be more productive than you've ever been with a lousy IDE!
Use Vim! http://www.vim.org/about.php
Have there been any roguelikes made with coop/multiplayer btw? I'm building mine around a server/client model, both because I like the seperation that it enforces in the architecture, but also because I'd like to experiment some with coop in roguelikes.
ReplyDeleteTomeNET is the only active one I know of. There have been several attempts such as TwilightMMO but most failed at early stages or couldn't get enough player support to establish a community.
DeleteAlso it's very hard to get right with turns etc. If you can manage it then I want you on the show :P
Quite interesting that you touched on this topic for the T Engine, since I presume it wasn't designed with a multiplayer model in mind? Even though it has some multiplayer aspects incorporated, like the irc chat client and the profile server, I have the impression that the gameplay was never design to sit on a server seperate from the clients? Then I guess such measures to prevent cheating isn't that important unless you have a PvP aspect about the game...
DeleteT-Engine has community features, not multiplayer features. Chat, info sharing, stats, online character sheets, etc. It never had any real multiplayer support in mind, and is completely not set up for it. Not to say it can't be done, but all the hard work of server code and client management would have to be done from scratch.
DeleteNetwork stuff is hard shit from what I understand. I wouldn't touch it with a 20 foot poll myself!
Thanks, will have to check out TomeNET and TwilightMMO then :-) I think PvP could be hard for that RL feel, but do have some hopes for more coop oriented gameplay. The wait for turns is definitely a potential problem, so quite excited about doing more experiments with it :-) some of my more fond memories from MUDs though, was helping out new players learn the complexity of the game, or receive that help myself, which often far exceeds the help from a tutorial or documentation, so I do think that it has great potential in a genre like this, with such complex gameplay.
DeleteSeperating the view from the gameplay also permits multiple specialized clients fairly easily. So there's the possibility of having an ASCII client and a 3D client using very different technology, but respecting the client server model API.
I'd love to be on the show if I had something to talk about :-P For now I'm still learning and experimenting :-) I'd probably be the first on the show who was introduced to this genre mainly through this podcast!
Hehe, and yes, network code does complicate some aspects, specially in how one has to respect the multiplayer aspect when designing gameplay, but the enforced seperation of the architecture is sooo nice once it's up and running.
DeleteOther than zone instancing and player handling, the server is pretty much pure gameplay coding, while the clients are focusing on presentation and input handling.
A bonus is of course that one could play the same character from multiple computers, and prevent savescumming, so even if the gameplay is single player, the client/server model could be very nice to have :-)
Quite interesting to read your four year old thoughts on this concept, Darren. Are your opinion on the matter unchanged?
Deletehttp://kharne-rl.blogspot.no/2009/02/gameplay-idea-3-cooperative-multiplayer.html?m=1
Quite interesting to read how TomeNET is an old ToME fork, and MAngband of course.
But yeah, this is getting off topic so I'll get back to my experiments to emerge again when/if it comes to fruition.
Yes, my views there are the same as now. A big part of normal roguelike play is control over time - you move quickly when simply exploring or ploughing through weak enemies, you slow down when in tough battles and making hard decisions. FTL captures this flow perfectly. How can a multiplayer game do this?
DeleteOne method is to be asynchronous - other players can be 5 turns ahead before they have to wait on your turn, for instance. This wouldn't work for PvP of course, but could be a way of doing cooperative multiplayer. For PvP you need either real-time with every decision quick and easy (and auto-battle/auto-move) or you need turn-based with every decision slow and careful (minimal exploration, difficult battles).
I find that Roguelikes is one of the few, or only, genre that truly respect the players' time. I can play 15 minutes of tome, auto-explore to the interesting parts and truly get value for time. It doesn't throw hours of samey monsters at you either, but mix simpler monsters with harder ones, to such a great effect that I'm always on my toes! It's all I want in a game tbh... and is why I've been stuck playing Counter Strike for way too long (it respects short play sessions).
DeleteI'd think that while there's no monsters in any player's vicinity, the game might as well be realtime, dare I say Diablo style. From the MUD genre, I'd also like to borrow the idea of group/party leaders and follow commands, where one player steer others around to the interesting bits of the game, auto-exploring if you will.
Then it would be turn based for encounters, with high focus on player player interaction, like in magicka for instance.
I have the impression that most players cooperate with some form of voice chat these days anyway, so I could see vocal planning and synchronizing of moves/choices as paramount to success. Then the remaining problem would be the boring encounters, which I think are important to the pacing... So maybe a semi-turn based with auto timeout of a turn, and then a pause button for true turn-based could be a better option...
It's still too early to tell though, in my experiments... Perhaps it's not really an achievable goal at all... Or perhaps a feature that would rely too much on wide spread success to ever get off its feat... Ideally I would like a game where I could solo dungeons and coop dungeons, and the game would generate the content to challenge me while not overwhelm me either way. Roguelikes should be perfect for that at least :-)
Last, I don't want to get into PvP, because it enforce so hard balance between classes and skills. I'd much rather have a fun coop environment with interesting interactions between player skills and classes, items and environments that a lot of gameplay could emerge from it without a perfect PvP balancing requirement... A concept that will probably take years to complete though, butt we'll release early :-P
You could use some kind of shared Action Point pool system. Every time all the players combined take X actions the monsters get a go.
DeleteYou could further limit so each player can only take one combat action per turn, but spend as much as they like on movement. For the most roguelike experience set Action Points = #players, but you could play with it a little move I think.
Obviously it'd need to be very co-operative (probably on voice comms) to work well but it does mean you don't need separate combat/exploration modes and could open up interesting group tactics.
That's actually a really good idea, John. Will definitely have to give that a go. It wouldn't cripple either player if one had to idle or had connection issues. Yeah, this might actually be the best idea to solving the problem I've heard of.
DeleteGlad I could help :)
DeleteLike you said though, it would probably require voicecom to really work, with PUGs it might end up a bit frustrating... So I wonder if a system that had individual action points that were on a timeout, where when timed out they would end in a shared pool, one action point at a time. Might be closer to a system that could work in both situations :-) we'll see!
Deletehttp://www.knightsgame.org.uk/
DeleteI think this is the closest you can get to a multiplayer roguelike that is actually fun.
Roguelikes, due to their complexity, should probably be turn-based by nature.
You should definitely play Knights though. Not just Trefall, but the hosts of Roguelike Radio, too. I think it could open up your eyes to a lot of cool concepts that you could tell aspiring roguelike developers about. I think this philosophical discussion on game design you often devolve into is very important for spreading ideas.
Knights is a very original game and should definitely be looked at. It's definitely a 'hybrid' roguelike, but a lot of its concepts can be applied to proper roguelikes. Definitely check out Knights (link at the top of this comment!).
I really hope that there will be a better example-module. Perhaps also more clean (in style) as in a "ordinary" roguelike and not look so much TOME (think original rogue or similar with no particles and popups etx).
ReplyDeleteGreat episode!
Agreed. Last I evaluated the T Engine I never really got properly started on anything due to the steep learning curve. I found libtcod quite a bit simpler to get started with. At that time I mostly looked at the example module.
DeleteSince then I've started to play and enjoy Tome4 though... so I guess my motivation for learning it properly would be greater if I tried now, because Tome4 is truly a masterpiece :-)
Off-topic: the link to the Rogue Basin episode index redirects to the main page; it should be http://roguebasin.roguelikedevelopment.org/index.php?title=Roguelike_Radio instead.
ReplyDeleteOoh, well spotted - thanks!
DeleteJust wondering, I've been to the UK a lot and I cannot recognise Mr Grey's accent. I'm assuming... West Country? Possibly Yorkshire?
ReplyDeleteHaha, no, I'm originally from Dublin, Ireland - not UK at all!
Delete