Neon 0.3.2 released

[getter77]

http://neon.kosmonet.be/
http://roguebasin.roguelikedevelopment.org/index.php?title=Neon

Backend updates:
   - primitive sound support
   - TwoWayMap
   - scripts on regions
   - better tracking of changes during gameplay (e.g. map saving)
Gameplay updates:
   - better AI that uses spells, doors, weapons and A* pathfinding
   - levelling system with classes/feats/traits/abilitie/powers
   - random quests, dungeons (with themes), towns, wilderness and swamps
   - alchemist and healer services
   - creature types and subtypes
Improved neon editor:
   - make mods from scratch
   - mod packing and unpacking
   - export maps to svg format

Due to the changes to the data files, the editor can become unstable. Save frequently.
Not all new features have been incorporated into the editor yet.

It is my supposition that with each release, especially meaty looking ones like this one, this crazy engine thing takes some eyebrow-raising strides forward to really be "A Thing" of import.   

[jocke the beast]

Cool.
Would be cool to see more roguelike-engines that are "easy" to use.
Personally I think "someone" that has the skills (unlike me) should really make one that works. Could result in alot of new mini-roguelikes with cool new stuff & inovations.

[getter77]

Yeah, it is pretty hard to imagine one ultimately opening the door wider than the goal for this one about making a Roguelike without needing to write any code.   From there, I guess it would be just charging forward with UI and straightforwardness on top of keeping the featureset fresh.

[Bear]

I guess everybody has to decide where to put the boundary between engine and game.  If you're making a conscious decision that the game developer doesn't have to write code in your development language, that's fine.  But you have to provide a robust framework in the development language.  Depending on what you want the game developer to be able to do, you usually have to also provide a programming language (or more than one) so that they can design complicated interactions. 

Different game frameworks/engines provide for game developers to create individual content in different ways.  Crawl has its "vault" language, Angband has a bunch of different datafile formats, TOME has LuaScript, and so on.  To me, the crucial thing to recognize is that game content is, or at least can be, complicated enough to require programming, so if you *have* content that complicated, the game developer has to have access to a programming language, and has to write code in it.  It can be an language more suited to the problems you're defining, or have restricted complexity/capabilities, or any of a bunch of things to make the game content easier to develop. But there's a certain level of complexity you just can't pass without using a programming language or something equivalent.  Programming languages, after all, are just tools for managing procedural complexity.

In the software industry we see tools, every so often, that say you can develop complete applications without doing any programming.  They are invariably wrong.  They're either unusable for anything outside a very narrow class of programs, or they're just reframing the complexity-management in a different programming language while pretending that the "configuration files" or "webpages with extensions" or "Database table layout" or whatever, despite equivalent complexity management, aren't actually programming.  I really wish new middle managers would quit getting sucked in by those, because they make my life as a programmer actually harder.

Bear

[getter77]

Also makes sense.  Somehow, I get the feeling that this one is aiming to be more of a well constructed..er...."springboard" moreso than a one size fits all pair of pants---maybe something akin to the whole AngbandBase notion the folks over at Oook/Rephial have been hashing out of late?  I'm guessing messing around with exposed XML files mainly has to do with the nature of the formatting/structure and is something similar to the few relevant games that let you mod a great deal of features via .txt files using Notepad or some such----though not so much in the way of actually adding new content or culling/warping features outright.

I'd say another part would come down to what team members/good ideas they wind up with by, say, year's end as there's no telling when a timely inclusion or so could jump it all several spaces forward, even if just in a single area.  If they can manage the heft of being able to respond to user needs of future game makers in terms of adding/fixing/etc, well, good on them as that would be nifty as the near future strikes me as a good a time as any for a Roguelike-oriented denizen for the very visible "engine" pool that the likes of Unity3D/Torque/UDK/etc in terms of casting a wide net while intending to keep an eye on it and whatnot---I also suspect the whole Doryen Library apparatus can/will make inroads towards this territory as well.  The more useful tools, from varying approaches, the better as there's no way to tell which, if any, might happen to spark something randomly to very interesting ends. Like, how I understand it, the whole Demoscene thing served to accelerate evolution a fair bit on this and that as they tried to do random,  new things while melting as few things as possible...

[Bear]

I think different developers will probably prefer a choice of several different "engines" because each will have different sets of things you can do and things you can't do, and how hard it is to do each.  Each of us is developing, not just for our players, but for potential variant makers. And each of us has development goals that will appeal to different variant makers.

I think most variant makers approach the process with a strong idea of what kind of game they want to make and what coding languages and effort levels they're comfortable with, and pick the game or engine that suits their needs as a starting point.

As a primary developer creating both a game and its engine, I had a very specific vision for a game.  It's written in C, runs in a text terminal, works over ssh/telnet, uses Unicode, supports arbitrarily complex interactions between player, items, monsters, and dungeons, and conforms to a particular ideal of moddability.  The particular kind of moddability it has is that diffs which add content can be guaranteed not to interfere with one another.  But I assume the modders must have a working build environment and C compiler, and so far don't bother with script languages or parse text files other than the "vault" sublanguage.

This will appeal to and enable some variant makers, but it will repel and hobble others.  A different game or framework will appeal to a different set of variant makers, because it starts with a different vision of the game itself and how moddability works for that game or framework. 

Bear