next »

[Spooner]

'Smash and Grab' is a turn-based isometric game of 1950s comic-book supervillains pulling off daring heists. The mastermind chooses a group of villains from those under their control and must steal loot (e.g. cash or warheads) from a secure location (e.g. bank or military base) and escape with as much as quickly as they can. Each villain will have unique stats and powers and there is no equipment - the choice is in who you use, not what gear they are given.

The game is single-player only, but it will allow for multi-player later (Second player would control the defending Goodies).

Implemented in Ruby using the Gosu games library, it utilises my own GUI library and various code chunks recycled from my older games. It should work on Windows/OSX/Linux. I'm doing all my own art, so it isn't quite perfect, but I hope it is more than adequate for the job.

* Early development log (Shows some earlier screenshots)
* Github project

Heist mode (Radioactive Gorilla really hates G-men!)



Editor mode (Bank map - well, really just a test map)



Features implemented

The game implementation is a bit patchy, but is coming along. Not worth playing except as a rather uninspiring tech-demo.

* Orthogonal movement with path-finding, which shows where you can move, ZOCs and available melee locations.
* Three factions: Baddies (player villains), Goodies (heroes and police) and Bystanders (non-combatants):
  - Goodies have trivial AI (move next to a Baddie; melee if adjacent).
  - Bystanders have trivial AI (Move to random position they could move to).
* Characters
  - Stats - Health, action points, movement points
  - Melee (Rather simplistic implementation)
  - Sprint (Spend all AP to gain +50% move)
* Walls
  - Fences and windows cost extra movement points to travel through.
  - High walls block movement.
  - Individual wall sections become transparent when they cover up a person/object.
* All chracters and objects only have one image which I flip left/right. I'll add a little animation once I've got the game working a bit better and I've finalised the character design.
* Level editor.
* Undo/Redo - Both game and editor have an action history.

I really appreciate any feedback or suggestions you might make. Thanks for taking the time to peer at my game's development!

[starsrift]

I really like this game concept.

Dreaming of setting up Italian Job style heists.

[Franklin's Ghost]

Love the concept and think the game art fits in really well. Really liking the look of all the characters and think you've done a great job of grabbing that 1950's comic vibe.

Only thing I'm not sure about at first glance is the game name. Think it needs something more fitting with that retro vibe you've got going on.

But grab idea and can't wait to try it 

[Spooner]

Thanks for the comments!

@starsrift:
The Italian Job is a good inspiration, but although I have vehicles, I think they will just be used for scenery in the levels (and the idea is that you spawn in on your van at the edge of the map and have to return to it to finish the level). So sadly no Minis driving through pipes for you!

Levels I've thought of so far are a bank job (cash), space ship (alien tech), army base (warheads), Fort Knox (gold), Lab (plague bacteria), Museum (mummies), Police Station (evidence) and Prison (break out more henchmen). For now, though, just trying to get the bank job to work and when I realise how many more objects and scenery I need for all those others, I might just end up with lots of bank jobs .

@Franklins Ghost:
Regarding the graphics, I'm trying to keep it colourful and comic-booky, but trying to avoid using too many colours. Glad you feel it is OK; Always worried about my programmer art :D The people and small objects are intentionally flat, with the world, large objects and vehicles being isometric. I may have to redraw the people to be more isometric though, since I'm not sure if the mix works, but I'm going with it like this for now.

I'm not sure about the name either, but it needed a name to get it started. It sort of works, but is a bit generic (Smash and Grab may be a uniquely British term too?). When I fill out the storyline and gameplay a bit more, something more fitting might come to me.

[sabajt]

Always worried about my programmer art

well you could've fooled me, i like the art a lot actually - especially the vehicles!

[Spooner]

Thanks! I was particularly proud of the vehicles too, which I invested a lot of effort on a couple of days ago, in stark contrast to the place-holder trees which do look like genuine programmer art :D This is actually the first time I've attempted to make isometric graphics, since before now I've worked with flat or orthogonal graphics, so it is taking me a little while to get into the style.

You might be interested to know that my original sprite-work for this game was half the resolution it is now (My previous games have been at that lower resolution; about 8x8 pixels for regular people). I scaled it up and then tweaked it to add more detail and smooth the curves, but most of the people are still a bit blocky. I'm almost tempted to scale it again, but I know that the higher the resolution, the more work it is and the more frames of animation will be expected to make movements look smooth. Although my art is decent, I do think it takes me significantly more time to do than it would if I was primarily an artist, so I don't want to bite off more than I can chew!

[starsrift]

Thanks for the comments!

@starsrift:
The Italian Job is a good inspiration, but although I have vehicles, I think they will just be used for scenery in the levels (and the idea is that you spawn in on your van at the edge of the map and have to return to it to finish the level). So sadly no Minis driving through pipes for you!

Levels I've thought of so far are a bank job (cash), space ship (alien tech), army base (warheads), Fort Knox (gold), Lab (plague bacteria), Museum (mummies), Police Station (evidence) and Prison (break out more henchmen). For now, though, just trying to get the bank job to work and when I realise how many more objects and scenery I need for all those others, I might just end up with lots of bank jobs .

The appeal of heist movies, at least for me, is watching a well-planned thing unfold more or less on a precise timetable.

But I really like rpg-tactics games too. Either way you go, I'm excited to see what becomes of this. :D


And if you're not making it a recon->plan->execute style game, I may just shove that idea in my concepts file.

[J. R. Hill]

Digging it!  Although I'm not a fan of the 1px outline on stuff that's scaled up

[Spooner]

You mean the outline on the people, that is 1/2 sprite-pixel wide, not the outline on the move-arrow, which is one sprite-pixel wide? I tried with a one sprite-pixel outline, but it was much too thick around he low-res objects (it is added automatically, not by hand).

I am sort of considering having the outline one screen-pixel regardless of the resolution (at the moment it is always 1/2 sprite-pixel wide and that looks odd at different zoom levels). I'm still sort of considering upping the resolution again, which would mean I could effectively have a regular outline, but I'm scared of giving myself a massive amount more work to do

@starscrift
I'm still not 100% about how the game will play out, but I think it will be more about running in through the front door and throwing the police out the windows rather than careful recon and planning. There may be a level of stealth available for a few characters, but it won't be the norm. The map will always be visible though, so that can account for pre-action recon (I'm still undecided if you'll even need LOS to see your enemies, mainly because organised AI in a game like that would be an order of magnitude more messy).

There are a few games in the works that are much more about that style of heist though (e.g. Subversion and Monaco, I think).

[Spooner]

Wasted some time trying to redesign the sprites to look more isometric. I found that the current resolution images really didn't like being made isometric, so I tried doubling the resolution to more effectively show an isometric projection, but everyone ended up being really oddly proportioned (bottom row). Not sure if it is a lack of practice or just that my people, designed to be seen flat, don't look good in that projection.

On the other hand, I liked that I could add a bit more detail on the characters, so I experimented with other characters being increased in resolution whilst being kept as flat sprites (upper rows). This allowed several vague things to be cleared up (e.g. the reporter's notepad now has writing on it). On the other hand, this increase in resolution made me want to explicitly define things that were fine being blocky in the low-res version, but that then made them look a bit naff (e.g. the women's legs).



Note that I haven't outlined these sprites, but they would be outlined with a single pixel in-game (currently, outline is 1/2 a pixel). For comparison, the current sprites are about 16x18 for a person.

Any tips on avoiding those pitfalls? (I still haven't decided on final resolution - I think I started at very low-res mainly because that is what I'm used to, but I am wondering if higher resolution might not make more sense in the game).

On the code front, I'm not getting very far in my attempt to make a generic Ability class structure that would allow individual character's unique powers to be quantified. Previously, everyone just had the same set of built-in powers (melee and sprint), but once I think about adding a larger set, including continuous, ranged and area-effect powers, I need a more generic system.

[Spooner]

OK. I got sidetracked by other projects, but I've been working on this again in the last week or two. I still haven't decided about my graphics; I do think I am 50/50 on whether to double the resolution, but have discounted the idea of moving to isometric sprites, since they would be painful to animate and flat sprites feel more comic-booky anyway (good excuse?).

Worked on the UI and visual feedback a lot. Below you see Green Goddess about to shoot Stinger, with plenty of other options for movement. The small targets on the clear ground are where she'd be shot if she moved and the small explosions where she'd be meleed (eyes are her LOS).

It really feels a lot more like a game now: there are real choices to be made about where to go and how to fight, and the interface gives enough info (too much, actually, since nothing can be turned off yet). Still no sound at all, though. Thing is, it is effectively just a death-match at the moment, which is rather shallow and the characters are still rather bland, since they don't have much differential since they all have melee and sprint abilities and a few have a ranged attack(they have different skill levels in those though). Need to think about different powers, I think!

My usual composer has written me some music for the game. Sort of over-dramatic 50s SF B-movie style, which is good, but not worth using it in the game any time yet.

If anyone is particularly interested in testing at this alpha stage, then drop me a PM; I can give you an executable for Windows or OSX or Ruby source for Linux. Although written in Ruby, the fact that it it is effectively running > 200FPS (though capped at 60fps) on a 2.5Ghz machine, means I'm not worried about performance, but then in a turn-based game this shouldn't be an issue.



Implemented game features

* Play in single-player (Human vs. AI), hot-seat (Human vs. Human) or AI vs. AI modes. Bystanders are always controlled by the AI though.

* All characters can:
    - automatically attack if they have actions left in another player's turn:
      - get reactive melee attack against an enemy entering OR leaving an adjacent tile.
      - make ranged shots against anyone moving in their LoS and within range (over-watch).

* You can select your Baddies and/or Goodies to:
    - move around.
    - melee with enemies (Baddies => Goodies or Bystanders, Goodies => Baddies).
    - shoot enemies within range and LoS.
    - sprint to get extra movement (sacrificing all actions for that turn). Can be cancelled at any time (if you have enough MP left).
    - see indicated:
        * all tiles they can move to
        * all enemies they can melee
        * all tiles where they'd suffer reactive fire or melee
        * all tiles they have LOS to and all enemies they could shoot (assuming they have a ranged attack)

* AI
    - the AI is pretty dreadful, even by game standards
    -  Goodies/Baddies AI can:
        * charge into melee with an enemy in range.
        * shoot an enemy within range and LoS.
        * if baddies, will prefer to attack goodies over picking on bystanders.
        * move aimlessly.
    - Bystanders AI can:
        * wander aimlessly.

[Franklin's Ghost]

Nice to see an update, was just wondering about this game yesterday, so great to see you're still working on it 

[Birdorf]

Turn-based, my favourite, I can't offer any input, but this looks great.

[Spooner]

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)?

[tcstyle]

Yeah! Radioactive Gorilla.
I like the look of the pixelart in this game. Curious how the mechanics will work ingame.

[Happy Shabby Games]

Oh man how did I miss this devlog? This is looking great Spooner! Following.

[Franklin's Ghost]

Hey Spooner just had a quick play and have to say it's coming along nicely. Got completely destroyed the first time I played, but second time I didn't lose as badly. Third time I won, so yay for progress and learning.

Noticed that if I moved a character and then selected another one while the first one was still moving, then the new character would say they had no moves until I re-clicked them. Also took me a few goes to realise that end turn skipped the rest of all my characters goes rather then just ending the current characters.

Really like the character looks and looking forward to seeing what you do next with it all  

Haven't had a chance to try the editor yet but will let you know when I get the chance.

[Spooner]

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).

[Franklin's Ghost]

Hey Spooner had another quick go and a few things I've noticed with the interface is that it doesn't let you know who you've selected in the character profiles when you click a character. Think some sort of highlight on the characters profile when you click on them would just make it a bit clearer. Also if for the round you've used a characters moves then maybe darkening their character profile would make it clearer to which ones you have left for the turn. Like how you have it when they die, the character is darkened so you know they're gone. Just have to do something slightly different then that.

Really enjoying the concept though and looking forward to playing against real enemy AI 

[Spooner]

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!