Posts Tagged ‘strategy’
So couple hours into the jam the core gameplay works. The player can place, remove and edit grid trigger plates. The runner behaves accordingly with game-over and win states working. If you feel like giving it a try there is a webplayer here: http://www.the2ndsky.ch/LD28/
The goal is to build a path to the target block by using various trigger plates that change the path of the runner. Once you click play you have no more influence into the game, hence the theme “you only get one”. What do you guys think?
I’ll now work on camera function, two more trigger plates and then I’ll decide upon an art-style as well as a setting. Followed by modelling and finding the right sound effects. Watch it all go down in history: http://www.twitch.tv/polyganz
So after spending an extensive amount of time in the shower and crying like a little boy over the theme “you only get one” I’ve finally come up with the following idea:
Grid runner is an isometric strategic puzzle game.
The goal is to get a runner into the target zone in one run by adjusting his path through various grid plates that can be placed in his way.
The player has a limited amount of grid plates available to solve each level.
So in a way its like a problem solving game where the player defines a set of actions that get executed in an order with the hope of a profitable result. In this case: of the runner getting into the target zone. What do you guys think?
I’ve yet to find a proper setting for this type of game so I’ll work on the functionality for now. I’ll mostly be using Unity3D pro, 3Ds Max and Photoshop. If you’re curious like George then you can also watch it all go down in flames (or not) on my stream that I intend to keep open for the whole LD: http://www.twitch.tv/polyganz
I’m in for this October Challenge. The game I’m currently working on is Mutant Gangland, a Turn Based Strategy game set in a floating wasteland in which Mutants and Exo Mutants fight for control of the island. I keep a devlog on Devsofa and I will most likely share allot of stuff in the upcoming days.
Here’s a fresh vid:
Best of luck to everyone!
Well, the fact that I got this far must signify something.
This is my first Ludum Dare (the first for my partner too) and I’m pretty happy with the results. At 4:00 P.M on Sunday I was pretty sure this was going to be an absolute flop – but somehow it actually worked itself out. So without further ado, I’ll introduce the game concept and a few other details.
Game concept: It was heavily inspired by Chronotron, a game where players can go back in time and solve puzzles by making their former selves do part of the work. I played Chronotron a while back and didn’t really think much of it at first. But then… I realized there might just be something to this game that could be applied elsewhere. As in, the concept of time travel. Before Chronotron, I’d never really heard of a game which used time travel as a gameplay element. Turns out there are a few, but most of them don’t implement it like Chronotron.
So we decided to give time travel a second chance and incorporate it into a turn-based semi-strategy game. You would have as much time as you wanted to think about your actions, and then you would execute them. I even had ideas for a kind of time-travel portal device (past portal and future portal).
And the name of the game: Timing is Everything
What went well:
- During the early part of game development, I was just churning out code. My partner was drawing pretty well (I’m have the artistic skills of a planarian) and a lot of the early code was working flawlessly on the first test.
- The art style was definitely influenced by games like Geometry Wars and Pew-Pew. One would think that it would have no place in such a strategic game. But it actually fit in quite nicely.
- Some levels were quite creative. My partner designed all of them (although I did help out). The ideas of paradox avoidance shows up in the later levels and was well executed.
- Libgdx proved to be pretty easy to use as well as cross-platform.
What didn’t go so well:
- Time travel was a real pain to deal with. To make it easier on ourselves, we had started with a goal of making ANY game entity capable of traveling through time (just in case that time-portal device ended up being used). When I actually got to coding the player’s interactions with the time machine I hit problems. Originally, we wanted the player to be able to specify how far back in time they wanted to travel. This ended up creating a lot of annoying bugs and glitches, and the little framework which I had written didn’t suffice. So, we ended up ditching a huge chunk of code and going back to doing things Chrontron style – you can only go back to second 0. And after a lot of modification, we got that to work. The other problem was being able to use the time machine more than once. And the idea that when former selves went into the time machine, they had to DISAPPEAR but still get reverted later on. One of my ideas that never ended up completely working was that former selves could be linked to their future selves via some kind of linked list starting at the current player. In the end, annoying bugs and glitches made a game with more than two instances of the player impossible, and we ended up compromising and only allowing the players to use the time machine twice. If we had thought through the implications of time-travel ahead of time, we could have made a far simpler and more efficient framework which would have been able to handle that.
- Some of the early levels were a bit too hard. Level 2 should have been level 8. And level 10 was too easy (at first). Some levels were designed with only 1 solution… so if you made one wrong move or if you forgot to sprint, you would inevitably fail.
- The code eventually disintegrated into an absolute mess in the later hours. Best to look at the actual code if you want to see what an “absolute mess” looks like. Some code was unused.
- Real life got in the way. This is probably the busiest time of the year for me, and to shove everything to the side for the Dare was not easy. In reality, we only put about 20 hours of work into this entry in the 72 hours we had to make it.
- Porting issues. While they say “Port later” in the guide, be careful. If you want to make a web game, prototype on your browser frequently. I didn’t and I had an 1 hr and 45 mins to figure out Libgdx’s GWT port. And it didn’t work, so sometime this week when I have time, I’ll have to make a web port.
Anyways, if you haven’t yet played it, try it out here.
Except the sketches in my notebook on screen I have only a 10 seconds counter lol !
Anyways I decided to go for a primitive strategy/simulation with 10 second battles. The gameplay will be tactical with crucial placement of army stacks (doh). During the battle time however player will have to wait and hope for his army to accomplish the goal. This will be my first time creating a strategy with lots of units and I’ll try to escape from the tower defence reeking around the idea.
Next comes the Engine…
Progress will be kept here: http://www.foumartgames.com/dev/ld/2013-Inherity/
So basically it’s a rip off of Z, from The Bitmap Brothers (1996), but on rails.
You “control” an army of robots that are too stupid to be controlled directly. So you have a set of waypoints when you give them direction orders. You win when you reach the enemy fort waypoint.
That’s pretty much it. It’s ugly but functional.
Source code is there, on github.
Cya late august for the next LD !
EGGZ is a real-time strategy game with eggz in it – click on the EGGZ for a sweet 48-hour
As mentioned in my last post Eggz was essentially finished in 48 hours, though they’ve been a couple of bug-fixes and enhancements since then. I’ve also been very lazy about building a version for distribution, but I’ve finally gotten around to it:
Unfortunately the game has no AI, so if you don’t have a friend to play with you’re not going to get much out of the game
I’ve drawn up a quick state-machine that should play the game adequately but it’s not going to be in the 7dRTS version I’m afraid. Check the game page for any post compo improvements
Looking forward to playing your games guys, I really love RTSs – let’s revive this genre
Good new everyone
EGGZ is a real-time strategy game with eggz in it…
I was really happy to hear that there’s a 7 Day RTS, because I really love RTS game – it’s a pity more indies don’t make them!
Anyhow, we held this friendly multiplayer oriented game jam called the “Funky Future” last weekend, so I decided to make a single-screen competitive RTS controlled with the keyboard (or a gamepad) and with no elimination. The game was basically finished last weekend, but I’ve been tweaking it and doing bugfixes since then.
Well, I was really not wishing for minimalistic to be voted as a theme for this Ludumdare but, well, C’est la vie. The way I see it, I can take one of the following routes:
- Minimal Graphics: Monochrome or simple geometric figures
- Minimal Gameplay: small set of goals and interaction options
- Have a character named “Malistic, Mini Malistic”
I decided to go with option number two and design a small “strategy game” with little to no interaction during game play. The basic idea is this: The player has a certain number of points at his disposal. By spending those points he can buy and deploy troops on the battlefield at the start of the game: Infantry, Rocketers, Tanks and Anti-infantry Vehicles. He must assess the situation and, based on the amount of points as his disposal, choose the best possible line-up. After he places his units and clicks start they will proceed to search for the enemy on the map. At this point, the player will only be able to mark certain locations as important (and thus, a few units nearby will go towards that location) or drop Health Packs (to aid his units). Here’s a screenshot featuring the current progress:
That’s about it for now. I’m actually curious to where I can take this game.
My entry for MiniLD 39 has been posted http://www.ludumdare.com/compo/minild-39/?action=preview&uid=15656 The hindsight for this entry was what would I have done had a school shooting right before LD#25 had not happened and I went with my original idea for that theme instead of a non-violent game.
Well, yesterday I decided to do post-mortem work on my immune system game RTS game.
Currently, I have only one campaign level – but I did a lot of refactoring in the game logic code.
Let me know what you think about it, any hints appreciated
The first campaign level shows you how to use the immune team and the supporting leucocytes, so it’s more kind of a tutorial:
The concept of the game:
You can either play the virus team or the immune system team. You (currently) have two Computer players taking part in the game. One is neutral and controlled passively by the Immune System. This neutral Computer is the one that controls the leucocytes that are controlled by the interleucines (produced by the immune’s globulines) and will attack the cells that are under control by the virus team. The viruses team advantage is that their spawn rate is higher than the spawn rate of the immune system and that they are much stronger than globulines (but weaker than leucocytes).
The immune system player is the one that is defensive, but he can also attack with “Blitzkrieg” strategy and making the virus team busy whilst using his leucocytes bonus.
The virus player is the one that is aggressive, he is the one that has to infect as much cells as possible. The more time he has, the stronger he gets and the harder it is for the counterpart to eliminate the virus player.
Taking further the concept:
What I wanted to achieve is a more realistic RTS game that is balanced and has a tech tree with different units. So, for example, the cell will have different “buildings” inside:
The nucleolus: This is the one that is producing the DNA, splitting and results in “more units” if upgraded
The cytoplasma: This is the part that is the shield of the nucleolus, it will upgrade the health of the cell so that it can take more damage until being captured.
The ribosomes: The research building. Use it to research DNA upgrades (mutations) for your team. For example, this is the place to equip leucocytes with better amino acids; the place to get T-killer or -helper cells as reinforcements. The counterpart (virus team) can research their own upgrades here. For example a by-strength upgrading until you reach Ebola.
(Doomsday) Super weapons:
The immune system team can have fever as a super weapon. It is limited by time (e.g. every 3 minutes) and has the capabilty of completely killing all cells at the game board (excluding the viruses that are currently produced inside the cells). It will also neutralize the immune’s captured cells and remove the leucocytes on the gameboard.
The virus team has the super weapon of upgrading to the T-virus (haha, resident evil and zombies! :D) which is therefore able to attack t-helper cells (like HIV) AND to attack t-killer cells, which are the ones that can completely destroy cells like a “bomber” in a classic RTS game.
Let me know what you think about this concept… and if you have suggestions: They are very appreciated!
One of the only things I voted a -1 for. Oh, well!
I think that I do have an idea that will work for it.
Thoughts on “Tiny World”
- The world starts as tiny.
- The world can grow, but should optimally be small.
- Size of “World” can be based on perception.
So, my idea is a semi-strategy game based on a mixture of these.
Tiny World- A War of Ideal
In the void there is an idea, one that to grow will need souls to believe in it. For souls to exist they must have a place to live. So an idea begets a world. Souls will come to world, will believe in the idea. But the power of an idea is limited and ideas have trouble coexisting in the same world.
I’ve been anxiously awaiting the October Challenge this year. I wanted to join in on the fun last year, but I was way too busy back then. But I’m hoping nothing is getting in the way this year. Also, as of today I’m a full-time indie developer.
Before I get into what my game is all about, here is some back-story: I’ve grown up with strategy and simulation games like Sim City, Caesar or The Settlers and they have been and still are my favorite game genre. What I want to create is a peaceful strategy game which is not too complex for newbies, but not too simple for veterans. I had several prototypes in mind with different gameplay mechanics and what I settled on was a scenario in where the player has to build a settlement on sky islands.
Interestingly enough, I came up with the original sky island idea for LD #20 and after playing around with the idea for a bit, I decided to create a small prototype while I was at BIGJAM in Berlin. While I was not as productive as I hoped to be, I got the basics done and decided to stick with the prototype. All in all, I worked about three weeks on this game so far. If you want to know what happened so far development-wise, click here to be redirected to the development blog.
If you liked the screenshot, I uploaded a very short gameplay video to Youtube last month if are interested in how the game looks like in motion. I also want to mention that I’m not working alone on this: Christian Storcks is doing the music (a short preview of that is in the video I linked in the last sentence) and Jesse, a friend of mine, is helping me with some coding, in particular scripting and some backend stuff.
The game is going to be released for Windows, Linux and Mac OS X. I am planning on starting pre-orders by October 21st and I hope someone will buy the game.
UPDATE: Now with (spoilerific) screenshots after the break.
Since several people seemed to find The Triumph of Time pretty hard, I decided to give some pointers as to how to best play the game.
Let me describe the core mechanics of the game. As soon as you have built a pylon next to a star, it will extract particles from it at a fixed rate. The larger the star is, the more particles are extracted per time unit. Building several pylons next to a star will not increase this rate, the particles will just be randomly distributed over all pylons. The particles will then go on to more or less randomly distribute themselves along all barriers which extend from their current pylon.
At a fixed time interval (every two seconds, if I recall correctly), the cloud of antimatter will expand in every direction. It can only be blocked by having a barrier which is powered by particles in its way. However, for every grid cell along the barrier which the cloud tries to enter, one particle on this barrier will be destroyed; when all particles are destroyed, the barrier falls.
So here are some rules of thumb for successful play:
- Try to tap each star at your disposal as early as possible, especially the large ones.
- Try not to lose any stars to the cloud as that will severely cut your particle budget.
- Do not build any superfluous barriers within your territory. Every particle that swirls around on a barrier which is not at the frontier does not contribute to your defenses and is essentially useless. So, try to keep the paths which transport particles to the frontier as efficient and short as possible.
- Keep the frontier as small as possible. Every frontier tile (i.e., a cell on a barrier which delimits your territory from the cloud) will cost you a particle every two seconds, so minimize your surface. PRO TIP: It’s well known that the shape with the smallest ratio of circumference to area is a circle. It may help to keep your territory roughly circular.
- I’ve found that once a critical barrier has fallen, it’s often very difficult to recover. It’s better to stake out your territory on the conservative side rather than lose it all.
I hope this helps a bit. After the break (SPOILERS): screenshots on how to solve the first four levels.