Topics

31

Traditional Roguelikes (Turn-based) / Guild

« on: February 01, 2014, 08:07:47 PM »

I downloaded and played Guild 1.03, then closed it. Now when I open it, all I can see is the cursor, no text is displayed on the black screen.  Any ideas?

32

Development Process & non-technical / Dev blog aggregator

« on: January 28, 2014, 07:27:11 PM »

Do you know of any interesting blogs where people discuss/post about the development of their roguelikes? I have an aggregator which collects these sorts of blogs, so people can go to one place to find them, rather than having to stumble over them individually.

Link: Planet-RLDev.

The reason I do this, is that once something like this builds up momentum, then rather than having to go searching for interesting blogs or stumbling onto them through happenstance, people tend to approach me and ask me to add them.  At least that's what I've found with my Planet-MUDDev.

33

Design / What does roguelikelike mean?

« on: January 20, 2014, 11:42:22 PM »

Exactly what a roguelike is, is contentious.  Given this, what exactly a roguelikelike is, becomes even weaker.

What makes a game a roguelikelike?

Does it mean anything worthwhile, or is the author unwilling/incapable to write an actual roguelike, and they're desperately clinging to the dream?

34

Traditional Roguelikes (Turn Based) / Write an article for Imaginary Realities, volume 6, issue 1

« on: December 20, 2013, 02:31:08 AM »

Are you involved with text-based gaming?  If so, whether your involvement is in mudding, roguelikes, interactive fiction, gamebooks, browser games or maybe even something else, please consider writing an article for Imaginary Realities.

Imaginary Realities is an online journal which originally ran from September 1998 to December 2001, primarily focused on mudding.  It has been revived, and had published a new issue just recently, which you can find here:

http://journal.imaginary-realities.com/volume-05/issue-01/

If you’re interested in the older issues, you can also find them here:

http://imaginary-realities.disinterest.org

Find more details about suitable article topics here:

http://journal.imaginary-realities.com/volume-05/issue-01/request-for-content/index.html

Please email me before writing an article, to confirm that the topic you are interested in writing about, is both suitable and within our range of coverage at this email address:

richard.m.tew@gmail.com

Articles should be in the range of 1000-4000 words, and need to be received by January 31st, 2014.  Longer articles are possible for serialisation, with approval required.

35

Traditional Roguelikes (Turn Based) / BrogueX 1.7.009

« on: November 01, 2012, 04:46:17 AM »

Code: [Select]

1.7.009:
- Update to Brogue 1.7 release.
- Added a directional movement touch mode.  More info within help menu item.
- Restored support for keys that require shift to be pressed (e.g. >).
- Improved pinch to zoom gesture support.  Maybe works worse.
- Added a help menu item to view instructions & controls.
The flu, conjunctivitus and blocked ears in quick succession combined to prevent me from finishing this.

Those with external keyboards can now use a wider range of keys, and should be fine for playability.  This without, with this release should find the game to be more playable especially on smaller screen devices.   To try that out, open the menus, select the options menu, then enable the move tapping layer.  Then Android UI buttons will overlay the screen and should allow play.

Note that with the move tapping layer, the screen is divided up into 9 parts:

NW|NN|NE
--+--+--
WW|??|EE
--+--+--
SW|SS|SE


When no UI elements are shown on the screen, tapping the corresponding part of the screen will move the player in that direction.

When the inventory is displayed, NN will move the inventory selection up, and SS will move the inventory selection down.  WW will back out.  So if an item details panel is displayed, NW, WW or SW will close it and simply show the inventory.  And then NW, WW or SW will close the inventory and return to gameplay.

If the screen is waiting for a mouse click, or key press, just touching anywhere on the screen will suffice.

https://play.google.com/store/apps/details?id=org.disinterest.broguex

Source code is published in the usual places, see links on the Play store page.

36

Traditional Roguelikes (Turn Based) / BrogueX 1.6.406

« on: September 28, 2012, 01:07:21 AM »

Hi,

This is the first post publication release of BrogueX that has a new feature or change worth mentioning

It is now possible to use two fingers (generally tends to be thumb and index finger) to pinch the touch screen, in order to zoom in and out the console.  And to use one finger to pan the console area displayed when it is zoomed in.

This takes BrogueX from being really unplayable on a smaller screened device, to only being somewhat less unplayable.  A lot of work is left still, and if you are one of those who purchased BrogueX for some reason, please feel free to email me with feedback so we can tweak this.  My email address is on the store page.

https://play.google.com/store/apps/details?id=org.disinterest.broguex

Cheers!

37

Programming / SVG fonts

« on: August 17, 2012, 10:04:49 PM »

Has anyone looked into or used SVG fonts?

38

Programming / Android and keyboards

« on: July 27, 2012, 09:00:39 PM »

I've spent quite a bit of time (around a day) trying to get the keyboard support in BrogueX working, and I thought I'd share my results.  At this point, I'm just looking into the support for entering text at prompts, like when you need to provide a filename to save your game recording.  Much of this applies to controlling the game directly though.

If the device has a physical keyboard, then you're almost fine.  It won't have some special keys that are important, like escape though, so if like in Brogue that is used to cancel or skip, then a change is required.

If your device does not have a physical keyboard, then the application can force the soft on-screen keyboard to be displayed.  Ideally, this would be used to send key presses to the application.  In reality, it has predictive input built in and you only get some random key events, like the space key.  Apparently you can bypass this by displaying a formal Android edit field and configuring it in some way, or getting the user to disable the predictive behaviour in their device settings (which is unreasonable).  You can also provide your own keyboard, in several different fashions.

Now there is Nethack for Android.  This supports key presses by providing it's own keyboard, and it does so in a way where the keyboard is always present on screen and does not take overlay half the screen like the system soft keyboards.  Basically, it is a scrollable row of specific key buttons at the bottom of the screen.

There seems to be something strange with the emulator and the default setup, as the initial input setting was Japanese and the soft keyboard just wouldn't display with it.  I know this because when I exited the application, I could see my soft keyboard sitting there open and displayed on the home screen and it was the japanese one.  The soft keyboard just didn't display in my application until I disabled all but the standard  input method.

Unfortunately, the way you have to discover all this is through a combination of trial and error, and haphazardly stumbling over a selection of blog posts and Stack Overflow questions & answers.  Pretty much par for the course in programming land 

39

Traditional Roguelikes (Turn Based) / Android BrogueX 1.6.401 (unofficial/approved Brogue port)

« on: July 26, 2012, 04:59:32 AM »

With permission of Pender, author of Brogue, I have released a (not the official) port of Brogue as a paid app on the Android market.

Note that it is expensively priced to discourage casual purchase, or haphazard installation.  You should only purchase it, and I would appreciate it - but be surprised if you did, if you wish to support and participate in the evolution of a native Android more usable way of controlling the game.  I would give out free licenses to suitable testers, but none are provided to Android developers.  As it is an open source game, and my Android-related changes to it and libtcod are also open source, it is possible to build a version yourself.  If you do, ensure it does not cause extra work for me or reduce the interest I have in taking this project further.  I have already invested quite a bit of time porting libtcod, and debugging it with printf statements because Eclipse cannot debug C code.  Good times!  I will not be making any changes whatsoever to gameplay except where it relates to being more easily able to play on Android devices.

At the moment, there are several features of questionable value.  They include the difficulty of picking the tiny tiles on the screen of a mobile device.  They also include the inability to do keyboard input.  And the inability to have the screen refreshed when you press the menu bar on the right hand side, get dumped to home screen and then reopen the application.  These will be reconsidered at my leisure, or perhaps slightly faster if anyone supports me by purchasing it :-)

https://play.google.com/store/apps/details?id=org.disinterest.broguex

40

Programming / Roguelike standards

« on: September 14, 2010, 09:48:48 AM »

Working on my roguelike, I find myself wanting not to have to make arbitrary decisions that would make my game differ simply through randomness, compared to other roguelikes out there.  To me, there is great value in some specification that lists the standard choices made in implementation.  By adopting these, or keeping as close to as possible, to these, a game author could make their game more approachable to players.

Just to be clear on what I am referring to.  Take @ for example, it is as far as I know, the standard symbol for the player character.  Is there a page somewhere listing guidelines for choosing symbols, for standard kinds of objects, monsters and other things which may be encountered?  Is there a page somewhere listing guidelines for choosing keys to map to actions?

Do people even consider having a baseline standard which developers can choose to keep close to, to be of value?