Sar
|
|
« Reply #140 on: May 22, 2013, 10:20:28 AM » |
|
Its interesting how people are willing to throw down 4 hours for a few thousand point battle in say Warhammer 40k, but potentially not online I think a good portion of this can indeed be attributed to the lack of socialization that happens from an internet turn based perspective. E.G waiting on an opponent around a table in the real world, tends to be a hugely different experience from doing so online. Partly, yeah - and because I only ever played tabletop wargames against people I was already friends with, even if the game wasn't that fun for me I didn't mind sitting around for an hour or two playing it out to conclusion because I could chat with a friend. I'm hopeful though that some of this can be mitigated with options like maximum turn times per player.
To be honest, this puts me off multiplayer even more - sure, it may mean the game isn't going to last quite as long, but it also means I have to feel rushed to think about things. (That said, I do personally like the interleaved kind of turn-based that games like Tactics Ogre have rather than the rigid I-move-all-my-guys-then-you-move-all-your-guys approach that a lot of tactics games have, which would remove most of the waiting problem for me at least.) The ability to move to an asynchronous mode would be a great boon to this kind of game in multiplayer, if you ask me - so long as it was implemented such that it didn't just give an open door to people who are willing to cheat to win (e.g. save-scumming etc.)! Of course, this wouldn't work so well with the interleaved approach I personally prefer, it'd be far too tedious without contiguous turns.
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #141 on: May 22, 2013, 10:41:08 AM » |
|
Its interesting how people are willing to throw down 4 hours for a few thousand point battle in say Warhammer 40k, but potentially not online I think a good portion of this can indeed be attributed to the lack of socialization that happens from an internet turn based perspective. E.G waiting on an opponent around a table in the real world, tends to be a hugely different experience from doing so online. Partly, yeah - and because I only ever played tabletop wargames against people I was already friends with, even if the game wasn't that fun for me I didn't mind sitting around for an hour or two playing it out to conclusion because I could chat with a friend. True though I was thinking of random games at game shops and such. To be honest, this puts me off multiplayer even more - sure, it may mean the game isn't going to last quite as long, but it also means I have to feel rushed to think about things.
Yeah this would be optional for sure. Some people like this type of play, like Spacehulk is really tense due to the hourglass timer for the space marines turn. Also have games like speed chess and so forth. The ability to move to an asynchronous mode would be a great boon to this kind of game in multiplayer, if you ask me - so long as it was implemented such that it didn't just give an open door to people who are willing to cheat to win (e.g. save-scumming etc.)! Of course, this wouldn't work so well with the interleaved approach I personally prefer, it'd be far too tedious without contiguous turns.
Yeah I'm pretty sure when it comes to MP other than hot seat, everything will be done on a central server to prevent the majority of cheating. I really want cheat free ladders and tournaments for instance. It also somewhat handles the annoying disconnect cheating that people often do. Instead of a game ending, it would be possible to wait for someone to reconnect (handling valid disconnects) or to just declare yourself the winner. Doing a central server also removes all the common problems of people not being able to connect to each other due to firewalls , nat , and routers that is quite common.
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #142 on: May 22, 2013, 08:53:08 PM » |
|
Well not a lot done today. Euro job stoled some extra hours of my day, but I did manage to squash a few movement map bugs.
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #143 on: May 23, 2013, 09:13:09 PM » |
|
So another slow day with most of it spent thinking about architecture, and how I want to handle the realities of SP, hot seat, possible LAN play, plus a company hosted online MP with many additional features.
One thing became fairly clear though, I need to start writing the server now, and just have a thin client, that can use a listen server for SP. Currently the client code is becoming more and more SP dominate as I race through engine dev, features and so forth to get to a nice prototype state. Yet this means almost all of the client needs tossed as soon as I want MP, which frankly I want for the whole prototyping and testing phase.
|
|
|
Logged
|
|
|
|
ColePowered
|
|
« Reply #144 on: May 24, 2013, 04:09:30 AM » |
|
This looks absolutely fantastic!
Did you ever play MechCommander? This is sounding like that mixed with Advance Wars/X-Com which is a winning combination in my book.
I have to say however, I'm also definitely more of a fan of the single player, especially when it comes to turn based games like this. I think part of it may be that there's a pressure to hurry up and make your move when you're aware the other player is waiting for you, and I like to play at my own pace. There are some who get a kick out of the pressures that PvP imposes, and others who find it stressful.
Personally, I hope you don't neglect the single player experience too much, even if it's just a skirmish mode with mostly decent AI I'd be happy. But by the sounds of it you are very passionate about the MP which I'm sure will be awesome for those that enjoy it.
Good luck! I'll be following this regardless as it's beautiful and I have an appetite for strategy games like this!
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #145 on: May 24, 2013, 02:13:28 PM » |
|
Thanks Colej_uk, and no worries, I'm sure the single player mode will receive lots of love as well. We realize its hugely important to a lot of gamers, and also tends to be fundamental to also teaching the player how to play the game.
|
|
|
Logged
|
|
|
|
happymonster
|
|
« Reply #146 on: May 24, 2013, 02:22:22 PM » |
|
Can I suggest something? Have you tried making the ground floors a slightly different hue and brightness than the buildings? They look all the same range at the moment, and I think if it was subtly different it might help..
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #147 on: May 24, 2013, 03:10:51 PM » |
|
Can I suggest something? Have you tried making the ground floors a slightly different hue and brightness than the buildings? They look all the same range at the moment, and I think if it was subtly different it might help.. Sure suggestions are always welcomed I'll pass that on to my partner who is in charge of the art, thanks.
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #148 on: May 25, 2013, 07:31:44 AM » |
|
Which library/framework are you using for the game? SDL(+OpenGL), SFML or something else?
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #149 on: May 25, 2013, 10:03:21 AM » |
|
Which library/framework are you using for the game? SDL(+OpenGL), SFML or something else?
Our own custom framework, which for pc, Mac, and Linux uses GLFW for window setup and input. OpenGL for rendering, and irrKlang for sound. The big hunt at the moment is a suitable network library. I don't want to have a thick client with tons of code duplicated between it and the server. However SP mandates this, or that I have a server component also built into the game and just have SP use a listen server. This has put a kink in my plan to just use a async based tcp/ip C# server for MP. So I've accepted writing the server in my lovely c with classes style, but am having a hard time finding a network library I like. ASIO looks like what I want in general, but the boost syntax kills me. I might end up using libuv which powers node.js though I'm not exactly a fan of it either, and it lacks some nice bits like ssl support. Lacewing is something I'd like to use but its pre 1.0 and so far my attempt to use it has resulted in a bunch of broken yet vital functionality. Still I'd rather not have to write my own non-blocking/iocp based network library per platform. Enet is very tempting despite being udp, but it just doesn't seem like it scales well enough. As such the search and evaluations continues =/
|
|
« Last Edit: May 25, 2013, 10:12:08 AM by Gregg Williams »
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #150 on: May 25, 2013, 11:18:22 PM » |
|
Alright after way to many hours staring at ASIO and Libuv, I've decided to go full speed ahead with ASIO. This should let me write server code that should scale to the thousands or possibly tens of thousands of clients thanks to using IOCP on Windows, and similar systems like epoll on linux. (A lot is dependent on the hardware and server coding though, ASIO could probably handle hundred of thousands of clients if the server was simple.)
I'm familiar with working with async sockets thanks to my many years of mmorpg work, so I don't expect to many problems, though I'm certainly new to doing it in C++. ASIO also has some bits like built in support for SSL, which is nice when you start wanting to actually do accounts and authentication across the internet.
Design wise theres a bit of interesting stuff to consider, as instead of a server that is managing just say a list of connected clients, on a given map, I'm really dealing with a server that is managing a list of active game sessions, each of which has its own players, map, game state and so forth.
In the end though, I expect the other service style systems to be more difficult to nail than the actual game server. Things like lobbies, patching, account back end, custom map distribution, and so forth. Thankfully all of that can come much later.
|
|
|
Logged
|
|
|
|
matriax
Guest
|
|
« Reply #151 on: May 26, 2013, 02:14:46 AM » |
|
Retromite is happy to announce its next project M.I.N.T has finally begun active development, and besides doing weekly updates on our blog we've decided to do a much more frequent and detailed development and design log here. M.I.N.T is a turn based tactical wargame that is skirmish oriented and draws inspiration from traditional table top games like BattleTech, and Warhammer 40k as well as from a long and rich history of both wargames and tactics games in computer form. The game will feature single player, as well as multi-player modes with support for both hot seat and online internet based play. We're currently aiming to support online ladder play, clans, and custom map sharing. M.I.N.T has just started development using our own C/C++ framework and is in the very early stages of game engine development and prototyping. As such there isn't much to show currently in that area, but it does have a fair bit of initial artwork completed that you can see below. Overall Mockup
A few Initial Unit Designs Awesome pixel-art :O all seems have too much hours of work. How many pixel-artist are working in the game?
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #152 on: May 26, 2013, 08:29:30 AM » |
|
Awesome pixel-art :O all seems have too much hours of work. How many pixel-artist are working in the game?
Cheers, just my partner at the moment.
|
|
|
Logged
|
|
|
|
rivon
|
|
« Reply #153 on: May 26, 2013, 08:38:21 AM » |
|
I thought that the game is supposed to be a TBS, not MMO... Why the need for support of thousands of clients?
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #154 on: May 26, 2013, 08:50:42 AM » |
|
I thought that the game is supposed to be a TBS, not MMO... Why the need for support of thousands of clients?
The current plan is for us to host the online server/servers, and other online bits like a battle.netish lobby, ladders, support for clans and so forth. I doubt we will have thousands of concurrent users, but it pretty much just happens that the technology best to scale is able to support tens of thousands or more connections at once. Where as doing something like a thread per socket or even a select based approach (depending on OS) can hit limits very quickly. Of course it would also be nice if the server didn't melt if we did end up with a huge success. scaling is a good thing.
|
|
« Last Edit: May 26, 2013, 08:56:27 AM by Gregg Williams »
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #155 on: May 26, 2013, 07:29:34 PM » |
|
Lazy day, but have tomorrow off as well. Yay Holiday?
Anyways, figured out most of boost:bind, and got ASIO basics like socket listening, connecting, async reads and async writes working.
Need to make some supporting systems for pooled buffers, sockets, circle buffers, then really set into building the network loops.
I imagine unless I run into serious problems I should be back to where I was by the end of next week, except instead of a thick client with tons of logic, I'll be running on a thin client, that just connects to a listen server that also gets initialized during startup.
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #156 on: May 26, 2013, 08:53:47 PM » |
|
Also with switching to the client/server model fo SP it should be trivial to also offer LAN support. Not that i know if anyone actually uses LAN play anymore.
|
|
|
Logged
|
|
|
|
Impmaster
|
|
« Reply #157 on: May 26, 2013, 09:06:03 PM » |
|
Students do.
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #158 on: May 26, 2013, 09:39:23 PM » |
|
Students do. Cool, thanks. I'm old and know nothing of students. Last LAN party I did was probably 10-11 years ago
|
|
|
Logged
|
|
|
|
Gregg Williams
|
|
« Reply #159 on: May 27, 2013, 09:34:56 PM » |
|
Well got a fair bit done today on the server side. Socket Pools, basic net state type class that encapsulates each connection to the server with read support, and other functionality like idle connection detection and disconnects. Also incorporated the TinyThread++ library https://gitorious.org/tinythread which seems to be quite nice, portable, and minimal in scope. Currently using it for mutex support, but I suspect actual thread spawning will happen soon enough. Next main steps are really some sort of receive buffer pool, send queue per net state instance, base packet classes/writers/readers/handlers, and the main packet processing pump. I may also look at seeing if I can figure out C++ signals/condition variables, so that the server loop only runs when there is actual work to do. Oh and figure out how to disable Nagle.
|
|
|
Logged
|
|
|
|
|