Messages

1

7DRLs / Unnamed sci-fi themed, browser based [7DRL 2015]

« on: March 07, 2015, 04:53:26 PM »

Started today with rot.js and got to a good start:

http://gfycat.com/BriskCanineAmericanwarmblood

I'm aiming to make this playable on smartphones too, hence the "touch where you want the @ to move"-controls. On desktop, keyboard is also available.

Currently I have movement, picking up items and simple world generation with separate maps for player's base and overworld planet surface:

http://youtu.be/7bvGfovWyFw

2

7DRLs / Re: 7DArrrL

« on: March 16, 2014, 06:08:07 PM »

I had pretty much the same exact idea for an entry to Procedural Death Jam, but decided to go another way as I couldn't find suitable ship models I liked. Great to be able to play the game anyway.

3

7DRLs / Golem Quest - Successful 3D browser 7DRL

« on: March 16, 2014, 05:39:22 PM »

A wizard has misplaced four powerful animal figurines. As the wilderness is dangerous, he summons some golems and tasks them with the search and retrieval.

This is a browser game powered by WebGL. It's rather simple: kill some monsters, drink potions and retrieve four objects to win. There's also a co-op multiplayer option for two players (turn-based, of course!). I'm probably going to write a postmortem later on, so for now, without further ado:

Play online here: http://tapiov.net/golem-quest/ (Chrome, Firefox)
Development blog post archive: http://blog.tapiov.net/tagged/golemquest
Code & offline download: https://github.com/tapio/golem-quest

4

Traditional Roguelikes (Turn Based) / Re: Elite RL (7DRL 2013)

« on: March 14, 2013, 10:49:46 AM »

Looks very interesting. Although I'm not a huge fan of directly copying another game's world, it's nice to see scifi games around here. Also, those progress indicators are just ridiculously pretty.

Btw, I challenge your planet pics with a shot of a star in my last year's 7DRL :

5

Traditional Roguelikes (Turn Based) / Re: Unicodetiles.js JavaScript Library v2.0 Released!

« on: February 06, 2013, 10:45:47 AM »

Released another version - v2.1. This improves WebGL renderer output with oversized characters, makes the Viewport easier to use without the tile engine component and adds a new example, Raycaster, pictured below.


(Click to try live).

Raycaster is a very rudimentary (about 100 lines of JavaScript) old-school pseudo-3d dungeon presented through the Unicodetiles.js' Viewport as ASCII characters with background colors. It's mostly demoing that you are free to manipulate the Viewport directly.

6

Traditional Roguelikes (Turn Based) / Unicodetiles.js JavaScript Library v2.0 Released!

« on: January 30, 2013, 11:33:53 AM »

Nicely in time for the 7DRL Challenge 2013 I present to you Unicodetiles.js 2.0.
Unicodetiles.js is a JavaScript tile engine based on Unicode (or ASCII if you wish) characters. It was originally made for last year's challenge and I used it for Infiniverse (second pic).



This new major 2.0 release brings a new WebGL-based renderer. This means there are now three options: WebGL has the best performance which also scales well for large viewport sizes with huge amount of tiles. If user's GPU or browser does not support WebGL, a regular 2D-canvas-based slower, but decent (and currently in some cases a bit more accurate) renderer is used. There's also a legacy DOM renderer, but it is by far the slowest and every browser I care about supports canvas. It does have mouse text selecting and DOM events for individual tiles going for it though.

WebGL performance for Firefox and Chrome seems to be in the same ballpark, each one scoring wins in some benchmarks (I'm actually surprised by this, usually Chrome always wins speed tests). Opera's WebGL implementation is not so great and in fact it loses to 2d canvas in some tests. In Opera's defence, its 2d canvas seems to be the fastest of these three browsers, at least with Unicodetiles' renderer. IE9 is also supported, although it obviosly won't have the WebGL renderer and the canvas is the slowest of the four browsers. You are free to benchmark yourself at http://tapio.github.com/unicodetiles.js/tests/ but note that many of the tests are stress tests by design - for a simple roguelike even the DOM renderer should be fine.

Check out online demos and grab the code from http://tapio.github.com/unicodetiles.js/
There are no API changes (a redesign is being thought of for 3.0) and no new examples, but there are several new tests/benchmarks.

Comments and suggestions appreciated!

PS. If you are interested in the technical side of the new WebGLRenderer, here's how it works: A cache of encountered characters is maintained and if the renderer sees new ones, it recreates a white font texture, rendering all the characters in the cache through a 2d canvas. The texture enlarges automatically if it can't fit all the characters. The correct texture coordinates for each tile (so it displays the right character) are calculated on the GPU based on a tile id passed to the vertex shader. The foreground and background colors are also passed in as attributes and the GPU blends them based on the font texture. Tile id and color data for every tile is uploaded to the GPU each frame, which sounds inefficient, but doesn't seem to matter in practise.

7

Other Announcements / Re: Which text roguelike has the best, most approachable UI?

« on: January 19, 2013, 11:50:00 AM »

I'll list a few points that make an UI attractive and approachable for me:

• Colors. This is the single most important thing for me. Monochrome looks boring and forces the player to examine the screen more carefully, as things cannot be so easily distinguished with a glance.
• ASCII bars instead of numbers (for things like health). Helps achieving a more visual look.
• Using full words or unicode symbols for UI texts instead of abbreviations that mean nothing to beginners and make the game look geeky (e.g. STR, STA, INT etc. for the player stats)
• Games aimed for beginners or simple coffee-break roguelikes could have the few keys needed for interaction other than moving listed in the UI. If you list your abilities, it doesn't take much more screen space anyway.

Here's a very fun, short online roguelike: http://ondras.github.com/star-wars/
It passes all the points I mentioned above and also throws in short tutorial messages, which introduce all of the enemy types as they come in.

I'll also shamelessly link a picture of my own 7DRL, which got full points in the Aesthetics category from review committee: http://tapio.github.com/cotc/pics/cotc.png It also achieves most of the points I mentioned.

PS. Personally I hate mouse in roguelikes.

8

Traditional Roguelikes (Turn Based) / Re: Deep Deadly Dungeons (now in various flavors, MyDDDungeonsGL 10/25/12)

« on: October 26, 2012, 07:21:28 AM »

The link to the isometric version is actually the ascii version. The correct one has input=180.

9

Programming / Re: game licence (need help)

« on: October 19, 2012, 08:08:45 AM »

There are many license picker tools in the internet that let you answer some questions and then suggest an existing license for you. Here's a couple:

http://home.ccil.org/~cowan/floss/
http://www.opendawn.com/choose/

Also, not all licenses are long and complicated, e.g. the popular MIT and BSD licenses are only a couple of paragraphs, though they are very permissive.

In any case, an open-source project should have a single, common license that all contributors are forced to follow - that will make everything easier and also makes sure other projects could use the code. Otherwise you could just keep the game proprietary, but I doubt that is what everyone wants.

I suggest you contact all the contributors and discuss about a license that suits you all, leaving custom license out of the equation. The best choices are most likely: BSD, MIT, Apache license v2, LGPL and GPL 2 or 3.

10

Programming / Re: A Roguelike TTF/OpenFont font: Is there interest in such a thing?

« on: July 12, 2012, 10:17:45 PM »

It sounds to me you are talking more about a monospace unicode font than specifically a roguelike font. Are you suggesting adding custom glyphs outside the Unicode? How is CJK helpful in roguelikes, unless you are making translations?

11

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: July 03, 2012, 01:45:27 PM »

A quick dev update!
I added a QtWebkit based native wrapper app, so if you want to cheat those weird people who prefer native executables into liking you, this is what you have been wating for (works for any HTML5 game, not just Unicodetiles.js based). Also useful if you'd like to offer the game to someone who's stuck with IE.

In other news, I forgot to mention here that Kevin Mees has ported Unicodetiles to Ruby language. You can take a look at it here: http://kmees.github.com/projects/unicodetiles.html

12

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: June 30, 2012, 10:06:55 AM »

tripling map size makes the engine too slow.

I've spent quite a bit of time trying to optimize the performance, but in the end it's browser performance that counts. The canvas renderer is much faster than the DOM one and the choice of browser brand counts too: e.g. in one benchmark, I get average frame time on 20ms in Firefox, 12ms in Opera and 10ms in Chrome (there is a small pause at the start of Firefox benchmark, perhaps it analyzed that GPU acceleration should be used and switched to that, so the number might be affected by that initial pause). You can test yourself here: http://tapio.github.com/unicodetiles.js/tests/

You should also try enabling the tile cache, but it probably maters only if you do heavy procedural "infinite" stuff.

If you really want to fill the screen with tiles, you should make the font bigger with CSS. No roguelike uses hundreds of tiles x hundreds of tiles viewport anyway.

@aave do you have a quick solution to getting contents of a tile from a mouse click?

Nope. Somehow I dislike mouse in roguelikes, so I have not given it any thought before. For the DOM renderer, it would probably be rather easy to attach an event handler to all of the tile elements on the engine side, but the canvas renderer needs fiddling with mouse coordinates, i.e. you need to get the mouse x,y, subtract the canvas x,y from that, then divide by the canvas w,h, multiply by tile counts in w,h and take the integer portion (or something along those lines). Not actually that hard probably, but I'm not too interested in adding the feauture (patches welcome though).


PS. I uploaded a new example I had lying around. It's not too exciting and presents a feature that has been in the engine for some time now, but still.

13

Programming / Re: Unicodetiles.js: JavaScript character tile engine

« on: June 29, 2012, 01:23:07 PM »

Oh my god, this is exactly what I have been looking for for months and months! Thank you!

I want to develop an ASCII lookalike RogueLike with Multiplayer and this looks like the perfect engine for the job. You code is beautiful and well documented. The infinite forest demo is amazing and means I can have world sizes of infinite size and be fed from a database along with player positions.

Apart from posting to thank you I just wanted to please ask you to keep up with this project and I look forward to seeing it develop further. Its wonderful.

Chris.

Thanks for the positive comments. As a side note, I'd recommend node.js with socket.io for your multiplayer server and communication library respectively. You'll get real-time communication, dead-simple API and the ability to write the server in JavaScript too.

Regarding the future of Unicodetiles.js, I'm currently not coding any web roguelike actively, so the library is also in "maintenance mode", which in this case means I'll probably make tiny tweaks/fixes from time to time and handle pull requests should some emerge, but chances are nothing major will happen, until I pick up a project that uses UT. If you have bugs or feature requests, feel free to shoot though.

14

Programming / Re: Preferred/ideal development environment/language for roguelikes?

« on: April 23, 2012, 06:14:30 AM »

Very interesting! I would never be waste my time doing anything remotely Dwarf Fortress-like, but I would like to be able to manage a lot of off-screen updates. How would pure JavaScript perform in that regard?

Just a couple of standards to accelerate JS:
JavaScript has WebWorkers for multithreading. They don't have DOM access (and are also otherwise limited), but you mentioning off-screen sounds like they could suit you. There's also WebCL for accelerated GPU (and multicore) computation, but that's not ready yet and it's not pure JS anymore. Then there is WebGL - while graphics oriented, some generic computation could be hacked there too and if your graphics are drawn through WebGL, that should leave a lot of CPU resources for other uses. But again not pure JS anymore (need to do a little GLSL) and only about 50% desktop penetration.

15

Programming / Re: OS X/Linux/Unix/etc Compatibility

« on: March 27, 2012, 10:00:27 AM »

I'm using ncurses, which I'm pretty sure is not supported on Windows, but I've looked at things like mingw, cygwin, and PDCurses.  Would any of those be helpful?

It depends. If you don't use exotic / ncurses-only features, PDCurses should allow you to compile your game for Windows without changes. I did my 2010 7DRL with ncurses, and trivially ported it to Windows using PDCurses.

In fact, I cross-compiled the Windows exe from Linux. Simple programs are very easy to cross-compile to Windows, as long as you don't use any Linux/OSX system APIs. You just need a cross-compiler, which in most Linux distributions is installable from repositories with one command/click. However, I don't know about OSX.