next »

[Triplefox]

Newest build, same time same place:

• 3-frame character animations(crits welcome)
• A bit of rendering optimization while doing the anim code
• "Real" save and load(only one slot for now)
• Tabbed controls
• Some behind-the-scenes stuff to get all of these features going

The old save/load test is still there by pressing ctrl+\

Goal for next release: Inventory + items

Once I have that working, tons of stuff for gameplay will open up.

[Chris Pavia]

Those creeps sure move fast!

[Triplefox]

Yeah, I haven't really done anything to tune combat or movement yet. I'm actually going to throw away the AI they use now and let the player decide when they invade so that it's possible to enjoy preparing, fighting, and defeating them. But final combat AI + tuning will probably wait until I have some equippable items and stats in place.

But since you mentioned it, I put up another build with slower and weaker creeps, so you don't have to be scared about wandering around

[Triplefox]

Another new build...

• Building costs resources now, clearing collects them
• Drag and drop (DragonDrop) inventory and equipment - equipment is non-functional right now...sorry...but it's fun to collect!
• Items are randomly generated when terrain is cleared (5% chance)
• Some backend stuff to improve future moddability
• I improved my build system, which means I can incorporate foreign APIs better now. Analytics are properly integrated in the swf now, instead of the hack JS thingy I was using before.

Next thing to work on, I think, is the village economy, specifically building defenses. Once I have some defenses to build and play with, I can do another pass on the combat and invasion AI.

In the process I'm also going to expose more stuff to build - more wall types, maybe more floor types if I'm ambitious, so there will be some changes rippling up and down the interface and backend there.

[Triplefox]

• Prisoners can be rescued by standing next to them(prioritized this since I was asked)
• Walls have "real art" now - may do another pass on it though
• Prisoners animate
• New build menu - this one is going to be "web scale"

[Triplefox]

It's here! The creeps can invade!

• Windows(that don't work yet, and will need another pass on the art)
• Four types of defenders now: Guards, archers, dwarves, and wizards. They don't behave differently at all yet. Each has its own marker type.
• New tab for "war," it's the little sword.
• Next Wave button under the war tab - press this and the creeps will plan and execute an invasion. While fighting the battle you will be unable to build.

It took me quite a while to get over the "Next Wave" hump but now that it's here, I can start thinking more about the content, balancing, and all that fun stuff


Edit: There's a bug with the invasions where the creeps will just restart their path too early, floating back to their starting position. Will fix sometime next week.
Edit 2: Figured it out, I think. Should be fixed now. Also tuned the pathing behavior a little.

[JobLeonard]

Not enough people are posting encouraging words.

Keep it up dude!

[Triplefox]

Thanks.

Today's update:

• Hp change numbers are shown as a "particle effect."
• Hp is recovered slowly over time.
• Targeting tries for the lowest distance instead of "anything I see."
• Projectiles go through windows
• Nice-looking windows
• JSON-based tuning data(not really tuned yet)
• Refactored pathfinding and AI behaviors...
• Creep invasion behavior is much better now.
• Movement is slightly smoother.

[Triplefox]

Today

• New projectile sprites
• Colored hp change text
• Line of sight is checked when targeting
• The different guard types have unique weapons. Not well balanced yet...the dwarf will destroy everything
• Range affects damage - "melee" weapons will do more damage at the edge of their range(more leverage) while "ranged" weapons do less. The archer tends to get 0 damage easily right now...
• Flag animates
• The last creep in a wave drops a key. In the future this will "unlock" nests and make them visible, where right now you can just march up to any nest and kill it easily.
• Tuned the creep path-cost heuristic a bit.

[Triplefox]

Small update. Ace of Spades has drastically slowed me down the last few days, and sent me into a fit of doubt over whether the game is "good enough."

• Nests are not visible until you unlock them with the key.
• Collecting the key shows a compass pointing you towards the nest.
• Next wave only re-enables after you've destroyed the nest.
• A bit more tuning and balancing.

[aekeren]

Wow, this truly looks great!  The procedurally generated worlds are beautiful.  I had a lot of fun building up a fortress and exploring.  So quick on the updates too, you blow my work ethic out of the water!   

What is the gameplay going toward?  You said casual, is this going to be a 10-minute coffee break type of casual, a Facebook type of casual, or casual in that it's a more approachable DF type game? 

Here are few bugs I noticed.
Moving on to a character from the bottom or left has a different response than moving from the top or right, nothing terrible just a visual inconsistency.  Building a wall while workers are clearing an area can cause them to get hung up on the wall and not find a new path.

Best of luck finding the fun!

[Triplefox]

Thanks for the feedback, and the bug reports. I actually haven't resolved a lot of the design questions yet - I know in abstract that the game will be "build, defend, and explore" and that's gotten me this far, but the phrase "devil is in the details" is very applicable to the problems I'm facing now and it's bringing me down fast.

At this point I'm starting to question some of the things I've already built, like the pace of the combat and the depth of control given to the player. I'm not even 100% sure about the goals and objectives of the game - whether the endgame is about "building" or "exterminating," and how much sandbox play I want to include. It's unclear how long it will take to resolve all of this, and iterating just by coding and testing is going to be really really slow and grueling just by myself, so I decided yesterday to take a break from this project, do some simpler ~1-2 week games and prototypes with unrelated themes, and return to it later with new ideas.

[Chris Pavia]

 I'm not even 100% sure about the goals and objectives of the game - whether the endgame is about "building" or "exterminating," and how much sandbox play I want to include.

This seems like something you should decide and expand upon ASAP. For me, it's pretty obvious when a game I'm playing didn't have much vision or intent behind it, and ends up feeling pretty sterile. There are exceptions, of course. There's a time for experimentation and discovery, but eventually you should decide what the pillars of your game are going to be so everything else can be stripped away (IMO). Maybe Magnate is still in the former phase, but I think it's beneficial to realize the distinction between the two.

[Triplefox]

Well, what I've done - on this one and on a lot of my previous games - is kind of a technical exercise, both in the coding and design. I haven't had much pressure to ship as an indie, so I'm doing a lot of boundary-pushing. This is turning into a kind of a reflective post, which is good, since I need to write about it too.

In this case the thought was: build up the core features for a really big, simulation-driven game, that could also be made accessible. The game itself could change, the core idea was just to try having a lot of things going on and see what I could make out of them, which in part was driven by the idea that a big, simulation-driven game is usually a good, playable game too. The only instances I can think of this kind of game actually failing to be fun for some audience are where the developers shipped the game before the design was ready or things were polished - e.g. the numerous games shipped as buggy messes with non-working features: Darklands, Outpost, or Battlecruiser 3000, to name some famous fails from the 90s. Dwarf Fortress only fails to be fun for people because it's ignored accessibility - it's just a few steps above playing a game in a debugger. In any other respect it's a massive hit. Spore is a good example of the worst case if the game is polished and most things work as advertised; the result ended up being a kind of minigame collection, but most people were able to find a few hours of fun in it, even though it did not come together in a cohesive, focused way.

And after six months, like those half-finished games, Magnate is sort of playable, and even sort of fun, in a few spots, but it's obvious how much work is still left - an amount that - if I'm going to make the best game out of this - is in the man-year range, because it's the kind of game that responds well to feature accumulation. It's clear that things will have to get cut to make Magnate work, but even more things will have to get added, too. And that's the problem with making the game big.

So I've let myself keep the design very loose and tied to the abstract, because all this time, the technical challenges have been the top thing on my mind. And in trying for that I've found out that having this kind of design doesn't give me the leverage I thought it would. It's code, it's simulation, things are procedural and such, but it's code that is built like content, and thus - unlike the engine bits - it's not once-and-done, and the iteration times are huge when dealing with code, so it takes a really long time to get it right across the entire game. It could be another six months before I have it firmly steered in the "fun" direction.

So I see myself doing one of these things for future work on Magnate:

• Work on it gradually in between other projects, so that I can iterate on the "big game," however long it takes.
• Strip it down, and make multiple games with different focuses.
• Get a budget and a team to work on it. Within a team, many more ideas are formed than can be implemented, so design becomes more of a filtering process. Development also bottlenecks less, up to a certain team size - 5 or so would be fine.

I'm more interested in game-business experiments than game-design ones right now, so this is the right time for a break. Right now I'm starting on a little minigolf game with a map editor. I'll have a playable build done sometime tomorrow or the next day, and I'll have a first-pass, ready-to-sell product in 1-3 weeks. So I will change gears and be able to see progress in product-to-product iteration in future months, instead of feature-to-feature iteration. Then we'll see where I'm at.

[JobLeonard]

 

Spore is a good example of the worst case if the game is polished and most things work as advertised; the result ended up being a kind of minigame collection, but most people were able to find a few hours of fun in it, even though it did not come together in a cohesive, focused way.

And after six months, like those half-finished games, Magnate is sort of playable, and even sort of fun, in a few spots, but it's obvious how much work is still left - an amount that - if I'm going to make the best game out of this - is in the man-year range, because it's the kind of game that responds well to feature accumulation. It's clear that things will have to get cut to make Magnate work, but even more things will have to get added, too. And that's the problem with making the game big.

It kind of feels like the conclusion in the latter paragraph ignores the proof from the previous paragraph that that line of thinking can go horribly wrong.

The game isn't missing features, it's missing purpose, whether that is imposed or emergent.

[Triplefox]

No, there's no contradiction. I do have a vision, but to find focus I just need to iterate, because it's clear that I'm not going to be able to nail elements on the first try as I can when I do tiny designs. I'm not so ignorant as to literally throw things into the game at random, but these are the first pass efforts, and that is what is making them unfocused. So I plan to build them again in a different way, and only cut them if I can't make them work after a few tries.

If I deliberately cut enough features to make the iteration times faster, it would become a much different game, and not the one I wanted to make. There are smaller games hiding inside Magnate, but I'm not interested in them. Those are the games I would only make if I were under time and budget pressure. I brought up Spore precisely because that is the problem that comes to mind; the original design there was extremely ambitious and instead of trying to iterate it until it worked as intended, it got cut down into a much smaller and simpler design, which had the side effect of making the whole thing less focused.