The Daily Click ::. Projects ::. Squad
 

Project: Squad
Project Started: 22nd September, 2011 Last Update: 17th December, 2011
Project Owner: Muz Project Members:
Project Type: Shooter management Project Progress:

Project Overview  
You're a teenager in Keriya, a city that has been pushed into near anarchy after a few years of constant warfare. The government spends all their money on warfare, leaving law enforcement with no budget. Crime rates are too high for anyone to make much of a living from businesses. With the collapse of the government, money has become worthless. Cigarettes have become the prime form of currency, as they can't be easily printed and are worth a lot in many countries.

Your family has fled to another country. You remain, taking the opportunity to gain power by exploiting the chaos and saving the city. But you cannot do this alone. To do this, you must rally support to your cause. You need to recruit troops and get weapons for them. Lead them, and take over this city.


Sounds like a typical RPG? Well, the difference is that you do nothing but create and level up characters. The game handles all the tactical combat stuff. The fun part is that you get to lay back and relax, while your guys do everything, and you just watch the fireworks.

You get to decide the men that make up your squad, their weapons choice, their training, their choice of missions and how they improve.

The game's also meant to be played in a sitting, from 5 mins to 2 hours. There's no saving and loading. It takes the feel of a roguelike, in that every game is made to be a little random and you'll have to go through a few hundred games to actually 'win'. Death and injuries are permanent, but it's just easy, unstressful, and fun to start over with an entirely different squad later.

Project Forums Topics Posts Last Post
Public Forum
Public forum for open project discussion
2 4 Combat System: Ke...
By: s-m-r
On: 12th Apr 12, 12/04/2012 12:22:43
Private Forum
Private forum for project members only
0 0 No Access

Rant
Posted 17th Dec 11, by Muz 2 Comments
Ok, long status update...

I've been having a lot of trouble working on this because I don't really have the facilities for it. I haven't mentioned it earlier as I wasn't sure, but I decided to code it in Construct 1.2, mostly as a learning lesson for myself on Construct.

So on the Construct vs MMF, I've learned a bit:
- MMF does global values better if you intend to use them for stuff.
- Construct sucks at functions as well. MMF has Lua, greatly improving function use. Well, Construct does have Python, but I don't speak Python, and don't really have the time to learn yet another language.
- Construct's sub-events are incredibly useful. This alone (along with easy special effects) is why I prefer Construct.
- Construct is just as buggy as MMF in a lot of things.
- Construct's sprite editor sucks as well. I end up going back to MMF for spriting, since it's just as good, if not better than most professional apps.
- No text blitter for Construct.
- Construct's expression editor is pleasant to use and the event editor is pleasant to read, even when you have a whole bunch of stuff. Also why you should split long formulas into several actions, for readability. I find MMF's really messy event list to be a major down point to making anything, though, again, that's fixed with Lua.

Other problems:
- I've had internet access for maybe only 3 weeks since Nov 1, and most of it has been really bad. Also losing Internet again in 2 days.
- I've also had a lot of trouble getting on a laptop; I've had literally only 3 weeks of access to my laptop, only 1 week of that with Construct, thanks to the frustrating Internet system.
- Only been home for one day since then.
- I've recently purchased Skyrim, so don't really feel like making games much D:
- My laptop charger burned out about 2 weeks ago, so can't actually do any coding.
- Starting a job in January. And getting starting on some other major non game project. Making games just doesn't pay any bills


So, yeah. Not looking good for this. Also tempted to just move it on to MMF, just to make the engine more moddable.
Coding a battle engine
Posted 27th Nov 11, by Muz 3 Comments
The battle engine will be 2.5D, which means that the characters will be somewhat side view, but be able to walk behind or in front of one another, even when overlapping. More importantly shots like bullets and rockets will go behind each other without overlapping.

It was initially a bit of a challenge to code, but one trick I found was to create sort of a XY base for the characters and objects in the game. Treat the base sort of like how you'd treat top-down code, which makes it simple 2D. Then add an extra Z (up-down) angle to it, and check whether the bullets go too high or too low.

Unlike the typical klik method, bullets won't be shot around and collision detected. It's quite possible to just collision detect, all I have to do is treat the shots like it's top-down, and check if that hits. If it does, check if the z-position is right for a hit to the head or feet or whatever. It's simple enough, but in my experience (and hearing about the experiences of many others), collision detection is buggy in MMF2. I'd rather spend an extra week working on the long route, than a few frustrating weeks debugging the collision detection, then giving up and passing down the frustration to the player.

So, simulation it is. The shots will be simulated by finding the angle and direction of the shot, and then adding a little inaccuracy to that angle. Then we trace where the bullet ends up. If the location of bullet is somwhere where there is already cover, then the bullet hits cover. If the bullet is aimed at someone's head, but the angle slides a bit and hits the arm instead, then it hits the arm. The more difficult problem seems to be checking whether a bullet hits cover, as there's too many bits of cover around.

There's a few approaches I've considered.
- The easiest method is just to scan through every bit of cover on the map and check if it hits anything. The problem here is that it's probably computationally intensive. You've got 6 sin/cos per bullet. With approx 40 parts of cover in a map, that's 240 per bullet... with 20 bullets flying around per second, 4800 sin/cos per second? It'll easily hit 10k+ with more bullets and a large map, with lots of units. It's not too bad with modern computers, still, it's a sloppy solution.
- A more classic approach, used by many games, is to determine sort of a cone of area where the bullet may go astray, and then choose something within this cone. It's not a bad approach at all, but I feel too much effort to code/debug.
- Another classic approach is to only examine the cover around the target, and check if it hits that (probably a higher chance of hitting cover the further away the shooter is). Then sort of draw a line from the shooter to the target, and tick and check everything along the way. I think games like Jagged Alliance use this system, so it's a decent enough one. The main problem here is trying to draw a line with MMF (without collision detection).

> My chosen approach was to set every location on the map as a 'tile'. At the start of the map, the game remembers which 'tiles' cover is in. Then, upon shooting a bullet, the game only checks the objects in tiles passed through. It's a little more work since I'd have to set up a tile-based system. But the advantage there is that I could just apply it to a tile based pathfinding system as well, since the obstacles will be mapped out too.
Alpha 1
Posted 18th Oct 11, by Muz Post A Comment
I've only got 10 mins for the whole month, so a very rushed update.

Basically, I've planned it through, but without computer access so I can't code it yet. The game will be released in a few different portions. I don't really like long confusing version names, so I'll call the initial release Alpha 1.

Alpha 1 will feature the core content of the game. You should be able to:
- Do the initial missions, and meet the first two factions.
- Build a simple squad, and level up.
- Most of the gameplay will be in it: choosing skills, skillsets, shooting, melee, cover.
- If I have the time to spare, the initial random terrain generator should be available, with a hotel, suburbs, and tenement maps.

There won't be any graphics in it, though, it's mostly to test out the core engine and as a show off to find someone willing to sprite artist for it.

Future alpha versions will have game balance improvements, more missions and factions, and better graphics.
Battle engine philosophy
Posted 30th Sep 11, by Muz 2 Comments
The idea behind battles in this game is that they should be short, but keep you at the edge of your seat. An average, inexperienced player who slowly improves would have:

15% chance of losing a level
35% chance of becoming stronger
30% chance of ending the level at the same strength, or only slightly stronger
20% chance of becoming weaker

The chance of losing seems a little low here, but it stacks up. Similar to a tough roguelike game, where you have a chance of getting killed on every new dungeon level, though this game will kill off some of your team members.

After about 100 tries of just pressing random buttons, you should win around once. Which should give an unskilled, dedicated newbie a win after about a week maybe. Not too worried if most people don't win... I mean, after all, how many people have ever won Nethack? Yet they enjoy chasing the win anyway.

The chances to win drastically rises for good players, who figure out which missions give a better advantage or which weapons/skills are better.


The approach I'll use to do this is realism. A vital shot will kill. Even a weak shot will injure badly. And over all things, cover will very important.

Pistols will be an actual deadly weapon. Automatic weapons will be more likely to do harm, but also be useful in suppression. Snipers will be slower, but can possibly instakill. AP weapons will punch through many forms of covers but hurt less, rocket launchers and grenades even more so.

Your troops will make use of this cover and try to outflank the enemy or flee when under indirect fire.


A skilled character will have higher skills, meaning that they can utilize cover more effectively, be more likely to shoot first when leaving cover (and first to hit), shoot more accurately, throw grenades back, etc. This would increase their chances of winning most missions.


The battle engine itself will likely be 2.5D, that is, Golden Axe kind of side view, where they move up and down on the screen to indicate moving left and right.

Most of the shootouts would occur in a single frame. Yeah, it's partly because of technical reasons, but also because the player should be able to see the fights clearly. A sliding frame brings up the issue of trying to have the 'camera' zoom in to the interesting parts, which would be hard to determine. The big missions might have multiple frames of action, or reinforcements trickling in to the fighting area as the heroes pick them off while they come.


Anyway, I'm taking a long vacation from computers soon, so, this might be my last entry, though I'll try to toss one tomorrow if possible.

View Project Archive


 



Project Forums


Favourite

Advertisement

Worth A Click