@Simon work on the multiplayer server for UTTT and Battleship, and have a bot fight with maaartinus. And get rid of that reload spam when things are saved
@SimonAndréForsberg I could see going one of two ways right now. I agree with @bazola that improving the UX to make it feel more like a real game would go a long way in attracting players
Artwork for Mythos would be relatively easy to get, since there's plenty of public domain and CC images just on Wikipedia for the different deities/characters
Code-wise, though; I could see that improving/Groovy-tizing more of the core components of the game would be a good thing too. Go back over some of the earliest game code like the ECS stuff, and simplify (and document) to make the code more maintainable and easier to implement new things
But, I think we agreed for 0.7 that we should really improve the GUI, and I'd be all for that. If you guys can find a way to get card images on there, I can volunteer to do the actual graphical part in Photoshop and get images in a format that's practical and economical enough to use for a TCG
Game code-wise, I think it would be reasonable to perhaps just improve the proverbial "low hanging fruit" and just implement some of the issues related to moddability, and keep core refactoring for later. The main moddability/card issues are documented in comments principally in the Greek cardset
Jay had come up with so many effect types we don't support yet, so I opened issues for each and commented the issue # in the cardset
Two random bots and a GUI plugged in, so I could see it playing. But it's backwards, I have to make an GameActor which gets started from the GUI and creates a connection to you.
@maaartinus A hopefully easy approach: How about having two comboboxes, one for each player? Whenever the selected value of the combobox change, you do: actors[comboboxIndex] = isOn ? new ActorAssociatedWithComboBox<>(INITIAL_GAME) : null;
@SimonAndréForsberg I'll try it when I'm done with my ActorChooser.
@SimonAndréForsberg Probably something like this. I'm not up to the task yet (woke up one hour ago, it's too early to switch my brain on, still booting).
@Lokkij Well, I'm not sure it would fit for either of the mods we have now (would have to see some of them them to be sure) but there's nothing stopping us from making another mod with them, if you'd like to
I don't know much about the code, but I think that something that really needs to be improved is the GUI. When I was playing a few days ago, I was clicking around randomly because I could hardly read anything that was on the cards.
Mhm. I wonder if perhaps we could split up the work a bit. The GUI is Java rather than Groovy language, I know @bazola and @Simon are familiar with libGDX
If we figure out how we want images, they can probably show me how to write the code for each cards once we figure out how we will do it
So yeah, what do I think is the most important for cardshifter right now? Definitely the UI. Better UI --> better play experience --> more interest in the project and quicker/more fun playtesting
The hard(est) part about the GUI will be to make it moddable, but I think the best solution for that is to just implement something, write as ugly and non-flexible code as you want, and then we'll look deeper into making it more moddable later on.
The beauty about the client is that there's nothing restricting us to only having one client. I'd be interested in seeing a pure HTML/CSS/JavaScript client, as that is something that I think is easily moddable. LibGDX can be tricky stuff for those who don't know it, but has the advantage of supporting the most platforms.
@Phrancis as in, from scratch HTML/CSS/JS. LibGDX does not support HTML elements and CSS like that.
If anyone is interested in writing a HTML/CSS/JS client, remember that there are other options than pure JS out there. There is for example the "Dart" language, and many other alternatives as well, that compile to JS.
I'll gladly volunteer to help with HTML client to the extent I can. Just don't know much about the backend stuff, but I can probably do quite a bit of front-end
So perhaps it could be in the cards (pun intended) to include an image link as part of a card's attributes in the Groovy cardsets, and have the clients just parse that link and download the images at run-time?
Maybe have CSS setups parsed in the mod Game config files...? Wonder if that would be possible, but if it were, it would allow HTML version to look different for each mod, if we wanted it to
@SimonAndréForsberg Honestly, not sure about the "how" part. I imagine we could probably use the existing Tomcat setup for the website and have the Tomcat server retrieve information about the game from the Groovy mod files right? (cards, rules, etc.)
Anyways, it would be neat if we could embed the HTML client into the web page, keep everything in one place
Perhaps including the CSS in Groovy is not a good idea, if we can do it from the client instead using JS or whatever then that would probably be better. I just don't really know what's available :)
I do think, if we can get images optimized for web, that might also work good for libGDX... since largely they would be small images we don't need very high resolution.
for me, I just don't have time to do much work on the GUI stuff. when there has been a bit of progress on it, I can help in making it more flexible. But I don't plan on doing much more than that.
I feel that I'm doing my part already, so I'd like to see others participate more.
> I'd suggest an unstructured format simply joining all the moves, just separated by newline. Something like this works universally for all games, assuming their turns contain no newlines. The client can simply reply them the way it plays received moves. So for UTTT you'd use something like "0 0\n1 1\n4 5...".
> Provide both clients with information how much time they spent thinking. This would allow a fair match between them. Obviously, there's the network and server delays which make this value imprecise, but with clients aiming at e.g. one second per turn, this can be ignored.
@skiwi appears to have left, but I was just thinking a bit ago perhaps he and I could try our hands at HTML/JS based GUI. @Simon you said perhaps JS AJAX would be a good place to start? I just want to do some reading and see if I can come up with something or at least an idea of the different parts that would connect with each other
@Phrancis I don't know how much time @skiwi has these days. But maybe @Lokkij and @SirPython would be willing to work on that also? @bazola would more like to work on the LibGDX side of things, I'd guess.
You could use JS AJAX if you would want to perform a request-response communication with the webserver.
For most communication though between the client and server, Websockets should be used.
I've done some livescript and I like it (functional tools! :D) but the community and surrounding stuff is much smaller than coffeescript (which is very similar)
From MDN: Note: The WebSockets API (and the underlying protocol) are still in active development, and there are many compatibility issues across browsers at this time (and even among different releases of the same browser).
XHR doesn't continually listen for incoming data, it's more of a request-response scenario. For Multiplayer games, it is very frequent to get incoming data without explicitly having requested it.
