Archive | Real-time Strategy RSS feed for this section

Capstone updates 3-5

4 Apr

So, I didn’t update this devlog as much as I intended to, but better late than never.

Day/Night is now established as a force in the world. Plants, predators, and players are now all affected by whether or not they are in “Day” or “Night”. Plants bloom quicker in daylight, queens and their pawns move slower at night, and predators come out at night.
One of my goals with this system is to force players into action and have them fight for territory that’s getting more sun, and therefore growing food more quickly.

In relation to the day/night cycle and the plant blooming cycle, I added the ability for players to force plants into bloom by clicking on them. When this is done at night, the plant becomes more stressed; when this is done during the day, the plant becomes less stressed. And as the plant becomes more stressed, it takes longer and longer to bloom.
My goal here is for players to learn how to “farm”. Part of the trick is that plants gain stress faster than they lose it when farmed, but if left alone for a while they naturally come back down. I see this as part of learning to dwell within the world. I also see it as a way to increase engagement, by making the game more “clicky”. In particular, I’m reminded of falling suns in Plants Vs Zombies.

I’ve also settled on the visual motif for this game. I’ve decided I want a very geometric look, so the queens are ovals, the pawns are triangles, predators are rotating octagons that live inside deccagons, and plants are squares that fold out when in bloom. I’m not gonna lie, a big incentive to go this route is simply how much easier it is for me to do.

Because this game is based on emergence in mechanics, it seemed natural to work towards random level generation. So far, even with few constraints in place, levels are coming out interesting. I’m gonna keep refining this aspect for probably longer than I need, or until it stops being fun.

I would really like to make the game multiplayer as soon as possible, but due to constraints on my time and the limited amount of time left in the semester, I will most likely wait until May to begin in earnest on that.

Gather and Harvest

30 Jul

I sorta became bored with Gather, and broke it in to two parts. My thoughts on it were taking me further into simulating things, which is mildly interesting to see the result of, but not much to play. My decision is to go one step further with ripping off paying homage to SimAnt, and include a player avatar that imitates one of the worker roles. This will allow players to lead some units into direct conflict by rounding up a posse. There might be some other homages to the Maxis classic coming.

So, that’s where Gather might go if I actually do work on it again. Separate from that, I think I want to do another game that’s closer to a traditional RTS that uses some of the concepts that I came up with for Gather This came about because a lot of what I was doing in Gather was based on RTS principles, but at the same time I wanted to have a very simple control scheme (in the end I was aiming for too simple). So, my thought now is to just embrace the traditional mouse and keyboard ‘drag and select’ style RTS controls. Therefore, direct control over all units.

Harvest will be more about developing fields of different resources located around strategic waterholes, these resources can confer different attributes to units which will ultimately help you topple your enemy. The resources are farmed until maturity and vulnerable until then. The game is about controlling as much of the map as possible and using the mixture of attributes to boost troops as necessary.

We’ll see which one gets worked on.

Strategy Basics

9 Jun

I’ve managed put together some very basic aspects of Control Room already. So far, there’s

line-of-sight cones that draw around objects

turrets look within a limited angle.

doors that can be oriented(edit: kinda)

Guards have pathfinding and can return to their regular patrol after chasing an enemy

Players can create a selection box with the mouse to select multiple guards, and can order them around.

I’ve never been able to do any of those things before, so I’m pretty happy. I’ll go ahead and give out proper credit too: An excellent Vision Cone example, and an RTS example. I haven’t used the RTS example much yet, except for unit selection.

If I knew how, I would post something playable. Until then, here’s the Game Maker Studio project file.

Bigger sprites equals better game

31 May

Gather – WASD to move the camera around, the two big buttons in the top left build bots.

I’ve been working on getting the bots to “talk” to each other more; so that 1 bot can tell another where he found some ore, for example. And attack bots now try to pursue enemies carrying dead bots. the added base component, the “stomach”, is just a cosmetic change to show available Ore reserves. And of course, I expanded the size of some sprites because they were tiny.

 

Looking Ahead…

15 May

This summer I plan on getting a head start for next semester’s Game Production Lab. I’ve been assigned to the game “Control Room”, which is a 2D, top-down, strategy and puzzle game about leading a group of operatives into a Secret Facility where you also happen to be a control room operator. So, you’re a double agent working to take down the facility while avoiding suspicion. I, for one, am ecstatic that we got a 2d strategy game to work on; as I am all about that shit.

Even better, is that Control Room will be made in Game Maker, which I have at least some experience in. Granted, I lost literally every project I ever worked on in GameMaker a few months ago, but I was gonna have to relearn certain aspects of it anyway. While I do have some serious gripes about GameMaker’s pricing structure, like why it costs $400 to add HTML5, Android, and iOS exporters, the program itself can be quite powerful.

And more importantly, it will be Game Development Done Right. I cannot stress enough how important it is to iterate on a game before you’ve even landed on what exactly it’s about. Next semester has the benefit of three whole months of prototyping beforehand, which I’ve already kinda sorta started.

Last semester, zero iteration, terrible development. Without getting too much into it, my experience in Game Lab last semester was mostly me trying to learn a whole new game engine and language while working on an untested game design. It was no fun, it really soured me on working with large groups that don’t communicate (or any size group that doesn’t communicate for that matter), and  and it really drilled in the importance of pre-production and prototyping.

 

Anyways, I anticipate Control Room will be a very fun game to work on. I’ll try to post about progress if it’s significant and playable.

Attack and Gather with Buttons, Oh My!

10 May

The updated game. – This version should work better on mobile. UPDATE: So, when I run this project in my editor, everything works fine. Exported, the game has some baffling bugs. As far as I can tell, this is because I’m on the Construct 2 beta update channel. And if there’s one thing that can be said about Scirra, it’s that they do frequent and often bug-causing updates.

On the surface, all that’s new is the interface and the inclusion of Attack Bots. Of course, in the background there was more, but it was mostly stupid bug fixing. This time around, Gather Bots care less about finding Dead Bots, and their behavior has changed so that they “swarm” less one object. Attack Bots search for Dead Bots to bring back, and, if they see another team trying to take a Dead Bot, they attack.

One of the things I had to change a while back was the Turret system used by my bots. The Construct 2 behavior plugin, “Turret Behavior”, had some real limitations as far as determining whether an object was a suitable target. So, I just use events to control which objects are targeted. I’m getting close to the point where I must just try and write my own Plugin. If nothing else, it’s good motivation to learn Javascript.

A Gather update?

29 Apr

In my last post about gather I mentioned that it might still be interesting to focus on the “ant farm” aspect of what I had built, and ignore the science subtext I was trying to force in. So, I decided to pluck away, and this is the result:

Gather – Click on the big Yellow and Pink boxes to spawn bots of those respective colors. I left all the log info commands in, so clicking on things will give object variable info.

Why pursue this?: While I think I’m using a lot of the same mechanics, my end goal is much simpler. I still like the “AI voyeurism” in watching two sets of the same instructions battle it out for supremacy. It’s also helpful for me to keep sharpening my RTS programming skills.

Where am I going with it?: The scary part is, not many of the actual systems are going to change, but the emphasis I placed on different parts has changed. Before I was worried more about the different base”nodes” talking to each other and sending “signals” with different transmitters, with bots being tools of the base. Now it’s more traditional, with the idea being that the production of bots is the purpose of the base and ore.  Resource bots still look for ore, Attack bots are going to attack enemies, and Road bots are going to connect the different nodes up. The only real change for the bots is that Resource and Attack bots are now concerned with picking up “un-energized” bots and bringing them back to base for recharging, thereby keeping up the team numbers at a lower cost.

The next thing I want to implement is the Attack bots. Their role will be to actively look for un-energized bots and to destroy enemy bots that are carrying un-energized bots.  These will take a different resource for production, so I’ll also put in the different colored Combiners.

An update.

9 Mar

I decided to do some follow up posts for my Neural/AI RTS thing.

Construct 2′s Pathfinding behavior is giving me some problems. I want to create automatically create paths on-screen between two objects to send units back and forth them. Right now, the units will usually take one path to get to an object and another path to go back. I’ve experimented with adjusting the “cost” of taking different paths so that units will prefer the first route, but that breaks the game when it works.

On a similar note, I would like to see expanded capability of pathfinding by having access to the pathfinding nodes directly as objects. They just added the ability to reference the node the object is heading towards by it’s array index, and you can access the (X,Y) coordinates of a node by index already.

Construct 2′s path finding behavior is still fairly new and they’re still evolving it and fixing it.

On more of the design side of things, I was planning to have units be ordered by instructions linked to a particular resource type. Orders could build up in complexity, and basically it becomes similar to programming. Different order configurations could be saved as physical “macros” in the game world. The goal would actually be to represent muscle movement patterns stored in our brain. I’m worried that while this may be a novel way of doing things, it may not be very fun. It’s certainly not practical.

I’ll post the prototype for posterity’s sake, but there’s a lot of shit going on that I don’t feel like explaining.

http://dl.dropbox.com/u/11289993/Gather2/index.html

Gathering AI

21 Feb

Construct has added a bunch of interesting features since I last used it, so I figured I might as well prototype some ideas that needed to be worked out. I should probably just write something down that summarizes my musings on games inspired by neuroscience, but for now I have this, Gather AI.

Right now, “bots” automatically gather red ore and return it to base. After 4 red ore are collected, a new red ore bot will spawn. The player can click and hold on the base to make the red bots move towards the base, when they arrive they will “sacrifice” themselves. Once 4 red bots are sacrificed, a “green” bot appears.

The idea is to create an RTS style game, where players control AI units indirectly through commands. Even the clicking in this prototype is more direct than I intend to get. Essentially, your base will run itself based on set parameters.

One of the main features I wanted to try out was PathFinding, but I it was giving me some problem. Ironically, all of the work in this prototype is done with the turret behavior, which is still new but I’ve pretty much created the same functionality out of code before. But still, Turret behavior is a nice package and I’m looking forward to working with PathFinding.

I also like that they’ve incorporated most of RexRainbow’s “Function” extension into Construct 2.

Follow

Get every new post delivered to your Inbox.

Join 81 other followers