Temple of The Roguelike Forums
Announcements => Traditional Roguelikes (Turn Based) => Topic started by: getter77 on June 10, 2010, 12:03:29 PM
-
http://dev.largerussiangames.com/projects/show/sharplike
Sharplike is an open source roguelike library written in C# for the .NET Framework and Mono Framework, licensed under the CPAL 1.0 (a derivative of the Mozilla Public License). It is developed in an attempt to provide a best-practices framework within which developers can concentrate on just making an awesome game, instead of spending a lot of time reinventing the wheel. Development of Sharplike focuses on two separate concerns:
* An easily usable, extensible core library, and
* A clean, powerful library of additional features for developers who want to get a head start on realizing their game.
The current version of Sharplike is 0.2.0, released on June 10, 2010. Features include:
* Modular core system for audio, graphics, input, and scripting (scripting currently disabled) using a provider model for all core systems.
* OpenGL audio and video system, using OpenTK.
* Keyboard and mouse input using WinForms. Command-based input mechanism; games don't have to care about specific key bindings outside of an .ini file, the framework handles it for you.
* Stepwise game loop system for roguelike game control. (Realtime game loop coming in the next release.)
* Stack based state machine for control flow. Integrates with the game loop automatically, without any special configuration.
* Preliminary noise generation systems in Sharplike.Noise.
* Very early start of a UI library to use in conjunction with the core libraries. (Next release wll build this out significantly.)
* Built using the .NET Framework 2.0 and tested with Mono 2.4.4 to ensure cross-platform operation on Linux and Mac OS X.
There seems to be some Rail issues with most of the links, but this sounds to be yet another good engine for Roguelike doings to come. Mono stuff should help audience wise, though this is the first I've ever seen with this kinda license and I'm not so familiar on the gist of it/Mozilla stylings...
-
It's definately good to see some more C# in the Roguelike universe. Certainly one of the nicer things since most of us who work with the language aren't relinquishing our code. *snickers deviantely*
On a side note, their homepage construction image is neat. (Attached Below in case it goes down in the future. Their website is available here : http://largerussiangames.com/)
I've ever seen with this kinda license and I'm not so familiar on the gist of it/Mozilla stylings...
That's strange because CPAL is one of the biggest licenses out there.
It's almost identical to Creative Commons Attribution License
CPAL: http://www.opensource.org/licenses/cpal_1.0
CCAL: http://creativecommons.org/licenses/by/3.0/
-
D'oh...I guess the abbreviation is what got me. That and my general lack of understanding of the myriad licenses. :P
-
Hey, folks. I'm Ed, one of the devs for Sharplike. Thought I'd come by and address a couple of things:
There seems to be some Rail issues with most of the links, but this sounds to be yet another good engine for Roguelike doings to come. Mono stuff should help audience wise, though this is the first I've ever seen with this kinda license and I'm not so familiar on the gist of it/Mozilla stylings...
Yeah, I was having trouble with Redmine. It's running off my personal Dreamhost account for now, because I'm not going to pay to host it until I'm using it for projects that actually make me money. :)
I've ever seen with this kinda license and I'm not so familiar on the gist of it/Mozilla stylings...
That's strange because CPAL is one of the biggest licenses out there.
It's almost identical to Creative Commons Attribution License
CPAL: http://www.opensource.org/licenses/cpal_1.0
CCAL: http://creativecommons.org/licenses/by/3.0/
Sorry, but CPAL is not similar to CCAL. CPAL has a number of other clauses that go well beyond the Creative Commons license, including the requirement that any modifications to the code under the CPAL license be made publicly available (slightly similar to LGPL, but the boundary is at the code file level rather than the process/binary-image level). In particular, it should be noted that it is not GPL-compatible and you may not use CPAL-licensed code and GPL-licensed code in the same publicly released project. (This is not the fault of CPAL; it is because of the GPL's provisions. All MPL-derived licenses are GPL-incompatible. I selected this license for the project after a good bit of thought: to me, GPL incompatibility is a feature, not a bug.)
Anyway, the main reason I swung by is because we just pushed Sharplike 0.4.0 (http://oss.largerussiangames.com/42/sharplike-0-4-0-released/) in a packaged format. It's pretty slick, if I do say so myself, albeit incomplete. We're going into a brief feature freeze for Sharplike 0.5, which is primarily a documentation (http://dev.largerussiangames.com/wiki/sharplike) and demo-writing release, after which we'll be proceeding with Sharplike 0.6. While I would say that you could easily start development of a Sharplike-powered roguelike with 0.4.0, I'd advise doing so with the foreknowledge that we'll be adding the features to really give a game a polish in 0.6. Our APIs are going to be static from here on out, however, and you'll be able to incorporate 0.6's features into a game started under 0.4 without much trouble.
I hate to toot my own horn, but honestly? Sharplike's slick, and I don't usually say that about my own projects. Managed code lets you hit the ground running, and Sharplike provides some seriously powerful tools to get going. You can have the core of a game up and running in an hour or so. I recommend that anyone looking for a trivially cross-platform engine give it a look and tell us what you think, and what features we could add to benefit your projects.
-
Welcome to the thread and congrats on 0.4.0! 8)
Might I suggest bolding the latest features in the Summary page on Roguebasin so people can get a better feel as to the evolution of the project? With the 0.4.0 bolds becoming regular text again when the 0.5.0 features are to be mentioned and so on.
Sharplike surely sounds to be slick and heading in a good direction, as is it always good to have more competent engines out there. Your nod to Dwarf Fortress level complexity being a target of sorts would probably catch the interest of at least a team or so currently scrambling about aiming to start something DF-like in their own right.
-
Good call. I'll do that.
The guys doing most of the heavy lifting behind Sharplike--Alex Karantza and Sean Edwards (Total_Meltdown)--have actually written 3D game engines; this is patterned pretty heavily off how you'd do a 3D engine, only with the rendering field being...well...ASCII. The focus on making it easy to use makes building it a little more of a hassle for us, but makes development of actual games a lot easier. :)
-
Good call. I'll do that.
The guys doing most of the heavy lifting behind Sharplike--Alex Karantza and Sean Edwards (Total_Meltdown)--have actually written 3D game engines; this is patterned pretty heavily off how you'd do a 3D engine, only with the rendering field being...well...ASCII. The focus on making it easy to use makes building it a little more of a hassle for us, but makes development of actual games a lot easier. :)
Famine before feast eh? Good on the lot of ya! :D
I'm guessing then it would support mixed ASCII/Graphical doings should somebody go that direction somewhat in line with another new engine, T-Engine 4/ToME 4? http://te4.org/
-
ToME 4 is somewhat similar in concept to what we're doing. I haven't looked at their code (Lua gives me hives), but I think they're going in the same direction. We prefer to deploy on .NET because, frankly, it's easier than wrestling with any specific runtime for any one language--when your runtime has to abstract itself to support lots of languages, it tends to be a smarter runtime. ToME seems to handle more higher-level functionality for you than Sharplike does; we'll eventually be building up into that higher-level space as time goes on, but I have reservations about doing that because you run the risk of all the games using your engine looking and playing the same.
There's nothing really stopping a user from developing something graphical, although it's not really supported (the workarounds to do it are ugly, maybe down the line, for 1.x or something). The system is decoupled enough that it shouldn't be too hard to do when it comes down to that, it's just that for our primary use cases we didn't need it. (Anyone who'd want it is more than welcome to post a Feature ticket on our tracker and we can see if it's worth implementing!)
-
Just a head's up: The "here"'s on your site's Q+A section in the License section are not hyperlinks as I reckon they are intended to be to the full and simpler versions of the license description.
-
Whoops. Thanks for the heads-up; one of us C&P'd it from elsewhere and forgot to format.
License: http://opensource.edropple.com/svn/Sharplike/trunk/Sharplike%20License.txt
Short-hand explanation: http://en.wikipedia.org/wiki/CPAL
-
Good deal as I'm always happy to help. This feels like something that will lead to big things in terms of hitting most all the bases.
Hmm...given the apparent video capabilities(Though I'd suggest inserting a hyperlink on the Roguebasin page for OpenTK), might I be correct in reckoning support for in-game animation, perhaps of the "lively ASCII" persuasion something akin to Triangle Wizard? As I would guess otherwise that'd lend to an interesting juxtaposition of cutscenes within static ASCII doings.
-
I'm not exactly sure what you mean; I've never looked at Triangle Wizard. I can tell you that there's support for a number of glyph modifiers and other wizardry, and there's a post-logic, pre-render hook that can be used by applications if devs know what they're doing.
-
Triangle Wizard went for an odd combo of Vector graphic stylings, particle special effects, and.."stylized" ASCII in lieu of tiles. In other words, rather than a Knight graphical icon slide across the screen to engage the player(as it is realtime), in Triangle Wizard you would see a " K" literally "gallop" across the screen at you with the lower part of letter K animated in such an evocative manner.
That said, it is developed in GameMaker of all things, so such a thing might not happen to fall into the scope of Sharplike. It does sound like a robust characterset is possible with Sharplike though.
How about things like fullscreen/stretch to fit for widescreen folk/resolutions that play well with people on machines with tricky ones/etc? Is it an aim for the proper versions to perhaps create some manner o automaticf error log file to ferret out odd crashes when people start making this and this within it?
-
Ah. Well, here's the cool thing about our glyph system: so long as you are using a graphical rendering system (OpenTK, or our future planned Silverlight frontend), you can have as many arbitrary glyphs as you want. The default glyph set is 255, but our glyph palette doesn't care how many you have. So if you want to animate glyphs, just add more frames to the end.
Resizing of the play window is planned - we haven't figured out how to do so cleanly yet.
-
Nice! I would also guess individual glyphs can be, perhaps wildly, varying sizes as opposed to everything being locked into equal proportions? A giant "D", that is actually huge in terms of the gamefield, would be a nifty communicator on top of opening up strategic possibilities not readily present in a great many other Roguelikes. Good to hear on the window sizings too----good luck with finding a comfortable way.
Silverlight eh? Despite my overall ignorance, any ruminations towards the whole HTML 5/powerful browser-based stuff coming down the line? About the only thing many people clamor for more than additional DF-like games would be multiplayer capable ones.
-
Currently, no, there's a single size for glyphs (1x1). Later we could probably change that, but there's been no real need to do so yet. If we were to do it we'd probably create a single LargeEntity that was the parent of four smaller ones (or whatever size you needed), and moved them together. I don't think that would be difficult at all, now that I think about it.
As our code is C#, there is zero chance of using HTML5 or the like (not that I would anyway, I find the HTML5 spec catastrophically broken and nowhere near the Flash or Silverlight killer they say it is). Our code is relatively decoupled, though, and a Silverlight plug-in would be pretty easy to build (although possibly slow; there's no hardware acceleration for Silverlight, though there is for XBAP--which isn't cross-platform). There's nothing really stopping us from making networked games, especially with our message-passing framework. It'd be a pretty easy addition to the messaging system and we've been talking about it a little bit.
-
Great to hear on glyph possibilities AND fair odds on net-multi possibilities! 8)
Hmm...what about local co-op/playing nicely with some manner of gamepad things? One of these days somebody is bound to essentially remake the old Gauntlet games and infuse them with modern Roguelike notions methinks....
Or some other tactical/turnbased style variants...
Hexagonal support? AstralHexRL has seemingly been dormant for quite awhile now and hadn't made it to release yet...
-
No multi-input, but that might be a feature request that we could do for 1.2 or something (i.e., after we get everything done _we_ want we can start looking into special requests that break API--if you'd like to see it sometime, post a Feature ticket in our system so we remember it when we get that far!).
Hexes...doubt it. Though I have a number of half-finished hex game engines in my files, I might polish one up and release it sometime.
-
Yep, all makes sense and good stuff---mainly just thinking off the top to my head to try and anticipate audience-broadening potential endeavors since some folk can be shy about mentioning/requesting such things despite wanting to avail themselves of such.
I would also highly recommend some video tutorials/demonstrations/etc to eventually wander up and stay relatively lively on youtube---the days where youtube was locked into too low a resolution to display lots of stuff correctly seem largely a thing of the past.
Hmm...What about transparencies? As in, let's say, a more seamless fading in effect when going downstairs more akin to going down a tunnel into a ramp? It would add a bit of panache versus an instant screen change, and should any realtime Roguelikes manifest they would benefit----as would it allow for freaky things like Spiral Staircases and the like.
-
Transparencies are fully supporting in basically all areas--I don't think there's anything that is expressly not transparency-capable.
I'm not much of one for video tutorials, but maybe we'll see about them. I'm working on a simple, straightforward text tutorial for creating a game right now.
-
Great!
Hmm...other crazy things...
What...about....
Background/foreground scrolling/movement? As in "In PitRL, a Sharplike production, you must descend into the Pit of Woe with only stairwells and scattered ledges at your disposal while fighting the hordes in order to reach the Orb of Toz. But you must be quick in finding sound paths ever downward due to the stairs crumbling on down" In a practical sense, you'd, I suppose, be able to vaguely "see" X number of levels down in a faux 3D effect/perspective trick---becoming more in focus as distance is descended and eventually the current level. Seeing vague "tiny" glyphs of paths and mobile/stationary foes swarming about. Then perhaps at the end you fly/float back towards the surface with the Item having sealed the pit presuming you can survive the ascent---just because! :D
Based on what you say about transparencies, I would think such a feat kinda workable at some point depending on how much flexibility there is in terms of background/foreground. I would reckon NOT to expect Sharplike to ultimately get into any actual 3D features, even though you mention the prior 3D engine works, versus tricks like above...right? :P
-
As far as 3D goes, I was planning on the DF model of "layered" glyphs that you move up and down, one Z-level at a time. We currently don't (but probably should) have overloads for the various glyph display functions to allow for hinting as far as stuff that's a level "below" (in case a tile on Z-level 1 is transparent, the "far below" display for Z-level 0 should be rendered beneath it). For stuff like LoS, I don't see why it can't be made 3D. We haven't started writing that yet. =)
-
Excellent. Definitely seem to be a robust and flexible future ahead for Sharplike----just a question of getting there, fixing whatever comes up, and the whole thing being as intuitive as can be wrangled.
Are there any pie in the sky notions any team members have as to aspects that would depend on OpenTK's ongoing evolution with the, as I understand it in a very limited way, OpenGL/CL/etc continuing to improve? I saw that OpenCL in particular had a rather meaty looking 1.1 release not that long ago.
-
OpenCL is a part of OpenTK. As a rule we kind of hate "duct tape" code, that exists just to hook together a library with a new namespace. Like, we don't even have a "configuration loader" class/format...because we have System.Xml and we already pack the Nini INI library with out code. If someone wants to use OpenCL, they can.
That said, we may experiment with it for some stuff--like, have a faster noise implementation that works in OpenCL, and a .NET fallback.
And yeah, I agree, there's a pretty robust future for this code. We're not the best programmers ever to walk the earth, but we're pretty good, and we're focusing a lot on making the hard stuff transparent. I mean, after fixing the last embarrassing and stupid bug, I can write the start of a game--like, get an @ walking around--in maybe 20 minutes.
-
An @ walking around in about 20 min, in this likely still a good ways from polished and all-the-way implemented state---that's pretty fantastic in boding well for what would hope to be an active userbase come .6.0 or maybe even starting somewhere in .5.x upon that feature freeze taking place that has been mentioned.
The pace seems to be well in hand too in terms of the gap of time from .2.0 unto .4.0----at even a somewhat slowed rate there would be some rather substantial growth and improvement by year's end.
Is the team thinking of taking part in ARRP, even if just for kicks in a happy coincidence of the lot of it? I would think it would also help with visibility to grow the audience.
http://roguebasin.roguelikedevelopment.org/index.php?title=The_annual_roguelike_release_party
-
Well, when I say "an @ walking around in 20 minutes," you have to realize I mean the following:
-a full tile system, with the ability to have walkable/nonwalkable tiles
-a paging, caching map of arbitrary size
-3D mapping, so you can make multiple pages and move up and down
-(in 0.6) full integrated pathfinding and line-of-sight
-(in 0.6) fluids - so you can just lay in water, lava, etc.
It's just the absolute basics that you see, but the software already supports pretty much everything that you'd want--it's mostly a matter of content generation (building your maps) instead of screwing around with reinventing the wheel. Which is kind of the point.
I expect us to hit 1.0 before September, so I have no idea.
-
Right, I just meant in terms of the "plug n' play" factor that a fresh user could spend not a terribly gigantic amount of time with to get things hopping overtly and get some real traction on their then spinning wheels.
Heh, throw 1.1.0 up for ARRP then! ;)
That example reminds me though:
What about Gasses alongside Fluids? While somewhat similar, they'd also have some key differences going...
-
Uh. 1.1? I don't know what the other two guys want to do, but I have no real plans to improve the library beyond 1.0, aside from bugfixes. 1.0 literally means "everything that we wanted is there"; anything past that is very much if-and-when. Sharplike is a project primarily for our own personal enjoyment; whether anyone other than us uses the library is not really a big concern for me personally, and I have a feeling that a lot of stuff will be looked at based on how interesting it may be for us to use.
As far as "ARRP," I don't speak for the other guys but I am much more interested in releasing code and games when they're done, not during a specific month. Sorry.
-
Ah, I see---aiming for a fully realized 1.0 is an interesting aim indeed versus the common conventions of growth on up the whole number scale. All the better that you lot are already up to .4 then! 8)
No worries on ARRP, as it was just something mentioned in case of "happy coincidence" of the calendar. Surely nothing amiss with putting out your hard wrought efforts upon it all being well contented and dripping with satisfaction as per the team's reckoning.
Good stuff good stuff. ;D