[New ship models and implementation of action cards]

New ship models and implementation of action cards
 

Created a back-end server and allowed user creation & login


I decided to give up on having two functions on each card and, instead, have each picked fleet card also add 0-2 action cards to your deck. Also, testing on Android, I realised that animating the cards was more trouble than it was worth and also implemented some other optimisations to allow that version to work at a reasonable FPS.

[Progress so far...]

Progress so far...

[Name:]

Name: Space Fleets (Working Title)
Description: Turn-based, tactical space battles on small hex map, with card game elements.
Engine: Unity 5.5 Personal Linux
Platforms: Win/Mac/Linux initially, then Android then iOS
Inspiration: World of Tanks: Generals, Cards & Castles, Panzer General: Online, Ironclad Tactics

Battle view


Fleet (deck) construction view


Battles are fought over a number of turns (alternating between the two players, that can be human or AI, local or remote). Players first construct a deck from one mother-ship card and 9 squadron cards (multiplied so you have 3 of each fleet card in the deck you play from), then they can battle on the small hex map until someone's mothership is destroyed. Each ship card in your deck also adds 0-2 action cards to your deck.

The intention is to make this mainly an online PvP game (play when you want, rather than real-time), but with a single-player campaign for practice (and to unlock new cards for the different factions).

I've mainly worked in 2D before for my own projects, but I did build part of the new 3D engine for Unity of Command 2, so I'm reasonably used to working in 3D.

Haven't achieved much in the last couple of days, working on optimising parts of my graphics engine a bit. I added line of sight using the distance field (the enemies now turn and run at you, but only if they see you). Tried to add wall-sliding to the physics code, but everyone just gets stuck on the walls even if they are trying to move obliquely along them; doesn't matter so much for the enemies, because they will have pathfinding eventually, but I need to allow the player to be able to move close to convex walls without sticking. Wondering if rolling my own physics was such a great idea after all, but I couldn't see a good way to integrate dynamically-shaped terrain with a polygon-based physics engine

As an appendix to the last post, here is the mask of the solid terrain (greenish shows blocking terrain) and the resultant distance map (lighter shows areas a long way from blocking terrain):

terrain mask:


distance map:


superimposed:

Originally, the game had used tiles and Chipmunk physics for each of the square wall sections. I just changed to a completely free-form map and was a bit perplexed how to efficiently continue to be able to prevent my objects from hitting the walls.

The answer was a distance map. First thing I tried was to implement it in Ruby (A high level interpreted language), but it took 1800ms to generate one for my level map and wasn't terribly accurate. The size of the yellow squares indicates the clear distance from a wall:



I re-implementeded the algorithm as a GLSL fragment shader and now it takes 10ms to generate and is at least a thousand times more accurate (it calculates distance for every pixel and looks for blocking terrain in more directions and steps outward from that point at lower intervals)! Ha!

The brightness of the floor indicates the distance from a wall - I set r/g/b channel equal to the distance, in pixels, from the nearest wall. To prevent collisions with walls, all I need to do is ensure that the object's collision radius is lower than the red channel of the pixel it is moving to. This information will also allow me to work out navigation routes around the map allowing for smaller creatures to know they can fit through smaller spaces.

The red dots are points guaranteed to be far enough from a wall to allow any object to spawn (I need to move those about a bit so they don't look like they are tiled :D). The entities have their collision circles drawn on to show their "real" sizes.

[Links]

Throckmorton

This is a twin-stick shooter (move with keys & aim with mouse) where you dungeon-crawl through a cavern system. The gameplay is relatively simplistic (you have health, energy and two attack modes: direct shot and AOE burst); I'm aiming for a level of complexity similar to Alien Swarm, I think.

Map and texture generation is entirely procedural (mainly based on Simplex noise), which is poor quality at the moment, so I need to work on it a lot. Each level layout is based on a simple seed, so sharing levels would be effortless.

Ultimately, it is intended to be run in networked coop mode (2-4 players, depending on how well that works out; it is designed with that in mind, but I haven't made it actually work like that).

I am using a dynamic shader-based line-of-sight lighting system, but it is glitchy at the moment, so I've disabled it for the screenshot.



Links
* Github project (Implemented in Ruby and C and glsl)
* Wiki (Includes description of what is currently implemented as well as a todo list).
* Early devlog (it still had tiles back then :D)

Gave the demo a quick go and it felt pretty good! Been following your progress for a while and was interested to see how it went. I realise you are in early alpha, so some of my comments may well be irrelevant.

* I liked the way fire worked and that missed shots actually went somewhere, rather than being abstracted entirely. However, it sometimes wasn't obvious whether the shot hit the target or a nearby wall.
* Being able to shoot just above the horizontal walls, but being unable to walk just above them was a little odd. I understand why you can't allow movement there, since it would hide people, but letting fire go there was not entirely expected. Perhaps the base of walls should be half-way through a tile vertically, so that it blocks that tile for movement and fire and just covers the feet of characters walking in the tile above it?
* Sometimes the rosette around character, or the tile you will move to, has more than one color (e.g. some arrows will be red and others orange). I wasn't entirely sure if this was a bug or a piece of information being given to me via the UI that I wasn't comprehending.
* I didn't like losing the mouse entirely when moving or firing. Perhaps set it to a neutral shape and make it inactive rather than completely hiding it?
* I'd prefer to have map grab, rather than map-move, on right-button. That is, change to a hand icon and pull the map around, which is just the inverse of the current map-scrolling movement.
* Seemed to be able to see through half-horizontal walls a bit too easily. Are they completely transparent or do they fill half the tile? I'd expect the later.

It is great, but the colour of the purple bar doesn't work well, but I can't explain why.

I suspect that reading the walls would be a lot easier if they were complete loops and not just free-standing blocks of bricks. The dark outline at the top of the horizontal walls does look fainter than the outline on the sides of the vertical walls though, which makes them merge a bit more.

My games, each in 25x25 glory:

Just noticed this and really like the clean vector style (I think anyone who wants simple now goes for big pixels, including me). Look forward to seeing more of this and how game-play progresses. Good luck!

Did quite a few little things:

* Actually implemented elemental combat (Blunt, Electric, etc.) and show overall results of dice rolls in log. Haven't bothered to actually show what dice are rolled and what each die shows yet.



* Gave up on having multiple actions per turn and just have one per character (saves clicks and the main effect I wanted from it, specifically having some abilities use 2 actions, can be mimicked by other parts of the system, such as requiring energy).

* Implemented resistances (roll less damage dice) and vulnerabilities (roll more damage dice).

* Added status effects, like burning and poison. In doing this, I changed a few things:
  - Mental damage prevents action for a number of turns, but can still move.
  - Poison reduces movement slightly, as well as doing damage over time.
  - Burning now does 2 damage per turn, but is less likely to have effect.
  - Changed cosmic damage to sap super-energy over time (if you have any), otherwise acting like poison.
  - Rather than sapping a set amount of movement, hold damage now just prevents movement for a number of turns. Maybe should add a special ability to "break free" when held, using your action to reduce number of turns held.

* Added knockback effect and secondary impacts (you get knocked back N tiles, but can give and take Blunt damage if you hit anything before you run out of impetus).

* Added some powers that use energy, specifically Second Wind (self-heal) and Flurry (get extra action). Probably should try to implement some of the more messy powers, like pet summoning or area effect attacks...

I had another go at the dice and I'm a lot happier with them. Some of the 2s are very unclear, but only some dice will have a 2 on them so it matters less.



@udderdude: Your point about determinism is noted. My system is based on ones quite commonly used in board games like Descent or Space Hulk, which are inherently quite random because they are intended to be more fun, beer-and-pretzel games. Remember, however, that the dice include the effects of to-hit and damage in a single roll, so they aren't as random as they appear. e.g. with a average superheroic melee/crushing skill of 3, you roll 3 dice, each with 0,0,0,1,1,1 on their faces (effectively 3d2 if you are a pen-and-paper RPGer). The probabilities are 0=> 0.125, 1=> 0.375, 2=> 0.375, 3=> 0.125 (average result will be 1.5), so it is a nice bell-curve, but does allow for rare fumbles/misses (0) and criticals (3).

As an alternative, if it had 50% chance to hit, but always did 3 damage, it would have the same average, but would never give a 1 or 2 result. The only properly deterministic result would be to always do 1.5 damage, or 1-2 perhaps as a compromise since I don't manage partial health points, but in both of those cases you can't miss. Sorry if you fully understand the maths; just clarifying it for everyone in case anyone else wants to throw in suggestions.

[EDIT: The other common number of dice to roll are 1, 2 and 4:
       1 dice is: 0=> 0.5, 1=> 0.5 # Not a bell curve here
       2 dice is: 0=> 0.25, 1=> 0.5, 2=> 0.25,
       4 dice is: 0=> 0.0625, 1=> 0.25, 2=> 0.375, 3=>0.25, 4=> 0.0625]

[EDIT2: Hmm, Piercing, which is has 0,0,0,0,1,2 on its faces, is a bit more random since rolling 3 of them gives a range of 0-6 rather than 0-3, although the average is actually the same and you only have 0.5% chance of getting a 6 out of it!]

Well, not a lot of progress in terms of code, but I've planned out the next few steps of development. I did some thinking about damage types and came up with a set of dice to calculate the effects (if you have an attack at skill 3 which is crushing/knock-back, then you roll 2 crushing and 1 knock-back dice. If the target is vulnerable to crushing, then you'd roll more crushing dice; if resistant to knock-back, you'd not get any knock-back dice at all).



Dice are, left to right:
* crushing (hp)
* fire (hp over time)
* poison (hp over time)
* electric (hp)
* piercing (hp)
* mental (lose actions)
* hold (lose movement points)
* knockback (move away; may take secondary damage from hitting objects or walls)
* cosmic (each dice will be randomly chosen from one of other damage types each time it is used)

I'm happy with most of the symbols, but really not happy with the piercing/knockback icons looking much too similar, but I couldn't think of a more differentiated pair of symbols (at this resolution). Maybe I'll try again with a pushing hand, but I'm not hopeful it will be clear.

I'm not totally committed to having a dice-based, rather than a more abstract, system, but I do think it makes it easier for the end-user to comprehend the probable effects of their actions. Unless I think of something that is really incompatible with this system, though, I think I'll keep to using virtual dice (though I don't want to make a big deal about rolling them, as some games do; I'll just show the results in the game log).

Full details of what is on each dice, as well as more details of what abilities I'm planning to implement and how they work is on the wiki. Also I've made a preliminary list of all characters in the game and their powers.

Well, I spent a few days playing with making Robin, my turn-management server, although a significant chunk of the time was lost to annoying technical problems caused by moving into a completely new sphere (hosting apps in the cloud). You can now create players, upload and download maps, challenge people to games and send your action data to those games - abstractly via a console, at least; I haven't even considered creating a GUI to interact with the server

As I said earlier, the server has a RESTful interface, which I think was a good choice. It is both significantly easier to test, since each operation is separate, and it also suits the disconnected nature of the game. The intention is to allow people to play at the same time and sync as moves are made, but also allow for submitting turns, or partial turns, at any time. I also realised I had picked a server architecture that was mostly game-neutral, so I thought I might as well branch that off and make it a separate project which conceivably might be of use to someone else making a similar game.

Interestingly, designing the server opened up a few important things about the game as a whole, for example that if I want to avoid cheating, I need to post an action onto the server, then the server pass back a random seed, which is then used by the player to calculate what happens in the action submitted; they will only stay in sync if they both do the calculations from that seed correctly. Perhaps it isn't something I should worry about...

A bigger problem that I stumbled upon is how to manage AI when playing in online COOP mode, as well as how I'm going to serialise its forward planning when the game is saved and loaded (my intention is to make the server entirely dumb and not understand what it is doing beyond a concept of turns; the client can verify the data coming in is reasonable and reject it if it has been tampered with).

Although it was interesting to spend a bit of time on some server investigations, I can't wait to get back to the meat and bones of the game itself

Haven't checked this thread for a while and it is always good to see progress. Saw some ideas I wanted to steal, but thankfully not all of them :D

Reminded me how you can get away without a large GUI being on-screen all the time, but I do think that you've gone a bit overboard on that. I think it can be just as distracting if a lot of info is flicking on and off the screen too. I felt the problem with the expanding tool-tip was that the unexpanded bit shouldn't change when it expands (repeat the info when expanded if you really need to expand the details).

Hope the game release has gone well, but also to see you return to developing this one soon.

Yep. Those are good points. I am all for multiple redundancy of information, though as people have pointed out, the current build is extremely noisy because everything is shown at once.

Also, if you play in the standard window (800x600) the GUI is extremely oppressive. The reason I allowed that was because I wanted that as the minimum size the game _could_ be played. In full-screen mode, the GUI doesn't resize, so it is considerably less in the way. If you have a build, then "smash_and_grab.exe --fullscreen" might be useful; I'll do that with config later, but I'm trying to avoid working on things I have done plenty of times before in other games, until much later in the development cycle.

Today I fancied a change, so I'm working on making a MP server that manages game turns (similar in function to the one used by Frozen Synapse or Unity of Command). I doubt I'll have it working for a while and really at this point I'm just exploring the possibility. I decided to use a RESTful server, which suits a turn-based game where you can play your turns at any time, backed by a MongoDB database and hosted at Heroku.com - we'll see whether this is a good choice later

What is nice is that people have a lot more interest in this game than others I've done, at least regarding willingness to test it and even to comment on it Thanks everyone!

Thanks very much for taking a look, Franklins Ghost. Don't get too excited about winning though; the AI is able to do everything that you can, but is completely incapable of thinking. It can move and shoot and fight and grab items, but doesn't have any state or idea of actual tactics, so it attacks different enemies in every move and doesn't coordinate the units' actions at all!

Thanks again for everyone's comments about the game, which are helping me to feel encouraged to keep working on it Thought I'd try something different than my usual arcadey game and glad to know people are interested in this sort of format.

Yesterday I had a good talk to Ante, who developed the AI for Unity of Command to discuss some of the ways that game's AI was implemented. We didn't go to too great a depth, but I think that that sort of system is probably the best for S&G too. Separately, I found a description of a similar task-based AI manager, which describes it better than I could. That said, I'm not going to put any more work into the AI until there is a bit more of a game for it to play (rather than a bland team-deathmatch, which is pretty much all the current build amounts too).

Thanks for the support fellows!

Right, I added a co-op mode (so 2 players can have half the villains each, against the AI goodies). Could do it with 2 heroes versus villain AI, but I expect the attacker (villain) AI to be harder to manage. I suppose I could add "vengeance" modes later (heroes attack a villain's base) which would work in that way. Eventually I'd like to support on-line modes, but I'm not worrying about that any time soon as long as local SP/MP work

Added picking up and dropping of the cash-bags. The AI now tries to shoot/melee/pick-up/move in that order. No-one has a reason to drop them unless they are dead, though Thinking about having a super-strength stat and object weights so heroes can throw heavy things around.

Decided I didn't like stat bars and changed to using pips. HP is 1-10 and AP is 1-3, so that fits quite well. MP is 1-20 though (including super-sprint bonuses), so I stuck with a continuous bar there. It is also less critical than knowing the other stats, so that is fine. Although I'd originally conceived of HP values up to 20, I am thinking that is makes more sense to have a lower maximum health in-game with a lower maximum (e.g. taking a turn out to get your breath back gives a proportion of your HP back, which is in-genre, because supers get pummelled and get up again 5 minutes later all the time).

I seem to have fallen into a rules system that is very much like certain boardgames. Not sure I want to keep it as complexity increases though. Skills are 1-5, which corresponds to number of six-sided dice rolled. Melee dice cause damage on 4-6 and ranged dice cause damage on 5-6 (In a board game, you'd usually get custom dice with that many "hit" images on them rather than numbers). Not sure whether, even if I keep it this way, I want to expose these numbers in-game by showing what the dice results are (I can explain in a manual though). What do people think? Do you like "simple" systems that you can completely understand or ones that are a more complex simulation internally but are not understandable by the end-user (you just see the effect of actions)?