Author Topic: NausicaäRL  (Read 9867 times)

Anvilfolk

  • Rogueliker
  • ***
  • Posts: 374
  • Karma: +0/-0
    • View Profile
NausicaäRL
« on: July 05, 2013, 06:13:19 PM »
Hi all,

I tried making a 7drl based on Kaze no Tani no Nausicaä, but of course that failed miserably within the timeframe. But I continued, using Python3.3 + PyGame, then had to stop because I emigrated, and SFML2.0+PySFML came out in the meantime, so it's time to revive the game.

The World of Nausicaä

The world of Nausicaä is an amazing post-apocalyptic world where industrial society collapsed and people reverted back to a pre-industrial living. Artifacts of the industrial era, such as flying ships, are extremely rare and impossible to reproduce. There is a massive toxic jungle that humans cannot live in because of the poisonous airs, whose insects (large and small) are taking land from the last of the human kingdoms.

Nausicaä is the princess of the Valley of the Wind, through which, as the name indicates, a constant breeze from the sea flows. The wind helps keep the spores of the toxic jungle at bay, and people there live in relative harmony, health, and peace.

If you do not know this movie/manga, it is the masterpiece of Hayao Miyazaki, of Princess Mononoke, Chihiro, Howl's Moving Castle, etc fame. It is, in my opinion, better than all of those, and I would highly recommend you see it!


The game

I am not entirely sure how I want the game to play out, but have some basic game mechanics I'd like to see in it.
  • Basic village management: how many people to assign to agriculture, to exploiting resources in the toxic jungle, to defense, building new buildings, etc
  • Explore the toxic jungle: this is where the roguelike aspect comes in. You'll get to visit or explore several places of the toxic jungle. This is dangerous, but you may find some important resources for your village, like ohmu shells, fire-demon remains, airplane engines, etc, which can greatly benefit your village. If you die, you will probably be found and taken back to the village.
  • Survival: the more you go into and the more you stay in the toxic jungle, the more the jungle is going to get angry at you. If you are not careful, insects might come to invade the valley, which reduces their rage. With the attack, some spores might be leftover, and this can be a catastrophe as you have to burn your crops. Furthermore, you have to deal with envious other nations.
  • Wind: wind is such a huge element of the movie/manga that it should feature somehow. It might increase/decrease morale according to its strength, drive the windmills that bring the water up, serve as indicator that something is wrong...

There's many more from the movie one can draw. Too much time in the toxic jungle with a basic breathing mask can result in the character becoming ill and have to recuperate. To travel to the toxic jungle perhaps you take mainly chico nuts, which take lots of resources to find, an take manpower away from the rest of the running of the village... etc. Ohmu shells could make better tools and weapons, fire-demon remains could be used to make strobe grenades to stun insects and send them back peacefully, etc.

Technicalities

Language: Python 3.3
Libraries: PySFML1.3
Repository: https://github.com/Anvilfolk/NausicaaRL

Architecture & design: Model-View-Controller'ish, component-based actors, event-based communication, data-driven (XML)

I hope to build a fairly generic and reusable engine while making this game.

The repository currently contains the PyGame version, which is going to undergo a major rewrite as I port it to component-based actors, event-based communication and PySFML.

What's currently done

There's the "old" engine with PyGame, which is mostly going away. Here's the title screen, and a video of an older version. What you can see is the hero moving around an animated landscape, with the crops growing, and then the hero opening and closing some doors.

In the meantime I implemented the equipment system, which allows creatures to have "parts" (like IVAN) and items can be equipped on some of those "parts", etc, with all this information data-driven. However, these equipped items still do not give anything to the wearer, like armour or the ability to attack.

Again, it's mostly all going away, including the organisation of the XML file, but there might be reusable tidbits. At the very least, there's a record in case anyone wants to continue the PyGame implementation. The code is also relatively commented, so it might be of some interest.

Collaboration

I feel pretty confident I can work on this for a while. I changed my life habits a few months back and where I used to drop most activities after a while, I have been active in lots of things, and actually doing them feels great.

Still, I'd love some collaboration on this project, but would like it to be "proper" collaboration, where we Skype/Hangout once a week or so at a given time and discuss progress, development, code organisation and perhaps just code while hanging out on chat. This makes development tighter, more efficient and less likely to fizz out.

I'd like to try to get the architecture mentioned above working properly, and wouldn't want someone to just go ahead and do it themselves, since I want to learn. I've been browsing Game Coding Complete for ideas on how to organise an engine, and the book has some good advice.

Ideally, not only would we come up with a game, but also a game python engine for roguelikes, and 2d games in general.

Let's see what comes out of this :)
"Get it hot! Hit it harder!!!"
 - The tutor warcry

One of They Who Are Too Busy

tuturto

  • Rogueliker
  • ***
  • Posts: 259
  • Karma: +0/-0
    • View Profile
    • pyherc
Re: NausicaäRL
« Reply #1 on: July 06, 2013, 08:04:50 PM »
Idea looks sound and you even have some code to show which is always nice. Going for Python 3.x at this point is really good move too (in my opinion, of course). Have a look at PEP-8 (http://www.python.org/dev/peps/pep-0008/) if you want to write an engine that others will want to use. Having a consistent, pythonic API is a huge boost.

I'll keep one of my eyes on your repo, but I don't think I'll be able to contribute any time soon. Best of the luck with the game though.
Everyone you will ever meet knows something you don't.
 - Bill Nye

Anvilfolk

  • Rogueliker
  • ***
  • Posts: 374
  • Karma: +0/-0
    • View Profile
Re: NausicaäRL
« Reply #2 on: July 06, 2013, 08:22:38 PM »
Thanks for the input!

I realised after posting here that I'm not sure I posted in the right location. I'll be developing this and am perfectly OK with people looking at the code and commenting on it. Is this a good place?

It also seems I am already following most of the recommendations from that proposal, which is good news.

Regarding Python 3.x, there already appears to be enough support to use it. PyGame has support for it, and now PySFML too. I think some other, more low-level libraries like pyglet are also starting to support it, but higher-level ones like cocos2d do not.

I always liked the way SFML (for C++) was organised, but got tired of writing C++ code. I feel Python 3.x + PySFML is a great solution for Python game programming - especially if you're not into moving a pixel here and a pixel there and actually want to make a *game*.

I am just now working on porting the Display routines to PySFML, but I feel like I am going to have to scrap most of the rest. The new engine is going to be radically different - and hopefully radically better. I think I will tackle the changes in this order:
- main loop as a process manager
- Event-driven communication
- Composition over inheritance
- Human view as the GUI
- The game itself, including displaying it on screen.

Thanks for the interest - it's always great motivation!

P.S. the systems that might be of interest here are the EntityManager and how it reads from the XML file. I am dynamically assigning member variables depending on what's the in XML. For instance, if you want a weapon to have a damage type and it wasn't there before, simply add <damageType>piercing</damageType> to it, and you'll be able to use weapon.damageType :) No need to explicitly declare/assign those variables in the code.
"Get it hot! Hit it harder!!!"
 - The tutor warcry

One of They Who Are Too Busy