SOC2014 Daniwa Ai

This page is related to Summer of Code 2014

See the list of Summer of Code 2014 Ideas

This is a Summer of Code 2014 student page

ATTENTION

• This page is under construction.

Description

Improve the AI's Attack and Retreat decisions.

Abstract: Implement a process that would allow the AI to make correct decisions in regards to attack and retreat. It will be based off probability focused on current metagame habits.

Proposal: The focus of my implementation is not on outputting the optimal result in every case but instead will aim at mirroring a player like decision. The goal for this is to foster and develop good game decision making in new players and prevent bad habits. Ideally, the AI should act correctly but unpredictably (which is technically impossible) and be able to be a training aid.

IRC

Daniwa

Questionnaire

1) Basics

1.1) Write a small introduction to yourself.

Currently a full time student. I enjoy biking and having too many side projects that I'll never finish

1.2) State your preferred email address.

pham.dany@gmail.com

1.3) If you have chosen a nick for IRC and Wesnoth forums, what is it?

Daniwa

1.4) Why do you want to participate in summer of code?

I want to take up a new project and learn how to get around in an established code base. Learning in a controlled environment is hopefully what I want to get out of this program.

1.5) What are you studying, subject, level and school?

Second year undergraduate at Montreal's McGill University. Majoring in Computer Science.

1.6) What country are you from, at what time are you most likely to be able to join IRC?

East Canada, and I'm usually on and IRC during the daytime and evening. 15:00 to Midnight UTC

1.7) Do you have other commitments for the summer period ? Do you plan to take any vacations ? If yes, when.

Currently no, but I usually take a week away at the end of July

2) Experience

2.1) What programs/software have you worked on before?

• School Projects: a spaceracer AI in java and a website password verification module in C (of the noteworthy).
• Open Source Project: Member of Project Hawkthorne a 2d platformer built with Lua/Love engine.

2.2) Have you developed software in a team environment before? (As opposed to hacking on something on your own)

Yes I have. For both small school projects and evidently the open source program.

2.3) Have you participated to the Google Summer of Code before? As a mentor or a student? In what project? Were you successful? If not, why?

No, This would be my first time.

2.4) Are you already involved with any open source development projects? If yes, please describe the project and the scope of your involvement.

Yes, as mentioned above I am a member of Project Hawkthorne. https://github.com/hawkthorne/hawkthorne-journey It's a 2d Platformer based on an episode of NBC's tv show Community. My involvement is varied, I have started off doing art for it, but I'm mainly focused on reviewing code and fixing bugs (from trivial to game breaking) which we receive automatically through https://getsentry.com/welcome/

2.5) Gaming experience - Are you a gamer? Of Course

2.5.1) What type of gamer are you? The best way might be to say serious as when I find a game I like I dedicate hours to it.

2.5.2) What type of games? All kinds of games, but they all revolve around the idea of playing against someone. The current type of choice is fighting games more specifically, Super Smash Bros. Melee. The reason being it's really faced paced and you have to apply mind games to win at a competitive level. Of the same type, I've spent a lot of time with Skullgirl and Nidhogg. But this is not an exclusive, as other include:

• Real-time Strategy: With my friends we religiously play Age of Mythology
• Turn base Strategy: The same goes for Pokemon.
• MMO: More specifically, only the team arena Player vs. Player portion of World of Warcraft
• Indie: Relax games with good art style like FEZ.

2.5.3) What type of opponents do you prefer?

I always prefer a real opponent if a game can offer it, as they can teach you what you're doing wrong which jumps you in the learning curve.

2.5.4) Are you more interested in story or gameplay?

Definitely gameplay as that's most often than not what makes me come back to a game.

2.5.5) Have you played Wesnoth? If so, tell us roughly for how long and whether you lean towards single player or multiplayer.

Yes but no. I have been putting in a few hours over the past 3 weeks but I'm no where near saying I'm comfortable around the game yet. I've played with a friend and multiplayer is definitely my preference.

2.6) If you have contributed any patches to Wesnoth, please list them below. You can also list patches that have been submitted but not committed yet and patches that have not been specifically written for GSoC. If you have gained commit access to our repository (during the evaluation period or earlier) please state so.

None to report, but I hope to change this!

3) Communication skills

3.1) Though most of our developers are not native English speakers, English is the project's working language. Describe your fluency level in written English.

Fluent in both written and spoken English as I do attend a English University.

3.2) What spoken languages are you fluent in?

I speak, English and French.

3.3) Are you good at interacting with other players? Our developer community is friendly, but the player community can be a bit rough.

Yes I am. I moderate over at http://www.reddit.com/r/hawkthorne which is Project Hawkthorne's direct interface between player and developers. Though activity has waned lately.

3.4) Do you give constructive advice?

I strive to. I've helped many get started in coding for Project Hawthorne.

3.5) Do you receive advice well?

Any advice is good advice to me!

3.6) Are you good at sorting useful criticisms from useless ones?

Coming from the fighting game community, I would have to say yes as you receive many mixed signals from all over the place.

3.7) How autonomous are you when developing ? Would you rather discuss intensively changes and not start coding until you know what you want to do or would you rather code a proof of concept to "see how it turn out", taking the risk of having it thrown away if it doesn't match what the project want

I've always done a proof of concept first and then discuss it often taking it in a direction that I had not thought would've been possible. It sets a starting point for a serious discussion for the topic.

4) Project

4.1) Did you select a project from our list? If that is the case, what project did you select? What do you want to especially concentrate on?

I chose to go with " Improve AI by implementing global attack/retreat decision " I really want to focus on the making the decisions player-like as I've seen too many games go with the most difficult for difficulty sake and fostered poor player habits.

4.2) If you have invented your own project, please describe the project and the scope.

4.3) Why did you choose this project?

It's in the bounds of what I'm capable of implementing. The more important point though is the fact that it's the only project I had a clear idea of the direction I want to take it.

4.4) Include an estimated timeline for your work on the project. Don't forget to mention special things like "I booked holidays between A and B" and "I got an exam at ABC and won't be doing much then".

None of this is set in stone yet but if I follow my past summers and my plans for this one I should be able to spend a good deal of time on the project maybe barred one week at the end of July. My exams end at the start of May so I'm guessing I'll start then. I would give myself a week to get familiar with my portion of the code and then start building right after that. Though I do intend to discuss game tactics a lot in order to determine the correct course of actions.

4.5) Include as much technical detail about your implementation as you can

I'm not too familiar with the best tactics yet, but the ideal is to determine if an attack is imminent and either attack first if our loss would be less, or if we've reach a point of no return retreat.

My aim is to analyse the playing field as best possible then apply player like probability thinking.

4.6) What do you expect to gain from this project?

Gather knowledge from working in project with multiple dependencies.

4.7) What would make you stay in the Wesnoth community after the conclusion of SOC?

Only if you guys don't bite. Which look like you don't

5) Practical considerations

5.1) Are you familiar with any of the following tools or languages?

   Git (used for all commits) : Extensively. https://github.com/DaNiwa
   C++ (language used for all the normal source code) : No. Though I'm proficient in C. I've yet to look deeply in C++
   STL, Boost, Sdl (C++ libraries used by Wesnoth) :  None of the above. (I know of SDL through Lua/Love).
   Python (optional, mainly used for tools) : Yes, I've done many assignments in Python though I wouldn't go around and say I have a working knowledge of it. Though reading knowledge i could say yes.
   build environments (eg cmake/scons) : Very basic usage so far.
   WML (the wesnoth specific scenario language) : It's the first time I hear of it.
   Lua (used in combination with WML to create scenarios) : Extensive knowledge as it's the language we exclusively use for Project Hawkthorne.

5.2) Which tools do you normally use for development? Why do you use them?

I've usually always used a basic text editor(with highlighting) and a shell. On Window that would be Notepad++ and Powershell. On Unix that is Geany and Bash.

The reason I like this workflow is that it forces me to know the ins and outs of my code in a very detailed way.

On big project I've enjoyed using Eclipse as it give me access to documentation.

5.3) What programming languages are you fluent in?

In order of knowledge: Lua, C, Java, SML

5.4) Would you mind talking with your mentor on telephone / internet phone? We would like to have a backup way for communications for the case that somehow emails and IRC do fail. If you are willing to do so, please do list a phone number (including international code) so that we are able to contact you. You should probably *only* add this number in the application for you submit to google since the info in the wiki is available in public. We will *not* make any use of your number unless some case of "there is no way to contact you" does arise!