Messages

316

Traditional Roguelikes (Turn Based) / Re: Cladun X2 now available on Steam!

« on: August 15, 2012, 03:50:21 AM »

Who knows, perhaps the original and any other number of other similar projects will also make the jump if this does well?  We can only hope...

Too JRPG for me, but it looks like a polished work.

317

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

« on: August 06, 2012, 08:05:23 PM »

If you're the person getting crashes on the Nexus 7, please contact me.  My email address is on the play store page.  The play store page error reports do not give enough information.

318

Traditional Roguelikes (Turn Based) / Re: ADOM 1.2.0 Prerelease 1 is out!

« on: August 06, 2012, 06:52:01 AM »

I think this is wonderful.  I'm not an ADOM player, but I hope those that like the game and wish to both support Thomas and encourage him, take the chance to do so.  This is the kind of thing which if it goes well, encourages others to do similar things.  If the creator of Incursion were ever to be interested in doing something similar, I'd jump at the chance to support him.

319

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 

320

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

« on: July 26, 2012, 10:57:38 PM »

You could maybe have a free version and a donation version then.  People shouldn't complain too much about free versions and it makes the possible testing group much more open.

People complain horrendously about free versions.  I don't really use my phone for much, but the few free apps I have installed are filled with tonnes of people complaining about all sorts of ridiculous things.  The idea of dealing with the support for that kind of user seems like it would undermine my interest in the project.

My interest in Brogue is that it looks great, and it's an extremely user friendly game.  My porting of it is primarily a combination of the programming challenge, and the desire to educate myself more about Android programming.  Dealing with free users.. seems like it would be an overhead and burden.

321

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

« on: July 26, 2012, 09:58:20 PM »

The goal wasn't to get more sales, it was to reduce the amount    The game experience is Pender's and it doesn't seem right to make anything more than enough to encourage me to continue the bug fixes and Android UI enhancement.  That and I want to avoid people buying it and being surprised at how much more work is needed.

You're right, $12 is too much.  I'll reduce the price to $2 and if either of the two things above look like they're occurring, I'll lift the price back up.

If you buy it and have requests for simpler fixes or ui improvement, you can post here or in the google group accessible from the developer's page.  There's a list of "features" in the product description which are top of my list to fix before looking a things like zooming in and out web page style.

322

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

323

Programming / Re: Critique my "emergent economy" code

« on: May 18, 2012, 07:07:37 AM »

ignore

324

Programming / Re: Critique my "emergent economy" code

« on: May 18, 2012, 07:05:32 AM »

Rather than:

Code: [Select]

while not len(auction.bids) == 0 and not len(auction.asks) == 0:Don't you mean:

Code: [Select]

while len(auction.bids) and len(auction.asks):


325

Programming / Re: Critique my "emergent economy" code

« on: May 18, 2012, 07:02:28 AM »

Code: [Select]

random.shuffle(auction.bids)
random.shuffle(auction.asks)
## Sort the bids by price (highest to lowest) ##
auction.bids = sorted(auction.bids, key=lambda attr: attr.price, reverse=True)
## Sort the asks by price (lowest to hghest) ##
auction.asks = sorted(auction.asks, key=lambda attr: attr.price)
Does the shuffling really make a difference?

326

Off-topic (Locked) / Re: Lost Labyrinth - always opens website on exit

« on: January 14, 2011, 11:25:32 AM »

It baffles me as to why developers would be so rude to their players. With all the discussion about advertising games around here, I expect that players are an especially precious resource in this niche.

Egads!  The sheer entitlement of thinking you can tell a developer what to do with their masterpieces..  Why, when I release my game, I am going to open three web pages.  One will be my web page where I piteously ask for donations, and provide game news and updates.  The second shall be a stern lecture about how the user should be grateful for even playing my game, and should proceed to appreciate the privilege of having web pages opened for them.  And the third shall be a rambling diatribe on the evils of agile programming, linking it to the downfall of modern society through the misguided doctrines of taylorism.

327

Other Announcements / Re: Project(?): creating a standard for keyboard controls in roguelikes

« on: September 19, 2010, 09:04:38 AM »

Just another thought on complex key bindings: I don't actually believe that complex item interaction needs a complex interface to work. But the developer will have to get imaginative in new ways. Some examples:

Maybe it was just me, but none of these examples seemed to illustrate anything about "I don't actually believe that complex item interaction needs a complex interface to work"

So you see, a simpler interface is always better

I unfortunately, am not seeing 

328

Programming / Re: Roguelike standards

« on: September 19, 2010, 08:59:12 AM »

Thanks for the replies people, this was very informative.  I give you a 9/10 signal to noise ratio, which is consequently lowered by this post.

329

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?