FreeGameDev Planet - Games

Also check out the development planet.

April 15, 2014


Some things coming in the next release

We’ve been hard at work on the upcoming version 4 of Frogatto, which is what we intend to release on Steam. We’ve got a few things which are variously in the works, or mostly complete:

- One of the big goals in this release is to get a professional level of polish on our bosses. We’re trying to stamp out as many of the “trivial exploits” you can use to ‘cheap out’ a boss and take it down much more easily than intended. We want the bosses to fairly telegraph their moves (no random, sudden motions that aren’t predictable), but we also want the bosses to be very, very challenging. This is a really difficult balance to achieve, and it’s very time-consuming work, which is why we’ve neglected it in previous releases in favor of building out other content. There’s a reason many traditional 16-bit games had a few employees dedicated solely to writing the bosses for a given game.

- Related to this, we’ve added two new act bosses (on the same scale as Milgram) in the forest section. I’m not going to spoil them in this post, other than to say that I’m quite proud of what I’ve done.

- Frogatto now has two different paths to take through the forest. Each route route features new enemies, and also has some new and unusual platforming puzzles in it, very different from the rest of the game.

- The forest now has a town in it, called Tempo Village. You should visit it sometime, I hear it’s nice there this time of year.

- We’re trying to make monster encounters more interesting. Right now, if the player is intent on just progressing forward in the game, a lot of our monsters really aren’t very interesting. They’re similar to designs in many other games, but because Frogatto (the character) is incredibly agile and fast compared to most platforming characters, Frogatto can get past these by just jumping over them (unlike, say, Simon Belmont). It’s frustrating; we’re committed to having a really fluid, agile character, because the stiffness of many traditional game characters has always been something that bugged us. We also want to do this because we feel like it’s an obvious point-of-improvement that’s unfairly neglected; a cop-out a lot of existing games make, and an obvious point for us to innovate on – but the reason it isn’t done is exactly what vexes us: if we want to have a really agile character, we have to work much harder to make sufficiently interesting enemies. We can’t just make a goomba clone (which a surprising number of castlevania enemies were), and call it a day.

I describe “sufficiently interesting” as an enemy that arrests the player’s forward progress, and forces the player to confront the monster and either dispatch it or carefully dodge it before proceeding – something that demands the player’s attention. The guiding principle here is a classic quote by legendary game designer Sid Meier: “A great game is a series of interesting choices. (emphasis mine)” – the biggest problem we have is that jumping over an enemy, if it’s always the default fallback, isn’t an interesting choice. Choices have to be novel.

We’re doing a mix here of adding entirely new enemy types, and making the existing enemies more interesting. Quite a few existing enemies are perfectly serviceable designs, but in their existing usage, have been placed in fairly uninteresting situations. For example, a spiked, indestructible enemy is an entirely different beast when filling the breadth of a small tunnel, or when sitting on a small pedestal; as opposed to when sitting on top of flat, open ground. By not being able to move around it, you’re forced to strategize – to stop and think. Solving puzzles like that is what makes games fun; it’s the basic reward mechanism. It’s taken a while to understand this deeply enough to apply it to our own work, but our hope is that Frogatto will come out of this much more fun than it has been in the past.

- Related to this, we’ve built out a full damage-type and creature-type interaction system (similar to Pokémon and quite a few RPGs). Different kinds of damage do different things to different kinds of creatures. Part of this is that there are now secret areas in the game which you’ll only be able to access with a certain kind of damage to break through obstructions – usually a type of damage you won’t get until much later. We’ve worked these into the grab-and-spit mechanic, as well: you can grab objects, and “infuse” them with an elemental attack when you next spit them out.

Hopefully this will all add up to make Frogatto a heck of a lot better for the next release.

by Jetrel at April 15, 2014 10:57 PM

April 14, 2014

Dark Phear

DarkPhear version 1.3.1 released

-BUG FIXED: after using the heat gun, Lou and Fang replace two other members.


by Cleber Casali ( at April 14, 2014 05:35 AM

April 13, 2014

FAR Colony

Alpha 10: End of Data Implementation, Technosciences XML and Basics of the RDS

I designed a certain number of technosciences and theories since mid-March. I will stop it shortly because my plan is to put only most of those of the level 1 to 4 into the XML.
The pre-development phase, with the data structures and the expansion of the loading and saving of the save game file, is near to be completed.

The next phase is finally to implement the first "layer" of the Research & Development System (RDS) which manage the dynamic system and also build the user's interface. This last part will be located into the unified interface panel.

Normally it's OK yet for this first semester, I don't see any problem for this deadline, even if you haven't seen many code commits but it is due to my work into the design. For now there are 134 technosciences into the spreadsheet file and that number is of course subject to change, and also doesn't mean all of them will be implemented; I plan to put about 30 to 40 of them for the alpha 10.

That's all for now and don't worry I working on it, slowly as usual :)

Thanks for your support and interest and stay tuned.

by Jeff B ( at April 13, 2014 09:44 PM

April 12, 2014


More GSoC statistics and ramblings

We can now reveal how many GSoC slots we asked for, and ultimately how many we got, along with some more detailed statistics on the distribution of proposals. The mathematically aware of you may see that one proposal was withdrawn, thus lowering the total number to 79.

The mysterious number in the middle is our slot count. It might not be placed pixel perfect, but I assume students won't draw delusional conclusions from that. ;)
Now implicit from this is that 74 proposals will not be accepted, and hopefully those involved will understand there can be various reasons for why their proposal weren't among the chosen ones. The obvious one is that some may simply have had better proposals. The not as obvious one is that theoretically, the top 5 proposals could be for the same category, with the result that we would most likely have to choose only the top proposal and then go to proposal #6 to find another good one for another category. That is not exactly what happened, but the principle is that even having a good proposal may not land you the slot if someone else had an even better one for the same thing.
But I'd like to point out that not being selected among this year's SuperTuxKart GSoC students does not mean we don't want your contributions. On the contrary, if you find time and can do some things outside of GSoC you can gain some experience and also help us out quite a lot even if the scope of what you do is more limited. Obviously we will have to focus on mentoring the 5 students we select, but we do welcome anyone wanting to contribute and can probably find some time to answer questions that may arise.

Speaking of contributions, we recently had a student and GSoC applicant supply us with a rewritten camera, which has been on our wish/todo lists for a long time. The previous camera had one notable design fault, so getting this code fixed was very welcome. The new camera may still contain some rough edges, but we'll try to smoothen things before releasing a stable version of the game. Thanks a lot to divvy81.

Vlj is still wrangling with graphics code, and among other things he implemented recently in that regard is texture compression, which makes the game consume a lot less video memory than before. In some situations this may improve performance significantly, though you should expect that it will still not be the lightest game around on various resources. We do try to accommodate for a lot of hardware, but there are certain requirements we expect most will be able to meet to some degree.

Anyway, I should probably quit while ahead (or behind, depending on view) and not prolong this post any further, so there you have it folks. Expect another post after the 21st announcing the selected students for Google Summer of Code 2014!

by (Arthur) at April 12, 2014 10:04 AM