#ceilidhcoding

[gayprogrammer]

This week has been rather slow for me, so I've had time to work on the next update for what I'm making:

Cards! The game now starts with a deck of cards (two, actually), that can be drawn from in a quick animation that took a couple tries to get right. Of course, cards aren't very useful if you can only draw them, so now you can play them from your hand too!

Well, they don't do anything yet, but that'll come next. After I do some debugging, of course. (I've also added a nice skybox instead of the plain gray background, but more on the environment another time.)

[gayprogrammer]

Friday Update #4!

As predicted, this week has been super busy for me. I got a lot of my work done, fortunately, but it didn't leave much time to work on my game. I did get one thing working, though, which is that you can now play building cards to tiles!

Buildings cannot be built on top of other buildings, and most are limited in what terrain they can be built on. Also, the building models aren't final, but if you like them you should check out the person who made them here.

Besides that, I also hunted down a couple of bugs so everything is running pretty smoothly. I should have much more free time next week, which is when I intend to start working on turn systems, resources, and making this an actual multiplayer game!

[gayprogrammer]

Friday Update #7

IT'S WORKING! YESS!!!

Spring break was very nice, and I really didn't actually do much programming over it. I did however manage to fix a couple of serious bugs that were preventing the turn system (among other things) from working! There are still more minor issues to fix, but this is a pretty big deal. Getting this to work is honestly really exciting, as it means that I can start thinking about working on more advanced gameplay mechanics, which is always fun.

Next week I plan on taking things a bit slower: making sure that as many bugs are fixed as possible, and adding some more non-code content, such as building models and additional cards.

[gayprogrammer]

[gayprogrammer]

It's Friday! Card actions and effects are coming along, but there isn't much to actually look at yet. So, in the meantime, check out the new terrain models!

Terrain is broken into 4 groups based on elevation:

- Snowy Mountains

- Rocky Mountains

- Forests & Plains

- Swamps

For now each group has three different models which the map generator chooses from at random from when it places them. If you want to see them all, check out the gallery here. Eventually, the different types of terrain will be relevant for playing the game, but for now, it just looks pretty.

Other new things include the nice map controls you see in the gif, the highlight around the cell your mouse is over, and some bug fixies that made all of this work in the first place.

My goals for next week are to be able to place buildings and track some other game mechanics, but I'm going to be pretty busy so I can't make any promises about when that'll be ready.

Thanks for reading!

[gayprogrammer]

Started working on the main menu scene to go with the new multiplayer functions and matchmaking. Might make the table a little less cluttered.

Behind the scenes :)

[gayprogrammer]

Game Design: Control

In the process of making Summer Kingdoms, I recently sat down and wrote out a very comprehensive list of rules for the game. In the process, I found that there were still a handful of questions needing answers. For example: control. You can build buildings all you want, but controlling them is necessary to collect their resources. But how exactly should control work?

I pretty quickly worked out two possibilities:

First Design: Each player only has control over the buildings they have units on.

Second Design: Players always have control over buildings they build, until captured by their opponent, regardless of unit occupation.

While the idea of controlling only the buildings you occupy with units adds a whole new and interesting layer of strategy to the game, the board quickly becomes rather crowded. This in turn makes things more difficult to keep track of and just makes the game needlessly complicated.

However, I really like the new strategy involved with unit placement that the first option offers. So, for now, I've found a compromise between the two:

Third Design: Some buildings have a new stat: Control Range (eg. Control Range: 2). While buildings with this stat are occupied, the occupying player controls it and all other buildings within the radius of its range. (Contested buildings can only be controlled with direct occupation.)

Strictly speaking, this rule is wordier than either of the others, but personally, I think it manages to find a happy medium between requiring more unit strategy and reducing clutter in the game.

I'm still very open to ideas, so if you have any thoughts you'd like to share on this please reply or reblog, and my asks are always open. Also, check out my profile for more dev logs and game updates.

[gayprogrammer]

Game Design

From its initial creation as a physical card game to its current digital status, Summer Kingdoms has maintained a rather steady design. It is a 2-player game, in which each player assumes the role of a monarch leading their kingdom against their opponent.

The game plays out on a roughly 6-15 board, though it was originally much smaller. At the start of the game, each player has only their first building: the Palace. If this building is lost to your opponent, the game is over.

Playing the game involves drawing cards from your two decks: the building deck and the spell deck. There's a maximum hand size of 5 cards, which you draw up to at the start of your turn. Buildings cost gold to play onto the board, and spells have no cost to cast, though you may only play one per turn.

Originally, buildings had a single stat associated with them: yield. At the start of each player's turn, they may collect the yield of each building they control in the form of either gold or units, choosing for each. Where gold facilitated building buildings, units could be moved across the board to combat and capture your opponent's buildings. When the game switched to a digital format, yield was split into separate gold and unit stats to make turns faster and simpler.

Also when the game switched to digital, the mechanics were changed to include a kind of deck-building. Now, each player starts with a simpler deck and adds more complex and powerful cards to it that suit their strategy.

This is the question regarding game design that I'm currently on. Most deck-building games have a sort of "market". A zone in the game where new cards can be found and bought. Without this, obtaining new cards will be reliant on playing the cards you already have. The issue here is that this could easily make it difficult to make all cards in the game equally obtainable. It would require the addition of more cards specifically used to obtain new cards, which dilutes the pool of useful cards. If that makes sense.

Adding a new mechanic from scratch is a lot easier said than done when it comes to digital, and doing so will in turn create its own new questions to be answered and bugs to be fixed, but it's probably the right move.

Feel free to add any thoughts to this. My inbox is also always open for questions. Thanks for reading!

[gayprogrammer]

Friday Update #5

Well, unsurprisingly enough, adding multiplayer functionality and networking to a game isn't easy. That being said, it works!

Now when the game is loaded, instead of taking you directly to the game scene, it loads the new main menu. From here you can use matchmaking to join a random game, or create and join a specific game if you want to play with a friend!

The main menu also has some other buttons that don't lead anywhere, but I'm sure they'll be relevant eventually...

Admittedly I was also really hoping to have a turn system in the game by today, but as it happens that's harder to set up than server stuff. Huh.

Well, my goals for next week are to get that turn system working, maybe add to buildings a bit, and also sort out that bug in terrain generation that you might have noticed in the second gif.

Stay tuned for more!

[gayprogrammer]

Procedurally-generated landscape

[gayprogrammer]

Friday Update #6

It's already Friday! Time to show y'all what I've been working on for the last week.

I've been trying non-stop to implement a fully functional turn system along with some other useful features, like a game settings panel with "Return to Main Menu" and "Quit Game" buttons. And for the most part, it all seems to be working!

The built-in screen recorder didn't want to record both windows at once, which might be for the best this time. I may have gotten a little carried away with adding new code, so the project is a buggy nightmare right now, with issues including but not limited to:

- When you draw a card, your opponent also draws a card. - The turn counter doesn't seem to be iterating properly. - Doing the one pre-game action required by the game crashes it. - Trying to play more than one card in a turn also crashes it.

Basically, I'm gonna spend a while debugging and making everything work before moving on to the next stuff. Speaking of which, Spring Break is starting for me! It's gonna be nice to relax for a week, but it also means that there probably won't be a major update next Friday. Maybe I'll brainstorm possible names for this project.

Until next time!

[gayprogrammer]

Okay so I made really good progress and now all of these bugs

are solved! Leaving just a few new ones:

Not to jinx myself but I might have these done by Monday.

[gayprogrammer]

Snowy Mountains

[gayprogrammer]

Friday Devlog #12

This week has sure been a week. Unfortunately, I got next to nothing done due to the sheer amount of things and stuff I've had to handle. Thankfully, I'm done with one of my classes for this semester and the others are almost over, so hopefully development on Summer Kingdoms will be ramping back up over the next few weeks. Until I manage to find a job, at least.

Yeah, that's pretty much it for today. I might post some progress again in a couple days since I'm going to be much freer now.

[gayprogrammer]

Finished working out random terrain generation for my games board, which took a *lot* of tinkering to get right. I got it working eventually though, and after having it generate different colors, have started getting some very nice-looking results.

This many mountains might be an issue later, but for now I think it's a pretty good start. Now that this is done (for now) I'm going to go back to working on playing cards from hand onto the board.

[gayprogrammer]

Friday Update #10

We got there! 10 weeks!

This is already a pretty big milestone, but I'm going to take this time to announce some rather large updates regarding game design and the mechanics of Summer Kingdoms, and what it's going to look like going forward.

First of all, in order to make the game as accessible as possible and to generally reach a broader audience, Summer Kingdoms is going to be a mobile game from now on. I understand this is a large change to make, but the rest of the game's design will be accommodated for this.

For example, building models are going to be greatly simplified so as to be more recognizable on smaller screens. One such new model can be seen below.

Secondly, the game board is going to be made smaller, and units will be represented as cards, just as spells and buildings already are. These changed should both make the game easier to understand and speed up the overall gameplay flow.

Finally, I can share the first sneak peek at what this new and improved Summer Kingdoms will look like!

April fools :)

This week has been pretty busy for me, and that's not going to end until next Monday, but in what spare time I could manage I got around to fixing a couple of annoying bugs regarding coroutines and movement over time, as well as simplifying some more code.

Please disregard all of that.

I've also laid the groundwork for individual building and spell effect scripts, as well as unit summoning, movement, and combat, although it's probably going to be a few weeks before we see any proper fights, and I'm starting to second guess how I'm going about setting up effects.

That's about it for now, though I may be posting another ramble about game design sometime this weekend or next week.

Thanks for reading!