kobuge-games/project-kumquat

Repo for Kobuge's 1st hackathon game (a tower defense) - name subject to imminent change

Project Kumquat

WIP Tower Defense game - First Kobuge Hackathon

Powered by Godot Engine

License

Project Kumquat - Tower defense game made with Godot Engine
Copyright (C) 2015-2016 KOBUGE Games

This project is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This project is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/.

project-kumquat's Issues

Version of godot to use with kobuge games

Hello,

I just discovered godot and this project of making open source games with godot. That's really cool, thanks to all the contributors. Someone know how I can know which version of Godot I have to use for each projects of Kobuge games ? (ie : I have seen that for an other open source game tanks made with Godot they told to use the 2.1.4 version of godot). For Kobuge games, It's only the version 2 of Godot, the latest stable (the 2.1.5 ) ?
Thanks

Cancel button should return the money

Cancel button should return the money or it should only charge when tower is placed.

Code conventions

Now that we decided on node naming conventions (#9), we also need some guidelines for the code style.

As I'm a selfish dude, I propose to use the conventions I used in e.g. enemy.gd: https://github.com/KOBUGE-Games/project-kumquat/blob/49dc219/scripts/enemy.gd (or actually also used in @bojidar-bg's level.gd: https://github.com/KOBUGE-Games/project-kumquat/blob/a3d7f76/scripts/level.gd)

Proposal:

Code structure

• If applicable, inner classes definitions on top (as in level.gd)
• Variables section afterwards
  • consts are put on top, names are SNAKE_CASE
  • normal variables are put just after consts, names are snake_case
    • variables are more or less sorted by "usage" when possible
    • comments about variables are put inline, two spaces after the declaration (that's open to discussion, I just started using it ;))
• Methods section afterwards
  • callbacks first (_ready, _init, _input, etc.), in whichever order we find most natural (I'd say order of usages, i.e. _init, _enter_tree (or is it processed before _init?), _ready, and so on)
  • custom functions come next (helper functions, do_stuff(), etc.)
  • signals at the end (_on_button_pony_pressed, etc.)

Code style

• comments start with an uppercase letter, don't end with a dot (unless there are several sentences) --> PEP8 style
• operators:
  • spaces both on the left and right of =, ==, <, <=, +=, *=, etc.
  • spaces both on the left and right of +, - and % (or would you prefer no spaces for % ?)
  • no spaces around * and /
• parentheses around conditionals (if (true):)

I might be forgetting a couple things, but you'll complete. Once we agree on this, we should probably make a guideline and put it in someplace where we can use it as a reference in all projects.

Building towers can't be choosen when not enough money

When you have insufficent money, you can not click on the tower buttons for entering build-mode.

I think this is quite problematic, because it slows things down. You are not able to properly prepare for building / placing your next tower as soon as the money is there. So when you know that you want to place Tower ABC at position X/Y the next, you cannot preselect this tower and hover over X/Y to click in the instance you get the money. Instead, you have to go to the tower buttons first, wait for the money, click it, go to X/Y and click again.

Since you cannot buy a tower if you have not enough money anyways, I see no point in disabling the buttons.

Instead, some visible effect on the buttons that can't be build currently would be fine, but without changing the buttons function itself. Maybe just make the buttons' tower image grayed out or so.

Mouse symbols for building / upgrade don't refresh when money changes

When you are about to place a tower or an upgrade, and you currently have not enough money for that, the symbol at the mouse for that is of course red (which is fine). But if you don't move the mouse and the money increases to a point where you can build / upgrade the tower, the symbol simply stays red.
The game logic is fine, because you can actually build / upgrade in that moment, it's just the images that don't refresh.

Reproduction steps:

1. Build as much towers as you can.
2. Keep the mouse in tower building mode, and place it somewhere where you can build a tower (but you are out of money).
3. DON'T MOVE THE MOUSE FROM NOW ON.
4. Wait for enemies to die to the current towers, so your money increases again to a level where you can build the tower.
5. Look at the symbol: it's still red. Press the mouse: tower gets placed and money goes away (like expected, this works fine).

Node naming conventions

A useless nerdy issue from your favourite OCD guy :D

We currently use different conventions for the naming of nodes, it would be cool to homogenize it (especially so that the get_node("/root/blablabla") calls are not so impacted by case-sensitiveness.

So far we have:

• CamelCase: that's what Godot uses by default (e.g. "SamplePlayer" or "AnimatedSprite"), so that's what I'm using too personally. So we have "Enemy", "Tower", "Level", etc.
• camelCase: in the HUD scene we have "btnTower"
• lower case with underscores: in level scene "tilemap_grass", "tilemap_tower", in HUD scene, "coin_icon", "next_wave", "tower_name"
• random: in HUD scene, "Tower_desc" ;)

I'd propose to use CamelCase for all node names, and lower case with underscores for scene filenames (i.e. only scenes/btnTower.xscn would have to be renamed to scenes/btn_tower.xscn right now).

If that's fine with you I'll do the corresponding changes asap.

Main menu implementation and design

Needs a scene, likely some code and then some art.
Maybe also a general theme like in Minilens.

Skeleton needs a death animation

It can't die for now, but it will come soon ;)

Improve the HUD and add zooming + scrolling

The HUD is currently not looking super awesome due to the separation between the HUD elements on the left and the actual level area in the middle. We should probably look everything on top of the level area and/or design some nice HUD overlay.

If some HUD elements are on top of the level area, we also need to be able to zoom in and out and scroll within this area, maybe a Camera2D can be used for that.

Design discussion: enemies

We should somehow try to plan ahead what kind of enemies we want to implement, and what should be their skills. I think a tower defence is only fun when you have various types of enemies with strengths/weaknesses that force you to build various types of towers, so most enemies would likely be resistant to a kind of tower, and weak to another kind.

To keep things simple, we should probably try to do something a bit systematic like for the towers. If we go with the 3-era theme described in #2, we could have for example 4 types of enemies for each era; the types could be similar in each era and thus work similarly to our towers balancing-wise.

As for the towers, the kind of enemies we chose obviously impacts the art needs of the game, especially if we want the game to have some visual coherence (i.e. we can't just scrape sprites off OGA for all monsters as we likely would have some very different art styles). This can however be seen as a long-term discussion though, if we want we could get start with something heavily OGA-based, and fine-tune it little by little (as long as we have interest in the project, that is ;)).

Tower buying and placement

Some of it is already implemented in the UI, but clicking on a location after selecting a tower currently does not work. The code should be made aware of which tiles are "buildable" (see level.gd), and then instance a tower at the proper location.

Start wave

The "Next wave" button should initially be "Start", so you will have time to plan a strategy and place towers.

What's in a name?

Alright, Project Kumquat likely won't stay as the final name of this game when we want to release a first version, so we'll have to think a bit about how we want to name it :)

Create more levels

To show in the main menu, we'd need to have a couple more levels. We should try to make them relatively different to the existing one (and/or also adapt the existing one) so that they can be used to test the gameplay under various settings.

Better visual effect for tower placement

To make tower placement more intuitive and precise, I would suggest some placement style known from almost any RTS. Here a little example from Broodwar.

In words:
when "building tower" is selected and the mouse is hovered over the map, you see where the tower would be placed at the current mouse position. You see the transparent image of the tower snapped to the grid position that fits most (derived from current mouse position).
Implementation style:

• show tower image snapped to the grid + show radius of the tower (thin white line?)
• Mark tower sprite green if it can be build at current position and red if it can't be build there ... OR ...
• Show sprite only if placement is possible, and don't show if its not possible
  I prefer the first marking style (with green and red), because it shows that tower building is active now even if you are hovering over un-buildable terrain.

Design discussion: theme, story, art style

In our discussions before the hackathon we had the idea of three subsequent themes/eras that we could use to shape the game environment:

• Medieval/Fantasy
• Steampunk (Victorian-era, coal and steam-powered machines and technology)
• Mech/Sci-Fi (big modern robots and turrets, lasers, etc.)

The idea was then that both the turrets and the enemies would have variants in all eras. The turrets would be upgradeable by the player as soon have they have the money (first medieval, then steampunk upgrade, then mech), while the enemies would progressively evolve through the eras based on the duration of the game (and difficulty level probably).

So to keep the game in balance as a player one should try to match the tower upgrade level to the type of monsters that are arriving (medieval turrets vs mechs would not work well :p).

---

This idea is still open to discussion of course, since not much of it was implemented yet. It also has a very important influence on the assets, as we would need art assets that are in the same style for each era (i.e. not go from a Zelda-like medieval/fantasy to a Shadowrun-like Steampunk to end up with cartoony sci-fi :p).

So we also need to take into account how much work we want to do on the assets. If we are not ready to create a lot of artistic content, then we should maybe try to rethink the theme(s) so that it's easier to achieve.

Upgrade button costs as much as buying tier2 or tier3 from scratch

The upgrade button should only charge the different between the existing tower and the tower of tier+1.
Should be relatively simple to do but I haven't understood yet how upgrading towers work :D

Implement utility towers

As defined in the pad: https://framacalc.org/project-kumquat

How to handle the various tower types architecture-wise

We need to decide how we want to handle the various tower types at the architecture level. What I mean by that is whether we should use one separate scene file for each tower type, share some parts with subscenes, use scene inheritance, etc.

1. One scene file per tower type: all those scenes would like using the tower.gd to share the basic mechanism. It's likely the easiest solution, but means that changes done in one scene will have to be done again in all scenes if they are relevant for all tower types; we won't have many tower types though so it's maybe not a big deal.
2. One scene file per tower type, all instancing a common subscene for the parts that are common to all towers (home-made scene inheritance).
3. Only one tower scene, and differentiate all tower types using export member vars. The problem of this approach might be that we'll need to change many parameters in _ready() based on the export vars (spritesheet, etc.), and it might be problematic if we want to use different animations or sounds.
4. One tower scene, and use of the new scene inheritance mechanism. I have no idea how this works, but that might be worth looking into (or maybe just for enemies).

Are there other possibilities? WDYT about the ones above?
I guess 1. or 2. are likely the simplest solutions if we have only ~4 tower types.

project.godot

Are these just assets or is the import file missing?

Initial tower behaviour

They should fire at a regular interval on an enemy in range.

I think that typically, the tower should start by locating the closest enemy in range, and the lock onto it: it will fire at it as long as it's still in range and not dead, even if it's not the closest enemy anymore. Once it leaves the tower range, we go back to searching for the nearest enemy and lock onto it.

Add visual feedback when enemies are hit

Good idea from @Calinou.

Possible Story-line

I know it's hard to make a story around such games, but hopefully we can discuss and mix our ideas together to get something that makes sense 😊
When I use "Gaia" and names or expressions as such, they are just meant as placeholders because nothing better came up to my mind.

The Universe got a special configuration and thus a gate between two different dimensions got opened on the planet Gaia. The one dimension is inhabited by a superior life form, energy entities that live in peace with each other. The other dimension is massively overpopulated by all kind of wild creatures. While the gate is open, the wild hordes try to enter the new dimension through the paths of Gaia, desperate in the search of a new place to live. But the elementary entities channel all their energy to build up a physical defense against the intruders.
But with every creature passing the gate, the elements energy get disrupted and one of their towers falls for the negative energy of the intruders, opening yet another gate to their fierce world. (<- last sentence is the "twist")

Towers are placed with an offset

Left shows the way it should be, and right shows how it is currently.

The towers are placed 8 px too much to the south.
I think this results from the tower sprites being centered, and since they are 32x48 px in size, there is an 16/2 = 8 px unwanted misplacement in y-direction. It should be fixed by manually choosing the correct anchor point of the sprite (define offset).

Implement winning/losing mechanism

Currently you can't lose the game ;)

Placing several towers without having to select them each time

In my latest commit that fixed #12 (b5cc738), I made it so that once you have placed your tower, the cursor goes back to normal mode (i.e. not tower placement mode).

We might want to make it stay in tower placement mode so that you can place several towers at once. That's quite easy technically but raises one small question: how to handle the budget modification at each click?

Right now the transaction money is removed as soon as you click the button; that's fine if you place one tower, but if you place more than one, then you should get some money removed at each click, and then get the last transaction back once you cancel the tower placement mode. That would be a bit confusing IMO.

I guess a better solution would be to remove the money only when actually placing a tower, WDYT? (long issue for a very simple question, but well :p)

Spawn position is at an half-tile offset

In the current HEAD, the skeletons spawn at an offset of a half-tile instead of being well centered on the tile.
The enemy has its origin in the middle of its "feet" tile, so that's what should be used to spawn it.

Balancing the game futher

Some ideas to balance the game further:

• Make enemies spawn less frequently, so that you don't have to fight 200 of them at a given time
• Make the enemies stronger, to counter balance their lower number

Further ideas welcome :)

Spells/skills, pickable resources or bonuses

A nice gameplay addition would be to have spells and/or skills that the player could cast.
They would likely be unlocked with gold just like the tower tiers, and then cast with mana. Mana could be hoarded when killing monsters, or generated over time, or both. Or there could even be a utility tower that generates mana actually :D

If monsters dropped it, it could take the form of a collectible item (with a loot probability) that the player would have to fetch before it disappears. The same logic could be extended to some kind of gold bonuses too, or even autocast spells (like you pick the item and all enemies are slowed down for 10s).

Design discussion: the famous twist!

As we said, we want to make a boring tower defence, but with a twist! (like all tower defence basically :p).

The were some very good ideas on the pad, and we mostly settled on @fry-'s one:

Twist: It's maybe a bit egoistic, but I like my idea the most :P Enemies that break through 'infect' a tower (the one first in the line) and make additional enemies spawn. Infection will take like 60sec or so before the tower gets back to normal.

If we all agree with this gameplay element (I find it pretty cool personally :p), we need to discuss its implication both on the logic and graphics:

• What happens when an enemy reaches the "base"? How to chose the tower that would get infected, how look would it be infected and how would it behave (mob spawner? how many enemies/min, how strong, etc.)
• What would show visually that the tower is infected? Particle effect, specific sprite, etc.?

Design discussion: tower types and upgrades

In this topic we could brainstorm about the kind of towers/turrets (don't know what's the best word, but it doesn't matter :p) we want to have in the (more or less final) game.

It's somewhat dependent on the game theme (#2), but there's also some more general logic things that we need to settle upon.

Basically the initial idea would be that towers would have:

• a type (defines the kind of action/damage/skill they perform)
• an upgrade level (defines the "era" they correspond to if we continue with the theme proposed in #2, i.e. medieval/steampunk/sci-fi)

---

Regarding tower types, we had so far those proposals in the pad:

@fry-:

Tower types:

• 1x normal direct damage,
• 1x area damage (makes lesser damage to single units, but can damage multiple units that are near by at once),
• 1x slow motion (makes low / no damage, but slows down enemies so other towers have more time to deal damage),
• 1x poison (deals low / no damage, but poisons the enemy unit and makes it suffer damage while walking)

@ObaniGemini:

Towers :

• Weak + Normal range + fast (e.g : turret)
• Strong + slow + large zone damages + Low range (e.g : cannon)
• Very weak + Very High range + fast + slowing the ennemy (e.g : mage tower)

Feel free to build upon those or propose other stuff so that we can decide what to implement. Of course we will need assets made (or found, if in the correct style) for each tower type + upgrade level, so the opinion of our artists will weigh a lot ;)

---

The other part is upgrade levels, which would let upgrade each tower type to a stronger one. It could be done either per-tower, i.e. you always build level 1 towers and need to upgrade them, or globally (you build a very expensive mass upgrade and from now on all your towers of this type will be upgraded, both the old and the new). I think the first solution is better though, the second one would be way too expensive and would make balancing very hard (huge power increase all of a sudden vs. incremental increase tower by tower).

Once we decided on the tower types, we could start thinking about what each upgrade would bring to each type as bonus (attack increase, range increase, new skills, etc.).

Base/nexus (enemy goal) assets

We currently have a "goal" that enemy will converge to, and take damage when reached.
I'm not sure how to name it: base, nexus, HQ, town hall, whatever? It kind of depends on the theme and "story" (#2) so that we know what are those enemies actually trying to attack :D

At any rate, this base will need some graphics too.

Directory structure conventions

Should we change the directory structure as proposed in the wiki?

Basically the idea is to switch to:

- game/
  - game.tscn
  - game.gd
  - btn_tower.tscn
- level/
  - level.tscn
  - level.gd
  - tileset.png
  - tileset.tres
- towers/
  - base/
    - tower.tscn
    - tower.gd
    - range_indicator.png
  - tower1/
    - tower1.tscn
    - tower1.png

Currently we use a structure like:

- graphics/
  - tileset.png
  - range_indicator.png
  - towers/
    - tower1.png
- resources/
  - tileset.tres
- scripts/
  - game.gd
  - level.gd
  - tower.gd
- scenes/
  - game.tscn
  - btn_tower.tscn
  - level.tscn
  - towers/
    - tower.tscn
    - tower1.tscn

Proposal: shields

We can have shields, that would take damage just as other enemies do, but also prevent splash-damage from reaching other enemies and snipers from shooting through them.

A few more tiles are needed

While doing a level for testing the new pathfinder (which is still not in git, but, well...), I think it would be nice if we have a bit more tiles:

1. Broken versions of the unwalkable and unbuildable tiles. (e.g. broken statues, pillars, etc.)
2. More Grass-Dirt transitions.
3. Some way to make good-looking castle walls (and optionally, village/city walls)
   • Maybe based off the current pillar tile, just vertical, plus some additional tiles for the corners.
   • Another idea would be to make it based on the buildable stone tiles.
   • A third idea would be to just make it look like a quickly done wall from sticks/spears/lances, i.e. https://en.wikipedia.org/wiki/Palisade
4. Umm.. what 4? That's all I can think of...

Better GUI / HUD layout

I would like to see some more buttons on the HUD, so you can build Tier 2 / 3 Towers right away.

• Left: Initial HUD state, where you start all with Tier 1 towers. you can upgrade them per tower-type, and if you did that, you can upgrade the single towers of that type on the map too (gets unlocked by upgrading in general)
• Right: shows a more advanced state in the game. The player has upgraded some of the towers. Also, he has got some enemies entering his goal, so the "next wave" button is disabled and he has to disable towers / set towers to spawning points before he can go with the "next wave".

Let me know your opinion, criticism, ideas, ... 😀