Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Skyrunner]

I'd think it should take a whole lot of time for people to tear down stuff I mean, this isn't Minecraft--no-one's going to destroy a whole building with just a pickaxe xD

I'll just be lurking out of sight until you need or want ideas help :-0

[yamamushi]

Well now that things are picking up, networking is working, etc.  I think it's time I reach out for community help...

I need artists and writers, a developer would be nice but I've been handling things and moving along fairly quickly even without an additional programmer committing base code.

Just this moment I completed a world-interaction system that allows players to dig and place tiles, so it shouldn't be long till a 3d world is in place and players can create "3d" objects....

[Facekillz058]

Building protection or not, im looking forward to this game.

If you need any help brainstorming weapon ideas or the etc, holler.

If the code you use to set up weapons myself isnt too complex, I may even volunteer to code them.

I have a few more questions though.

In an ASCII Roguelike, how are you handling things happening in real-time?
Will there be crafting and resource gathering? I.E. Dig for iron ores, make iron bars, make iron sword/refine iron to steel?
How are you handling creating certain blocks, like, converting logs to planks?
Will building take a while to accomplish, like, a set amount of time to build X block into the world?
Will there be races other than humans that the player can choose?
Will this be free-to-play? It seems to me that hosting costs might pile up.
Will the game support tilesets?

I think a way you could handle building protection could be like.
Create Village Banner > 50 tile protection radius > Upgrade Banner > More protection.
There would need to be a way to make people who stopped playings' places raidable though.


This game has so much potential its not even funny.

[yamamushi]

I have the answers you seek and more, stop by our IRC:

http://www.theasciiproject.com/irc/

or feel free to shoot me a pm or email here on the forums.

Some of the things, like real-time mechanics, have been detailed elsewhere in our documentation (our wiki : http://www.theasciiproject.com/wk/ ), and I am always looking for input and people to bounce ideas off of. That's how creativity flows :-)

If you tell me what you need, we'll put it in so you can start getting weapons made, perhaps a combat system?

Right now I'm working on the "3-dimensional" world, ie z-levels. I did the math, and at 16gb of ram or so, I can handle a 1 billion tile world heh (I have access to 96gb hosts). I don't think I'll be doing that though :p

I don't have a compiled version yet, so anyone who wants to help develop right now would either need to be running Linux  or OSX for an easy setup - as I'm not a Windows dev by any means so I don't really know how things are setup over there. We have someone who is supposed to be maintaining the windows branch, but none of the recent (past week and a half) updates have made it in yet, which is depressing because a lot of neat stuff has gone in over the past two days alone

[Facekillz058]

Well, I can already tell me coding the weapons won't work.
Mainly due to the fact that im on windows, and you said that developers and stuff need linux.
Also mainly due to the fact that modding weapons into DF is the limit of my experience.

Send me a PM if you want me to do any brainstorming for you though.

[yamamushi]

Whew, it's been a long (almost) 2 months, but I'm happy to announce the first binary alpha release of The ASCII Project (ver 0.0.0m - Any Colour You Like). Unfortunately we only have builds available for Linux and OSX at this time, however a Windows build is in the works. If you're a Windows C++ dev with libtcod experience, or any experience for that matter, we ask that you stop by our IRC to help get the windows build out for everyone asap.

Downloads are available from our homepage:


http://www.theasciiproject.com

[Skyrunner]

D: Why not Windows? T_T

I mean, like 80% of people use Windows... including me.

[yamamushi]

D: Why not Windows? T_T

I mean, like 80% of people use Windows... including me.

Well that's why we need a Windows C++ dev asap to help out figuring out why wchar_t*'s aren't being translated properly, we think we've narrowed down the issue to that function, but someone with libtcod experience having eyes on this would really help as I only have Linux/OSX dev experience.

[Skyrunner]

Hmm, though it says wchar_t is 2 bytes wide in Windows and 4 bytes wide in Linux, I don't see how that's problem...


I'm not that experienced, so I don't think I'd be of much help. D:

[Normandy]

Eep, actually using wchar_t*'s... C++ still gives me nightmares, y'know?

I have to admit I haven't actually looked through all your code carefully but what Skyrunner says might be the issue; wchar_t varies from platform to platform, so if at some point you're putting wchar_t's directly to a bytestream then if the server has one definition of wchar_t (4 bytes) and client has a different definition (2 bytes), then that'd obviously cause big problems.

Another thing I've gotten from a little bit of waffling around with the code is the strange combined use of wchar_t* and std::string. I haven't seen references to std::wstring (which would correspond correctly to wchar_t*), but I've seen a couple of wchar_t*. To me this seems like a miscommunication is taking place somewhere. Especially since wchar_t is platform-dependent, if these wchar_t*'s are translated into std::string in a platform-dependent way, this will lead to problems as well. Consider the following quote from Wikipedia:

"The width of wchar_t is compiler-specific and can be as small as 8 bits. Consequently, programs that need to be portable across any C or C++ compiler should not use wchar_t for storing Unicode text. The wchar_t type is intended for storing compiler-defined wide characters, which may be Unicode characters in some compilers."

^{(Source: http://en.wikipedia.org/wiki/Wide_character#C.2FC.2B.2B)}

Unfortunately, I don't think there's much you can do about it without resorting to C++11's char16_t, which is apparently is still kinda wonky on most compilers (boost::locale doesn't have official support for them yet. And also libtcod doesn't have support for them). Or simply coercing the data into uint16_t's first then reconverting to wchar_t on the receiving end.

[yamamushi]

Well I was actually just talking in our IRC about the possible fix (I can't test it because I'm not on Windows), but I am 90% sure the breakdown is in this code:

   

Code: [Select]

    size_t size = lMap.size;
    wchar_t *wstr = new wchar_t[1];
   
   
    mbstowcs(wstr, lMap.ASCII, size);
   
    rMap->symbol = wstr;

Whereas it should be changed to:

Code: [Select]

   
    size_t size = sizeof(wchar_t);
    wchar_t *wstr = new wchar_t[1];
   
   
    mbstowcs(wstr, lMap.ASCII, size);
   
    rMap->symbol = wstr;
For proper portability.

The only reason wchar_t's are being used here is because of the way our serialization library compresses data, and that the tpl library doesn't support wchar_t* types, they need to be converted to multibyte characters first. After the raw data is sent across the net, it's unpacked correctly (we know this because the colors and tile placement information is making it across the net just fine), aside from the values of the wchar_t*'s.

[Normandy]

Hrm. Didn't look through the map code, and it's also pretty late here (should be getting to sleep!) otherwise I'd try the compile myself, but yeah, I could see that line causing some troubles. I feel like you should probably move away from using wchar_t's though. Chances are, assuming that you'll get 4 bytes then suddenly getting 2 will definitely lead to bugs in the future. Your seralization library is right in staying away from wchar_t's since they're platform dependent and won't serialize correctly.

I would imagine map tile data be stored as a series of integers (or smaller) that describe the type of tile and associated data - then the client decides how the tile should be rendered (i.e. what color and tile to use).

[yamamushi]

I would imagine map tile data be stored as a series of integers (or smaller) that describe the type of tile and associated data - then the client decides how the tile should be rendered (i.e. what color and tile to use).

I specifically chose against that type of design as to allow us to update the server and add new tile types without having to release client updates for every minor change to an entity we make on the server end :-)

[Valid_Dark]

Posting to watch,
I'm a semi-noobish C++ Developer, but I've no libtcod experience so I can't help you there unfortunately.
Maybe after I finish what I'm working on I can offer a hand with something though,