Arcomage 0.3

[Nomad]

You need the pre-compiled Visual Studio libraries (or compile SDL by hand) since ".a"-Files will only work with MinGW. To link against SDL with VS you either need .lib files - or link directly to the SDLMain DLL.

I've got myself MSVC SDL libs and it worked! Thanks

[GreatEmerald]

Good job You should still use git, though, it's really worth it.

[MMXAlamar]

Ahh, good 'ol Arcomage! Brings back the memories

I remember I got a copy of the original Arcomage CD when I bought LoMM. I used to play it on my Windows 95 in the basement.
That old thing broke a few years ago, lol.

This site looks really cool, it's called Arcomage Tribute: http://www.gatewayheaven.com/projects/arcomage/

The logo is awesome and the game has a similar but slightly different layout. And this time I don't need the 95 to play it

[NicholasRay]

Im also working on that project too. Check out the prototype website.
http://www.gimmik.net/Arcomage

[GreatEmerald]

Huh, that's pretty neat. My goals are basically the same here. I want to have mod deck support as well. Though my project is more faithful to the original and includes customisation and more polish right now. Though less graphics.

I'd say it would be neat to coordinate the efforts, if you were up to it.

[NicholasRay]

We'll the dev just sent me the updated version, but I can't release it yet I'm doing bug checks for him. It runs much better than the previous version. What did you have in mind?

[Xography]

Huh, that's pretty neat. My goals are basically the same here. I want to have mod deck support as well. Though my project is more faithful to the original and includes customisation and more polish right now. Though less graphics.

I'd say it would be neat to coordinate the efforts, if you were up to it.

Well its not a fork, the almost same version numbers are coincidental.
The current version of my implementation is almost 7 months old and yes, its not very polished, to say the least.. I have a refactored/rewritten branch in the works, but that'll take a while. This version of game uses C++ and makes heavy use of OOP-concepts (at least the new branch), so it is not pure C based as your version is. This could prove difficult regarding a possible collaboration, at least code-wise. But this doesn't mean I'm not willing to do so.

As for the possibility to modify the game, I spent the last three weeks creating an editor. It is limited to simply editing cards by now, but template modification (custom card backgrounds and so on) and a script editor module is planned (you can script card events with lua in Arcomage Tribute). I'm also in the process of forming an Arcomage-Deck C++ API & technical documentation to allow other Arcomage clones to load those decks. The API will be object oriented as well, tho. But porting it to C shouldn't be that hard, since it mostly uses wrappers for C libraries such as zlib (packing) & expat (xml based data). I'll cut the technical gibberish here, since it shouldn't be too interesting for most users in here.

We'll the dev just sent me the updated version, but I can't release it yet I'm doing bug checks for him.

As for that, thanks for testing, he's the only QA I have before releasing it to the public.

[GreatEmerald]

I have things like exchanging information in mind. For one, it would be very neat to utilise the same card creation system you guys have in the clone project. And how are you managing configuration right now, if you are looking into it at all?

[Xography]

I have things like exchanging information in mind. For one, it would be very neat to utilise the same card creation system you guys have in the clone project. And how are you managing configuration right now, if you are looking into it at all?

We're using Redmine for Project Management, with GIT for configuration management: http://redmine.gatewayheaven.com/projec ... repository (which is wrapping http://git.gatewayheaven.com/?p=arcomage.git )

Edit:
Oh wait, if you're looking for the editor, it doesn't have an own repository yet - it's located under sandbox/Tools. I just pushed the latest changes...

[GreatEmerald]

I'll have a look through it, then.
Hmm, could you briefly describe the way the lua code interfaces with the program? Or which file is responsible for that?

By the way, I'm thinking about interfacing D static libraries to use with the C executable so it would be easier for me to program things (I'm primarily an UnrealScript coder, so C feels very restraining to me, but that's what the original author used). So I'll see how that works. If it works well, I will be able to code a lot more efficiently!

[Xography]

I'll have a look through it, then.
Hmm, could you briefly describe the way the lua code interfaces with the program? Or which file is responsible for that?

By the way, I'm thinking about interfacing D static libraries to use with the C executable so it would be easier for me to program things (I'm primarily an UnrealScript coder, so C feels very restraining to me, but that's what the original author used). So I'll see how that works. If it works well, I will be able to code a lot more efficiently!

Integrating Lua is quite easy:
You basically just have to set up the bindings and wire them into your program:
http://redmine.gatewayheaven.com/projec ... script.cpp
http://redmine.gatewayheaven.com/projec ... ptbind.cpp

I'm sure there's a better way, like exposing classes directly and so on - but it works. There's also a tool which does it all that for you (including C code generation): http://www.swig.org/ (haven't used it yet, but I've seen many lua binds done with this tool).

I'm not too familiar with D, but I understand that C might make you feel restricted, since it's very low level and doesn't provide the utility constructs one is used too. I personally prefer C++ and Java, D seems to be something inbetween those, so its a matter of taste I guess. Although you are the first person who actually mentioned D in a very long time.

[GreatEmerald]

Ah, I see, so you send the LUA static library the info on the first LUA script (startup.lua) and let it parse the script, then use the events it calls after parsing to do things within the C++ code again. Very nice. Also neat how you have the deck as a separate class. And how easy it is to read your code

One more, thing, how do you clean the SDL event queue/prevent SDL from capturing clicks while the animation/enemy is playing, so you couldn't accidentally click the card twice?

I'll look into Swig too, it looks interesting.

Yeap, D is between C and Java (and the good thing is that you can use around three approaches to the same problem - C style, C++ style and Java style), as is UnrealScript that I'm most used to. Thus adapting is relatively easy. It's also good that D is constantly being developed - 2.051 version of the official D compiler was released less than a month ago.

Hmm, it seems that D .lib files use the free OMF specification rather than Microsoft's COFF, and MinGW uses only COFF format. That means I'll have to use another compiler for that... While it's not much of a problem for me, but others might have one. Then again, there are already problems with SDL, so I guess another requirement won't be that much of an issue here...

EDIT: Also, huh, I just had an idea. Compiling things can get quite tedious with a lot of requirements (Microsoft! ), so why not have a virtual environment for that. It could be easily transported between real systems and the executables work everywhere as well. That would also allow for easy testing on Linux. Hmm.

[Xography]

One more, thing, how do you clean the SDL event queue/prevent SDL from capturing clicks while the animation/enemy is playing, so you couldn't accidentally click the card twice?

As soon click on card gets processed, an animation starts and I simply lock the UI, preventing other clicks from being processed until the animation (or enemy) is finished. Quite simple, just requires a variable in the UI Manager and a function to check for it everytime a user clicks :p.
The SDL events get processed in a switch case statement, with simple breaks in case of a matching condition, this does the 'cleanup'.

But readable code? At least not online, I took a look at it in the browser and the formatting is horrible, since the line breaks and intends get screwed up a lot, mainly because of different intendation settings (I think VS does real tabs, whereas the Unix-standard is 4 spaces or was it the other way round..?) and the notorious CRLF .

[GreatEmerald]

Huh, of course. That makes sense! And I should be able to incorporate the UI lockdown into the current code with like one line. Thanks!

Bah, semantics, it's readable because it's logical, not because of tab placement You have no idea how difficult it was deciphering what STiCK wrote in the original Arcomage Clone code. For instance, "q" variable is actually "the queue of card IDs to be played this round before shuffling them".

[GreatEmerald]

OK, pushed two bugfix commits today: one solves the queue bug (literally a one-line fix that does wonders), and the other solved the bug where the numbers would disappear if you got more than 9 quarry/magic/dungeon levels. The latter also rewrote the way the program handles text display as a whole, so it's now actually readable.

[GreatEmerald]

Another bugfix here, this time I solved a problem with resource distribution being slightly incorrect in the older versions. I think that's the last bug and I will probably go implementing new things now.

[GreatEmerald]

Just managed to compile Arcomage under Linux with my Debian virtual installation. So I will now be able to make sure that it runs right under Linux as well. Have to figure out what it requires first, though.

Also tried combining C and D on both Windows and Linux and it works fine (after a few changes to the code), so I will be able to code parts of the code in D.

And working on a "red border on mouse hover" feature as in the original Arcomage.

[GreatEmerald]

Quite a few important changes that you'll like to hear: first of all, I have created a /bin folder in the Gitorious repository. That means that if you want to download the latest test version, you can do that at any time without the need to recompile the code from scratch. I have also included all the necessary DLLs and config files that you need to run the game. However, note that you will have to put the data folder inside the bin folder before you can play. I am still working on configuration of the location of the data folder (with which D should help a lot).

In other important news, I have now upgraded from SDL 1.2.8 to 1.2.14. This should help people who use Linux, where repositories usually have only the latest version of SDL and SDL-devel. The code was slightly altered to accommodate for the change (which is a commit changing mere 3 lines, actually).

Now about D: I have now entirely switched from compiling with MinGW to the Digital Mars C compiler. That is necessary in order to support the static libraries that the D compiler produces (which is in the well-defined Intel OMF format as opposed to the Microsoft COFF which is used everywhere these days). However, DMC is actually a lot easier to work with than MinGW ever was, so it's a really welcome change. You don't even need the Makefile any more, or have the compiler directory in your PATH. I haven't started implementing D there just yet, but I have tested integration with C separately on both Windows and Linux and I'm sure that it will work fine. On Linux systems, you still compile with GCC since it uses open library formats to begin with.

As for Lua, the integration is complete, only needs testing and actual code being written. So yeap, the project indeed involves three programming languages now I guess I should make a D to Lua parser some time, though.

About what's being planned: I have been looking into MArcomage for a while now, and I'm pretty sure I can support everything it can. That will make things a whole lot more original, strategic and fun! And also random.

[GreatEmerald]

All right people, I need your input on this one. I am going to rewrite the rendering system so you could set any resolution you want instead of sticking to VGA. I am also going to include all the extras from MArcomage into the game. But that raises a question: how do I do it and preserve a layout true to the original?

First off, I should note that in order to integrate MArcomage features, I will need to implement these things:
- Seeing both your cards and enemy cards
- Seeing what cards both you and the enemy played during the last turn
- A list of cards in the currently selected deck
- Keyword support
- Token counters
- Support a hand with up to 8 cards

Naturally, if I was to preserve VGA resolution, all of that wouldn't fit into the window. But I could create two new buttons: one would show your deck and the other would switch the view between your cards and enemy cards. There is also sufficient space for the token counters. However, if you were to play the game on a higher resolution, then there would be no need for such buttons - you would have enough space to see both your and enemy cards simultaneously. So the question is - should I: a) create buttons, b) drop low resolution support or c) create a mixed system where on low resolutions the button system would be used, while on high resolutions cards would be drawn normally?

Another question is what to do when you have too many cards in your hand. VGA only supports 6 cards, while the default for MArcomage is 8. The original Arcomage game stacked the cards in a way that they overlap - however, in that case it's really difficult to read what the card does, so it would be rather problematic to play this way. My idea is to use a sort of tooltip system - if you bring your mouse on a card, it gets highlighted and drawn on top of the other cards. However, here's the question: should the cards stack like in the original game, like this:
http://imgh.us/Cards1.svg
Or be stacked in a more 3D way, like this:
http://imgh.us/Cards2.svg
(Note: Your browser needs to support SVG to see those. And if it doesn't support SVG, what cave are you living in? )
The advantage of the first option is that it would take a lot less vertical space; however, you would be able to see less in a glance. The amount of space the second option takes means that it can only be used to display the history, not your current cards, unfortunately.

And last but not least, for HD resolutions I need HD content. If anyone could create or find a way to get artwork that would be in the spirit of Arcomage (that means a castle in the background with hills etc.), it would speed up the process quite a lot.

As for the progress on the program: Lua scripting works very well. I have moved all of the cards from C to Lua, so anyone can edit them (and, more importantly, create their own cards). I'm now working on mod support (supporting more than a single source of card code so that the official and custom cards wouldn't become mixed), but in order to draw the MArcomage cards, I need to draw the card background and then their images, and lastly supplement all of that with actual font support. And that leads us right back to supporting more resolutions!

Another interesting this is that the original programmer is back. Though I'm still in charge of development, he will help with things like building RPM packages for Linux. He also moved the code from Gitorious to GitHub (since the former had really odd issues with the server going on).

Oh, and since this is now quite a bit different from the original version, I've bumped the version up to 0.4.0-GIT now. The stable release will probably be 0.4.1 or something like that. Naturally it requires you to have Lua installed now.