Messages

46

Programming / Re: "Game state"-based game loop.

« on: July 11, 2013, 01:46:33 AM »

I'm going to go ahead and recommend you try Game Coding Complete 4th Ed. again. I've been interested in these issues for a while, and had a system working already, but after reading it decided for an almost complete rewrite, which I'm doing at the moment.

I've already written about it elsewhere, but their system is pretty flexible, and you really only need to read a few of the first chapters to get the gist of how to organise an engine in a very flexible way. It includes the events discussion that has been part of this thread, as well as organisation of the main loop in a generic and, again, flexible way, composition instead of inheritance, and GUIs and stuff in there as well.

There's so much stuff around that at some point you're just going to have to make a decision and live with it. Eventually perhaps do a rewrite, refactor, or whatever you want to call it. Perhaps just a new iteration of the engine

47

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 10, 2013, 01:19:16 AM »

Perhaps if you did a quick tech demo, using the materials that you can already put into the editor, people would see what can actually happen, and that might open their imagination.

It's actually kind of ironic, usually the trouble is finding programmers, not idea people

48

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 09, 2013, 08:42:41 PM »

Let's take it to PM

49

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 09, 2013, 07:59:53 PM »

I think I'm slowly getting a better hang of what you're trying to do with the game

Esoteric things? That is something I'm quite familiar with... what kind of stuff you're curious about?

Oh, you know... the usual... I love blacksmithing, WW2, in particular aviation (IL2 Sturmovik anyone?), napoleonic naval warfare, historical reenactment, parkour... all of which read about intensively and practice or am starting to practice. I'd love to get a pilot's license and a sailor's license. One day, when I'm rich



I also agree with miki's advice. I keep reducing features for my games... even right now I feel like I'm biting off more than I can chew, and I have tons less than what you do! In particular, I feel there's a huge difference between having the data, and actually using it. I just started reading about how a game engine should be organised, and it's absolutely not trivial. There's definitely a ton to it than getting and setting properties, which is what I was doing previously with my inheritance-based OOP design

50

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 09, 2013, 03:27:06 PM »

I really envy those persons who have the luxury if finding someone sharing the same interests and that build something together. Most people wish they could be rich. Me? Just wish I could find someone sharing my interests and enthusiasm.

Long ago I made some table games with some friends but we all moved in different directions and I got alone. I sacrifice most of my spare time to devote myself to this project and sometimes I really wonder if all this is really worthy. But then I keep pushing forward. We have this saying in Portugal: "One will not get tired by running if running is his passion".

What?! Mais um Português? Catano, nós estamos por todo o lado!

Sorry guys - just found out this here fellow is my compatriot, haha! Also, I feel for you... that first paragraph pretty much describes me. Turns out I get interested in the most esoteric things and it's almost impossible to find someone to share them with in person...


I think the idea for this game is more like the old game series Lords of Doomdark, or whatever the name was. It's on a more macro level than roguelikes. Instead of manually going around a dungeon, you could simply enter something like a province, and tell your hero to explore. Your hero might find and automatically explore a dungeon, and come back with loot and/or wounds. You won't get to manually fight the monsters. So, more strategy, less tactics? Correct me if I am wrong.



I also think I became confused with your answer to my previous post. I understand that in the editor you can define items, materials, nutrients, races, and that kind of stuff. The game itself uses these. So if you want to go adventuring, like you yourself said, you'll need to prepare and get food with a nice nutrient distribution for your race, etc. This seems a bit like overdoing it - too much to worry about before going on an adventure. A true real-life simulator is probably just as boring as real-life can be Don't you feel you might be going a bit too far in that regard?



Also, out of curiosity, what are you using to program this? Also, where in Portugal are you from?

51

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 08, 2013, 11:12:38 PM »

This seems more like an "everything simulator" than an actual game. At some point if you have to prepare for hours and hours just so you have enough to go on an adventure, it won't be much of a game. It might have this feeling of epicness if you manage to do something, but honestly it might be a little too complex to be enjoyed.

Don't get me wrong, I *love* sandboxes, but they need to allow me to do something meaningful without having to play for 10h just to get ready for my first adventure. I feel you will restrict your playerbase to the most hardcore of players, which is fine if that's what you want

I'll also point out that that feature list is pretty extensive, and comparable to Dwarf Fortress'... DF came out in 2006 and has been in full-time development for quite a few years since then. People will naturally be unconvinced about the feasibility of all this, from a developer with no previous track record Please don't take this the wrong way, it's just the natural way of things for someone without a track record

I've been trying to make a game for quite a few years now, and the feature list of things that I want to put in has been decreasing rather than increasing as I realise how much commitment and work getting everything to work takes

Also, is perma-death going to be an option? I assume not, since it seems like a huge level of involvement for enormous amounts of risk. Even without perma-death, and with saving, if there's so much involved in just staying alive (with all the nutrients, etc), there's the possibility of you getting yourself in an situation where you are going to starve no matter what.

52

Programming / Re: Cavern generation code

« on: July 08, 2013, 04:57:33 PM »

A quick idea would be to generate several intersecting circles of different diameters, and then adding and removing some of the outlying water tiles so it's not obviously just circles. Alternatively, start with circles of large diameters, then add circles of smaller diameters. This might give you something like lake shapes

53

Programming / Re: Recruiting game designers for a different kind of roguelike game.

« on: July 08, 2013, 04:56:20 PM »

Hey!

I saw your post on the DF forums as well.

I think the main problem with the way you are approaching this is that you are presenting this project mainly as a technical one. Look at the opening of the post: you have a list of what I assume are data definition files that need to be done. That's not going to attract a lot of people!

Right now the game appears to be a collection of technical possibilities, but no more. It's hard to get a idea of how the game is going to play out, of what the player is supposed to do, of what his goals might be. Furthermore, you don't appear to have a lot to show for it, so that it looks like it's mostly an ideas thing rather than an actual thing where a "designer" can get involved.

Some screenshots or videos would do wonders, I think

54

Programming / Re: Separating render and logic

« on: July 08, 2013, 01:18:01 AM »

This issue goes beyond RL development, and can actually be discussed at the level of game development in general.

I've been interested in gamedev for a while and have read quite a bit, but it turns out that most tutorials and books out there will essentially teach you an API, but never really tell you how your code should be organised. It's like all that matters is that you can render things.

Fortunately, I came across a review of a book that said the book was more about how to organise code than how to render specific things. I've been reading through it and it led me to completely rework the RL I'm currently developing.

The book is called Game Coding Complete (4th ed.), and I can heartily recommend it if you already have some programming experience. It's for C++ and DirectX, whereas I want Python and SFML, but it is entirely possible to ignore the technical aspects and focus on the organisational ones.

They essentially espouse the MVC pattern (model-view-controller), where the model is the game itself (no graphics involved), the view can the the user-interface/rendering for the human, or a network interface for a remote player, or for an AI, and the controller deals with inputs (for the player) and possibly AI decisions.

I highly recommend you just find the book somewhere and give a read to chapters 1-3,5-7,10,11, but the two main things related to your question are the following:

Have an EventManager. The model is doing its own thing, with time passing, actors moving, etc etc. Whenever anything of interest happens, send the EventManager an Event reporting it. If an actor moved, if an actor was created, if an attack occurred, etc etc etc. The EventManager is going to distribute these events to whoever is interested in them. Your game classes tell the EventManager what events they are interested in, and what function to call back once an Event is triggered.

For example, your rendering system is attached to the player's View. The View is interested in all events of the type Move (which it uses to update the locations of its sprites), of type Create (so it can add another visual representation for the object), of type Attack (so it can write "you do 5 damage") to the screen, etc etc.


For animations, you're likely to need something else, which changes the main loop. The authors of the book suggest using a ProcessManager, for anything that takes more than one "frame" or update to process. This can include things like AI routines that stop executing after a little bit so they don't hog a processor, or animations. Suppose an actor throws a grenade and it explodes. The model will deal damage to everything within a given radius, and then will generate an Explosion event. The Human View (which previously registered for Explosion events) will receive the event, and create a new Process whose sole purpose is to draw an explosion animation at the given location (by choosing frame after frame after frame as time passes). Once the explosion is complete, the process kills itself off.


So that's how the authors do it... at least in my interpretation of what they explained, but to be honest I did more of a quick perusal than a deep study, so I might be wrong. But conceptually this seems to make a lot of sense, and to be generalisable to many gamedev scenarios.

Hope this helps!

55

Incubator / Re: NausicaäRL

« 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.

56

Other Announcements / Re: Why I Dislike Addictive Games

« on: July 05, 2013, 09:33:07 PM »

This is one of the reasons I've mostly stopped playing certain genres offline. I force myself not to play certain games. Some I know are going to suck me in for hours on end... and get me a meaningless piece of loot.

Sharing the experience online, especially with VOIP, makes these experience social though. And social activities are, to me, a good thing. I do not feel I have wasted away time if I'm bonding with someone else over that activity.

For offline, the game has to offer some challenge, or some form of "content". Strategy games, turn-based or RTS, with significant difficulty, make you think constantly and outdo yourself. That's another activity I consider worthwhile. Others train your reflexes... Certain grognard games have historical content that makes you realise what a lot of people went through in this or that war, so that's another reason I'd play offline.

RPGs typically have little of this, if played offline. Click click click click clickityclick. Minecraft and Terraria, or world-building games in general, give you an open world to exercise creativity, and that's OK offline, but definitely better when bonding over it with friends.

Nice to see someone who feels the same way about modern games!

57

Incubator / 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

58

Programming / Re: Puzzles in a randomly generated dungeon

« on: October 26, 2009, 09:43:28 AM »

I'd like to see someone make an algorithm to do that on a regular game of Crawl 

59

Programming / Re: Damage displays

« on: October 26, 2009, 09:42:47 AM »

DCSS currently has the system Brigand said he'd use for his game. Essentially, it just shows you a colour code for the health of the enemy. I kind of like the system... it gives you an idea, without you getting full knowledge.

60

Traditional Roguelikes (Turn Based) / Re: Interhack 2.1.22 released

« on: October 26, 2009, 09:35:31 AM »

Windows and *NIX systems store the "enter key" differently. *NIX just puts a LineFeed special character, while Windows uses Carriage Return + Line Feed. Notepad is only able to interpret CRLF, and not just LF, unlike WordPad. I'm guessing interhack was programmed under linux or somesuch - it's pretty usual