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 - rsaarelm

Pages: [1] 2
1
Not yet, but thanks for mentioning them. I'm around the dev stage where I need to start adding some more interesting enemies with my game right now, I'll go re-read those now in case there's something I can pick up and use.

2
7DRLs / Re: Phage [7DRL 2015]
« on: March 16, 2015, 06:38:51 PM »
That looks like an error with the OpenGL bindings. Do you have a 3D accelerated graphics card and up to date drivers installed for it? I think a vanilla Windows install with zero graphics drivers updates will not work, my rendering engine needs something that can do simple shaders.

3
7DRLs / Re: Phage [7DRL 2015]
« on: March 16, 2015, 08:28:49 AM »
Still some necessary files are missing (for example libgcc_s_dw2-1.dll). Yeah, I can download this libraries and play the game, but - if you want to publish your game to audience - add these files to archive with game.
Maybe it's problem with my PC/Windows, but I don't think so.

Yeah, that totally needs to be included, thanks. It's probably from some of the parts in the dependencies that needs MinGW to build. I've updated the downloads.

I reproduced needing this for the 32-bit build, but the 64-bit Windows build seems to work fine on its own. Anyone notice further missing dependencies, do tell me.

4
7DRLs / Re: Phage [7DRL 2015]
« on: March 15, 2015, 09:01:22 PM »
And just now I notice that there was actually an earlier 7DRL in 2012 also called 'phage'. Oops. I'll have to come up with a new name for my thing if I ever develop it further.

5
7DRLs / Re: Phage [7DRL 2015]
« on: March 14, 2015, 06:53:16 AM »
Is possible that you make windows x86 build?

Building 32-bit release binaries on Windows with rustc is very slow for some reason, first I thought there was a bug that just makes the 32-bit compiler hang. Turns out it does get built eventually though. Added 32-bit build to the downloads page.

I've also updated the readme on the github page with build instructions for trying to make your own build.

6
7DRLs / Phage [7DRL 2015]
« on: March 13, 2015, 08:28:46 PM »
You're an alien bioweapon. You kill things and animate their corpses. Game is done in Rust. 7DRL is finished, though missing a bunch of planned stuff like ranged attacks, mob infighting and being able to trick the AI with infiltration.

Phage is forked off the same Rust roguelike codebase I've been working on since early 2014 as my last year's 7DRL Morlock Hunter was. Phage is a much better game since I had more engine machinery and more time to work on it this time.

Github with source and screenies.

Downloads for Windows and Linux

7
Early Dev / Re: Captive
« on: October 02, 2014, 06:09:08 PM »
Just so you know, there was a 1990 Amiga first person CRPG also called Captive. http://en.wikipedia.org/wiki/Captive_%28video_game%29

8
Design / Re: My two cents about Permadeath
« on: March 21, 2014, 11:02:18 AM »
An approach I haven't seen anywhere: Make winning the game with a single life a conduct instead of the only way to play.

Here's how it would work: As usual, you don't get free save-scumming. The first time you die though, and don't have an in-game mechanism like an Amulet of Life Saving or a lich spell to bring you back in some form, you get respawned some ways back, like you would in vanilla Diablo. (Some games already implement the respawn mechanic, ToME4 has the extra lives and DCSS has the cat race.) Then you get told that you lost your "single life" conduct, and your score gets frozen at what it was when you died. You can keep playing and respawning as much as you want, but your high score won't improve, and you won't get the "single life" conduct if you win the game.

The idea is that serious players would approach the game with the understanding that they're going for the single life victory, and with no save scumming to have their back, would still approach every dangerous situation with the requisite wariness. Players would also be free to practice approaches to different regions of the game with the respawns even when they weren't good enough to single life through the whole thing, but they wouldn't get proper high scores and end game conducts from it.

9
Other Announcements / Re: Felicia Day endorses Tome 4
« on: January 29, 2014, 12:11:37 PM »
Goddammit Krice.

10
Sodna is meant to be a replacement for the terminal display part of libtcod, while leaving out all of libtcod's software logic level bits like the map generator and pathfinding modules.

It's current improvements to libtcod are support of in-memory font bitmap data instead of requiring the font to be loaded from a filesystem bitmap, and automatically zooming the display as the window is resized. You can even use Sodna without any font bitmap data, since the library has the standard 8x8 CGA font baked in, and will use it until the user specifies a different font image.

Sodna currently doesn't support mouse input (I'm still thinking about the best way to represent incoming mouse events). I'd also like for the zoom feature to be pixel perfect instead of scaling exactly to the edges of whatever the current window is, but that looks like it would be some amount of work for a minor bit of visual niceness.

11
I wanted a library for bringing up a graphical terminal window, drawing characters on it, reading user input, and doing nothing else. Here's the one I made: https://github.com/rsaarelm/sodna/

The header is all there is to the interface. The screen buffer is an array to 32-bit cells, which contain the 8-bit character and 12-bit background and foreground colors. You draw on the screen by getting the pointer from the interface and modifying the array. The demo program provides a more detailed usage example.

My use case for this is calling the library through a foreign function interface from a non-C language, so I want to keep the library free of any kind of application logic that could just as well be implemented on the host language. Sodna's role is to stick to the window management, graphical display and input handling which has to access external systems.

It's MIT licensed, feel free to pick it up if it looks like something you could use.

12
Incubator / Re: Intro to the Incubator
« on: September 15, 2012, 09:47:45 AM »
Turns out I hit a brick wall with C++11 stuff too. With a new day job of working with C++, I just stared at the code at home and had no energy to work with it. So I decided to see what's up with the Go language these days, and ended up starting a total rewrite of Teratogen in Go version 1, after deciding that the old code base was too mired in a combination of abandoned experimental Go libraries, an unidiomatic style and a messy general architecture to be salvageable. It's still very much a work in progress and obviously not making it for ARRP, but at least I'm getting code done again.

13
Incubator / Re: Intro to the Incubator
« on: June 19, 2012, 12:46:02 AM »
I'm trying to get the C++11 reboot of Magog into a playable shape by ARRP 2012, and the project's aims are pretty much aligned with the current incubator plan.

Awesome to see this return----Factor hit a brick wall of some sort?

Factor is nice, but I wanted to look into C++11, get closer to the metal with my base tech, and get a game library that can port to lots of places and uses a tool ecosystem with lots of support for more general viability. Also, my biggest difficulties these days seem to be with design, and language choice doesn't really help there.

14
Incubator / Re: Intro to the Incubator
« on: June 18, 2012, 04:36:49 PM »
I'm trying to get the C++11 reboot of Magog into a playable shape by ARRP 2012, and the project's aims are pretty much aligned with the current incubator plan. The game is GPL, and an usable and approachable UI definitely fits with the design ideal. The idea has been basically to do a pilot project to figure out what works with a continuous world map engine.

Unfortunately, progress has been very slow so far, and though the core map engine is reasonably solid, there's still very little actual game to speak of. I'll need to get somewhere with that before I can start soliciting useful feedback. Still, even if I'm stuck with my own stuff I can still give feedback on other projects.

15
Early Dev / Re: Warhammer 40000: The Roguelike
« on: March 29, 2012, 10:40:46 AM »
I don't see why the inevitable C&D has to be such a problem. Just develop and publish the fangame in a way that can't be connected to your real-life identity in any way. Companies need a real person they can ask the police to drag to court for lawsuits to work, and if they can't find them, the C&D don't amount to much.

Web domains can get seized though, so figuring out how to keep the project discoverable in spite of this is left as an exercise for the reader.

Pages: [1] 2