Since the Sunflower engine is starting to have to much information about it to keep it all in my personal blog, which is supposed to be about other things as well, I opened a wiki. All information about the engine will go there from now on, so if you’re interested in playing card games, creating card games, or teaching your computer to play card games – go right here.
First, initial release of the Sunflower engine (version 0.26) will come in a few days, so it’s about time to start giving information to anyone who might want to play and make games for it – starting with, how to make AI. Currently it has to be made in Java, but more languages might be supported in the future – especially if many people ask for it.
What you’ll need:
- The official Sunflower engine Jar file (which will be available for download within a few days).
- The AI interface of the game you want to make an AI player for. I still haven’t decided on the official AI interface format, so for now I’ll just write something down for the first game to be released for the engine (which will be Hearts).
- The ability to write and compile a Java class.
How to do it:
- Create a Java class that extends the class AIAgent, and place it in the package sunflower.ai.
- Create a constructor that accepts an AIAdapter and an int (which is the playerNum – identifier of the player in a multiplayer game).
- Override the getSupportedRulesets method, which returns an array of String, with the names of rulesets this AI can play on.
- Override the getName() method, to return whichever name you want to give your AI player.
- Override the play() method. For now, just put nothing but “return false” in it.
- Compile the class, and put the .class file in the resources/AI subfolder of the Sunflower folder.
By now, the player exists and is recognized by the engine. All that remains is to actually play against it.
- Open the resources/menus.xml file. Look for the “Start Game” button, and inside it look for the tag:
Change the value to the name of your own player (the one you returned in getName()).
- This is it – time to play with your new AI opponent!
Of course, it would be a little bit unimpressive to play against someone who doesn’t do anything. So in the next post we’ll see how to put some actual gameplay in the play() method. Stay tuned!
(Note – I was going to put code examples in this post, but my WordPress skills must be lacking, because I can’t get it to look good. So I’ll just put a link to a complete code example in the next post)
There it is – a first video look at the Sunflower game engine, playing a game of Hearts against three AI opponents:
The opponents are mindless AIs – they look at all their legal options, and randomly choose one. Smarter AI will hopefully come later. The video was created by an experimental new utility that will come with the engine – one that turns game replays to videos, ready to upload to YouTube. I strongly believe that video broadcasting has become and important part of gaming and rightly so, therefore I consider it to be a very important feature and hope that you’ll be seeing many more gameplay videos in the future.
Getting ready for the release of the initial version of the Sunflower Virtual Gaming Table, here’s a little description of how the engine works. It’s built to be very modular and modifiable, and most importantly – to allow as much game creation and modding as possible be done without having to get into the actual project code. So here’s a basic description of the components of a game in the engine, with more detailed descriptions coming in the near future. All the terminology is currently based on card games, but the engine will also support other kinds of board games.
A Sunflower game requires the following – a ruleset, a table, a card set, (optionally) a deck, (optionally) a scenario, and an AI player.
The ruleset is the basic definition of a game in the engine. It fully defines the rules of the game, using a special-made markup language and scripting language. Since both are still under heavy construction, I’m not yet releasing an API, but it will come soon, and then you’ll be able to create all the games you want without having to mess with the engine code.
The table is the visual part, the appearence of the game on the computer screen. Each table is built to handle one or more rulesets, but is not necessarily bound to it – many tables can be used for a single ruleset, so artists are free to design tables that look however they want for any game. The tables are also defined with a custom-made markup language, so of course tables can be designed by artists, without any programming knowledge and without any need for messing with the internals of the project.
The card set is the pool of possible cards to use in a game. Each card has a set of properties, depending on the game – a classic card set will have properties “Suit” and “Value”, WTactics cards will have things like “Gold Cost” and “Attack Value”, and so on. Just like tables, card sets are made for one or more rulesets, so you can easily use a single ruleset to play with different cards.
A deck is a set of cards. Note that unlike a card set which defines possible cards, the deck has actual cards that can appear on the table – each card in the deck is an instance of the “prototype” card from the card set. Thus a deck is specific to both a ruleset and card set. Decks are expected to change with players in many games (such as WTactics), so a deck building mechanism will definitely come in the future.
A scenario is a snapshot of an ongoing game at a certain point. It allows creating games with several modes, identical in rules but different in starting conditions. This is the only basic element completely unimplemented yet.
An AI player is a piece of (compiled) code that knows how to play a certain game. They are loaded dynamically at runtime, so everyone can write new AI players without having to get into the engine code. This will probably be the first thing I’ll write an official API and tutorial for, so if you’re interested in AI, you might be interested in following it.
More is coming soon, stay tuned!
My excellent 2.5 weeks in Sweden are over, and the results will soon be announced – a new, single-player oriented card game engine, which will hopefully allow people to play a large selection of card games with AI opponents. Since WTactics is not finished yet you won’t be able to play that for now, but some other games will hopefully be implemented soon, each with its own AI opponent ready to challenge you. More details coming soon.
Those, of course, were my results – for the general WTactics project, see here.
It’s time to announce something I’ve been occupied with for a while now and haven’t mentioned yet – I’m going to land in Sweden this Friday to participate in the WTactics Summer of Cards.
Basically, WTactics is an open source collectible card game, or at least hopes to be so in the future. It has a very nice start so far with some beautiful cards and a promising set of rules, but it’s still not a working game. The Summer of Cards is a month-long game jam meant to push the project forward.
Now, what am I doing there? I’m going to work on a single-player card game engine the game will be able to use. The open source world has a few multiplayer card game engines, which allow players to meet online and play freely, taking care of the rules themselves. Single player support is much less common, and that’s where I come in – I think a single-player experience with an AI opponent is very important for new players to get into the game, and I’m going to work on it. The engine is already advancing nicely, and here’s what it currently looks like:
But there’s more. While I like WTactics’s potential, my open-source philosophy dictates making engines rather than games. I want my work here to be applicable to any future card game which will want it. So I’m going to start asking for any game designers out there, who have a set of rules ready – let’s see what we can do to make sure my engine will work for you as well. More on that in some upcoming posts.
My month in Lisbon really brought me some inspiration for my first commercial game, so stay tuned – gameplay is nearly complete, and an initial private demo will soon be released to the playtesters (in other words – random selection of my friends). So there is still hope that soon you’ll get to see the actual game happening. Just wait a little more.
In the previous post I said that if the Serpent Scribe of Kyoto was a success, I’ll try to continue making language-learning games. Unsurprisingly, I couldn’t help myself and didn’t wait for it to succeed. I’ve been working on some nice things that might become available soon.
I think it’s really an interesting experience with some lessons to be learned about memory and learning. I’ve tried several alphabets with the Serpent Scribe, and I think I can say that about 30 minutes with a game like this can bring me from knowing nothing in an average alphabet, to knowing it all. However, if I stop there, I’ll forget it all about an hour later. So the next challenge would be retaining the knowledge. This brings me back to what I asked a long time ago about mnemonics – if they can help us learn so much in such a short time, can we use them repeatedly and learn an entire language in a month?
It seems like the way to retain such information is to create associations – see the information in as many contexts as possible, not just in the simple flashcard or dictionary entry. One of my favourite examples is music – I’m often amused by how my vocabulary in languages I don’t know is affected by my favourite bands in the language – in German I can speak of death and blood, but I can’t ask what time it is. In Hungarian I can talk about flowers and birds, but not much else. In Portuguese about forests and hunters, in Indonesian about love and spirituality, and so on.
The Serpent Scribe starts working on it by providing challenges – chances to use the symbols learned in new contexts. But more work is needed.
This is why I think most structured language learning methods are useless on their own – I think the best way is to drown yourself in a huge array of different methods, each one bringing new associations to pick up new words from. But more importantly, I think you need to learn the language while doing something other than language learning – associations need to be between two things, so there has to be something else happening while you’re learning. It could be an especially frustrating level in a game, could be an awesome guitar chord in a song, or anything else. So my goal is to make games that are fun on their own, and as a side effect make you encounter loads of different words in the language you’re learning. We’ll see if I can make that happen.
Here it is – my first HTML5 game is available, combining two of my hobbies – gaming and language learning. The Serpent Scribe of Kyoto will allow you to feel like you’re wasting your time to the addictive void of snake, only to later find out you learned something – in this case, the Japanese writing systems Hiragana and Katakana. It works so well that I can now read both even though I had no intention of learning Japanese (yet) – it just comes naturally, that’s why I love the combination of gaming and learning so much.
Anyway, it’s available on Kongregate and you’re welcome to try it – it doesn’t matter if you want to learn Japanese, I think even playing a little game of snake and then being able to brag about your Japanese reading skills at the next party you go to is already worth it. I’d love to get some feedback, and to hear if you started reading Japanese because of it.
If it turns out to be a big success, you might see more of those coming in the future. Otherwise, they’ll probably come mostly to help me learn whatever I’m trying to learn at the time.
 Yes – as usual, it’s an old idea I recycled. I like doing that.
 Clearly, I’m a master of impressing people at social events.
After a long while, it’s time to announce my upcoming commercial project. The game will be an abstract shooting game based on my previous project, Ring of Marbles. Before boring you with words, here’s a sample level:
The point of the game is to shoot the targets thrown at you in each wave, without destroying your own armor – everything in the game is made of colored marbles, and your own health bar is a ring of marbles hovering around you. So if you’re not careful, you might end up destroying yourself instead of the targets!
In addition to several different campaigns, it will also include survival mode, and local multiplayer, and for the perfectionists among you – local high scores and achievements. Being my first commercial project and a fairly casual game, expect a very casual price point (no more than 5 US dollars).
The development is mostly complete, and since I’m on vacation now, it is in an extended testing phase. Release will hopefully be by the end of the year.