Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Another_Mr_Lizard

Pages: [1]
1
Traditional Roguelikes (Turn Based) / Hark! (iPad roguelike)
« on: October 30, 2013, 11:39:20 AM »
Hark!
I'm releasing a roguelike for iPad, hopefully this week.
The dungeons are tiny, 10x10, and densely packed with items and monsters.
The only visible stat is HP, and the only equip-able items are swords, which are rare.
Items need to combined in strategic ways (ie. throwing a gas bomb into a room of enemies and freezing one in the doorway so they can't get out). The player has to make use of the available items and base their play style around that, in a way that's similar to brogue.
The interface is designed to be zippy and invisible.

Hark! will retail for the princely sum of one dollar.

Screens:
NOTE: ignore the pile of numbers in the bottom left corner, it's dev stuff






Thanks !

2
Programming / Re: 7DRL Development Kit
« on: February 02, 2013, 01:56:05 AM »
If nobody reinvented the wheel, we'd be rolling around on logs like the flintstones ;)

3
Programming / Re: 7DRL Development Kit
« on: February 01, 2013, 11:30:58 AM »
It seems like most of the areas you mention are generic system things, handled already and in better ways than you will ever achieve.  I just don't think an extra level of abstraction accomplishes anything since most modern system interfaces are so simple now anyway (i.e. sfml).  As far as the roguelike features, as Darren mentions we already have engines that do that as well.  Personally I think using any kind of engine like this is very restrictive and inhibits the learning process.

Cross-platform generic system functionality has indeed been done well by SDL, glfw, smfl etc, and one of those will be used for window context and input in the back-end part of the project.
Lua itself exists at higher level of abstraction than any  of that. If anything, this project is about providing lower level functionality in Lua.
I don't agree that abstraction is harmful for beginners. If a beginner wants to draw an image on the screen in their first game project, I don't think they should have to go read the PNG specification, integrate the FreeImage library, and learn OpenGL.

4
Programming / Re: 7DRL Development Kit
« on: February 01, 2013, 10:52:04 AM »
Uh, before you go to all that effort, have you seen the T-Engine? Lua-based, numerous customizable level generators, LOS, lots of options like hex, full graphics and sound support... You would be very hard pressed to rival it.

The T-Engine is really more of a full blown roguelike development system. The idea behind this project is that everything is really quick to learn and use, rather than being all encompassing. It's about the simplest possible abstractions rather than the most functional.
Also, I want to make a nice API for my own 7DRL attempts, so I might as well go the extra mile and polish it into something that other people can use.

5
Programming / 7DRL Development Kit
« on: January 31, 2013, 03:20:39 PM »
I've started working on a framework that takes care of the boiler plate involved in getting a roguelike up and running.
It's a Lua based system that aims to take care of some of the really common tasks, with a simple and clean interface.

My plan is to cover following areas:

Tile sheet clipping and sprite rendering
Font rendering
Basic Audio
Keyboard / Mouse Input
Line of Sight
A Star pathfinding
Decent random number generation
Game object system
Event System
Basic GUI components (Button, console)

It's designed to be useful without overly forcing a particular game structure.
I'm also planning to write coherent reference documentation for all components of the framework and a tutorial detailing an ultra basic roguelike.

It's also designed to be accessible to beginners. There's nothing to build and no dependancies, just an executable that hosts lua scripts.
 
I think what would make this framework useful for a 7DRL above existing alternatives is that it's specifically focused on the kinds of implementation problems that arise when developing an RL. There is functionality that almost every single roguelike implements, and this framework aims to abstract it cleanly and allow people to focus on gameplay ideas in the limited time they have.

I'd like to hear any thoughts or suggestions anyone has.

6
Programming / Re: Apotheosis, 3D Roguelike
« on: January 22, 2012, 11:04:10 AM »
I have a feeling that totally random placement of rooms in the levels looks even worse in 3D. I think there should be a structure, some kind of reason for placing rooms.
There is.

Also if you have a 3D engine, what is stopping you to make some use of the third dimension (those levels look flat 2D).
Significant development overhead.

7
Programming / Apotheosis, 3D Roguelike, 1st Tech Demo available
« on: January 22, 2012, 10:03:36 AM »
Hi, I posted here last year about Apotheosis, a 3D, semi-realtime roguelike I'm working on.
It's come on a great deal since then, and is moving toward a demoable stage.


Development Blog:
http://apotheosisthegame.wordpress.com/

I'd love to hear any gameplay suggestions anyone has.


 latest Dev site: http://seanfahy.me/

8
Programming / Re: My 3D Rougelike
« on: May 31, 2011, 04:51:50 PM »
What I am getting at is can someone else use your graphics back end for their roguelike project? ;D
[/quote]

The dungeons are generated, and are basically a 2d array of either floor or stone tiles. Then a series of query/replacement rules are applied to swap out groups of tiles that meet certain criteria with models that represent architectural features.
The rules also generate collision data and such.
So, to answer your question, it's totally abstracted from the process of actually generating the dungeon structure and would, hopefully, be of use as a system in it's own right.
I'm thinking it would be really cool to refactor the code into a framework for adding 3d graphics to rougelikes. Gameplay logic could be plugged in as a dll or something.
All the assets are defined in a text file, so it would be trivial for a hypothetical reprogrammer to add in their own assets.
I can foresee the codebase becoming less flexible as things like character animation and UI are added.
At the moment though, my only concern is getting the damn thing out the door some time this century. Making it into a tool can happen after it's released.

9
Programming / Re: My 3D Rougelike
« on: May 30, 2011, 03:11:17 PM »
Looking promising so far---keep at it!
Thanks !

I would like to apologize for the fact that I rather embarrassingly misspelled rouguelike throughout my original post.

10
Programming / My 3D Rougelike
« on: May 30, 2011, 11:00:18 AM »
Hi, I'm working on a 3D action rougelike game at the moment. I started a development blog (more as a technical journal than anything else), and you can see screenshots of how it looks at the moment.
http://apotheosisthegame.wordpress.com/
At the moment I'm working on designing the fundamental gameplay mechanics, and trying to successfully synthesize what makes rougelikes unique with a more action oriented style of interaction (i.e not turn-based). It's very early days at the moment, but I'd really appreciate any feedback or suggestions anyone has, especially about preserving the essence of what makes rougelikes so hatefully fantastic.

Pages: [1]