Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Anvilfolk

Pages: 1 [2] 3 4 ... 25
16
Other Announcements / Re: Roguelike Bundle
« on: July 29, 2013, 06:38:34 PM »
I like the idea of side-bundles, we can definitely work on those! The points I made would then be applicable to the main bundle. A shortish list of games, mostly with graphics or graphical versions, and some challenges for those.

Should we begin by choosing a list of those that should be included and go from there?

17
Traditional Roguelikes (Turn Based) / Re: Pugnacious Wizards 2
« on: July 29, 2013, 06:34:35 PM »
Fair enough :)

Also, that they already have the GUI/Event system handled for you is a big plus! Developing one is giving me headaches :)

18
Traditional Roguelikes (Turn Based) / Re: Pugnacious Wizards 2
« on: July 28, 2013, 10:32:58 PM »
Any particular reason you are using Flash do develop this? :)

19
Other Announcements / Re: Roguelike Bundle
« on: July 28, 2013, 05:50:26 PM »
Is this a one time or permanent thing?

Here's a few thoughts: This should mostly be about bringing new people to the genre. Therefore, I feel graphics are a big must. People will not know what an @ is, let alone a "d" or a "g". I am not too current on the modern RL scene, but Crawl, IVAN, DoomRL all have nice graphical interfaces. At least Crawl and DoomRL also allow the progression to pure ASCII, which could also be a point for the bundle: start with graphical stuff, and slowly built up to being able to play ASCII roguelikes. So it might be interesting to have a PDF with tutorials/challenges. It would give people a progression to go through, which might be interesting. For example, start with DoomRL, get to dungeon level 3 at least. Then move on to Crawl, and get to the orc mines with a minotaur berserker. Then make it with any other combination. Then IVAN and get out of the first dungeon... etc. It gives people attainable objectives, which is good until they get a good feel and liking for the gameplay itself!

I also feel that less is better here. I mean that maybe about 4-6 roguelikes would be more than enough. If we give people an assortment of 20 RL, we'll be able to put up less extra content for it, and people will think there's too much in there for them to try, or that they are too crappy. I get that feeling with some of the bundles with more extravagant numbers... sad thing is, according to metacritic, this feeling hasn't been entirely unjustified for those bundles ;) But I digress!

DRM free is also a big thing for a lot of bundles, and people seem to like its possibility. It's fine to have a Steam for roguelikes, but very often I hear people complaining about having "yet another distribution platform". A .torrent and a program sounds perfect :)


20
Programming / Re: Persistent world? Yes or no?
« on: July 28, 2013, 03:47:49 PM »
Should be relatively trivial to change behaviour, so just allow it at first.

If the world is large enough, perhaps you could have the next character be far enough away that it doesn't make a difference?

21
Programming / Re: Nausicaa Engine
« on: July 27, 2013, 11:14:23 PM »
Where does the query code and modification code reside, and how does the UI have access to it? It's definitely logic code. I assume we can put it in a System, even if it's not the "usual" kind that runs every step. Does the application/GUI layer know about the System being used? I guess what I'm saying is that I somewhat dislike that the application layer is so aware of the game's internals :)

I wonder if there is some nice halfway solution, where the application layer is a bit more decoupled from the game logic itself, but you keep this querying, which is definitely less involved than a bajillion events going all over the place for the smallest action...



Ooooh, using a plain dict would actually be really lightweight and cool! Do you have any particular opinion on the relative merits of Entity Systems over just Component-based Entities (which allow game logic within components/entities)? I feel those would be better adapted to games that aren't real-time. At least the class-based design may accommodates both?

I think I'm trying to be a little bit too overly general :(



Also, if you don't mind me asking - where and how did you learn all of these these things? You seem to have very clear ideas on most of these issues, which is great :)

22
Programming / Re: Nausicaa Engine
« on: July 27, 2013, 05:55:57 PM »
Thanks!

This is exactly the kind of discussion I was hoping to get. What you say makes perfect sense, though I'm thinking of a corner case between game events and gameplay events. I'm going to go through the execution flow of equipping an item, which should help me get a clearer idea of how this is going to work, and whether events make sense here.

  • Press "e" key for equipment.
  • Go through the GUI elements in postfix ordering. None of the sidepanels (health bar, message box, etc) capture this, but the game display GUIPanel does (This panel will also capture arrow keys and convert them into movement commands).
  • The game display GUIPanel accesses the HumanView and creates a new equipment screen, based on the Hero's inventory and equipment components.
  • The GUI would then send an EquipEvent with all required data, and an EquippingSystem would receive it and do its magic. Also, the message box GUI element would also receive this event and write out a message saying you are equipping said item.

How would you implement this without events? I feel you'd need to have the GUI equipment screen explicitly keep track of the equipment system and of the message box, or have game logic within the GUI. On the other hand, what happens if you try to equip something that's too heavy? You send the EquipEvent, but then that's supposed to fail... should the EquippingSystem abort the event? Should there be EquipSucess or EquipFail events? On EquipSuccess, it might make sense for an EquipBonusSystem to update armour values, etc etc in some other component?

I'm also aware that I might be trying to fit a cube into a round hole here, and that roguelikes don't make a lot of sense in this case...


Also, what do you mean about using classes for components/entities being unpythonic? How else would you do it?


Right now I'm struggling with the usual trying to make everything ultra customisable through XML files, which is bogging me down. I'm going to forget about that for a little while and hardcode a few things, and once I realise how stuff is actually going to run, I'll try to make it customisable :)

23
Programming / Re: 16-Bit Fantasy sprite set
« on: July 27, 2013, 05:31:11 PM »
Wow, these are really neat! Thanks for sharing! :)

24
Programming / Re: Nausicaa Engine
« on: July 27, 2013, 08:12:13 AM »
Thanks for the input (hah, no pun intended)! That actually makes a lot of sense. I think as far as my HumanView and GUI is going to be concerned, input is still going to be input events - not game events. So I'll be clicking places, opening screens, and the main screen will eventually capture (e), open the inventory screen and so forth. What the inventory screen is going to do is simply launch an EquipEvent, which an EquipmentSystem will consume.

I think this could probably work!

I'm still not entirely sure I agree that drag'n'drop are game events. I feel they are still GUI events, but the problem is that upon a mouse-down, you need to check whether it's actually mouseDown or a mouseDrag event... so I might need to wait, say, 0.25s until I send the mouse-down event. If in the meantime the button has not been released, then I start a mouseDrag event?

25
Incubator / Re: Spanner in the Works
« on: July 27, 2013, 08:05:59 AM »
Looked interesting!

Making a ship as a ton of potential, but somehow the way the builder works is pretty counter-intuitive :( I was expecting it to be 2d, but it started piling tiles upon tiles, so despite my best efforts I got a little frustrated and made a blob ship by wiggling my mouse around a little with every component :(

It starts piling up tiles on top of one another, and right-clicking (to remove the tile) actually opens a right-click menu, so it makes it really hard to remove tiles that were placed by mistake :(

It's definitely up to a great start, and I'm looking forward to seeing where it goes from here :)

26
Programming / Nausicaa Engine
« on: July 26, 2013, 01:42:32 PM »
There seem to be some really competent devs around here, so I thought I'd use this as a place to get feedback, bounce ideas and generally talk about game engine development.

I'm currently developing an engine that I hope will be useful for most types of 2d games. I'll be using it for a few proofs of concept games, and for NausicaaRL, a roguelike based on Hayao Miyazaki's masterpiece.

I'm using Python 3.3 and PySFML 1.3, based on SFML2. The github repository is at
https://github.com/Anvilfolk/NausicaaRL

The main concepts I am adhering to while programming this are:
- Seperation of logic and rendering
- Event-driven communication
- Entity system implementation
- Process management rather than "update(); render(); input()" loop

To be honest, I have read about so many different concepts that my mix'n'match might not make sense a ton of sense at the moment. Either way, here's some base modules and explanations.
  • Entities.py: contains Entities as aggregation of Components, and Components as data only. Systems are also here, and they track which entities have which components so that they can act on their data. There are two concerns here:
    • Many entity systems contain a RenderableComponent inside an Entity, which I dislike since it means that the game logic is including some visual information. It would be hacky to then make a dedicated server that did not need to have any rendering information whatsoever. Therefore, there will be no renderable components. Rather, whenever a component is created, an Event will be called, and the visual representation of the game, if any, will be responsible for figuring out how to display it.
    • Entity systems are typically used for real-time games. In a roguelike, you essentially have an event-driven system. I am thinking that the engine will have systems that can run in real time (they process all relevant entities every "frame"), and systems that simply work as event listeners to handle different things.
    There is also a World class that will contain the entities, and manage systems, entities, components, etc.
  • Processes.py: Process and ProcessManager. A process is something that needs to execute over several frames, like animations, particle systems, AI, etc. It's fairly simple stuff. It runs, and sometimes it can be aborted, stopped, it ends, starts, pauses, etc.
  • Events.py: there will be a singleton EventManager for ease of access, but many important classes, like a World, a Game, etc will subclass EventManager to allow local, more efficient communication. Events are currently dispatched according to their class. I am hoping that having lots of more localised EventManagers will make this simple system fast and robust enough, as there won't be lots of listeners that get irrelevant events.
  • Game.py: manages GameStates. I am currently unsure whether this should be tied to the graphical representation or not. I feel a dedicated server will simply host the game itself, and not other states. This would essentially be a scene manager, for the main menu, game, score menu, etc. As such, I am thinking that the HumanView, the graphical representation of the game, will contain a GameManager, and each GameState will contain a GUIPane on which contents will be rendered.
  • HumanView.py: Views are intended to be anything that receives events and presents a view of the game to anything. In this case the HumanView presents it to the user, so it manages the Window, GUI, etc. A RemoteView will likely receive all important events in the game world and send them to remote clients. It does not need to worry about visuals at all.
  • nGUI.py: the GUI system, oh god, the GUI System. How much I hate this. It's so annoying to implement. Everything is either a NGUIBase or an NGUIPane (which extends NGUIBase). Panes may have more content. Everything has several properties that can be checked, like whether the mouse is within its bounds (independently of whether there is another element in front), and whether it has mouse focus, i.e. whether the mouse is on top of this, and nothing else "above it" is capturing it". NGUIBasicButtons, and most buttons in general, will also have a "primed" state, where the mouse has been clicked but not released. Upon losing focus, they also lose primeness. Everything is managed through its own EventSystem... I should perhaps integrate it, though right now the system is fairly intuitive. You can add listeners to every GUI component, and if certain methods exist, they will be called when appropriate (onMouseFocus, onMouseDefocus, onMouseDown, onMouseUp, etc).
  • TextManager, ResourceManager, Utility
can be used to load resources such as text, data, fonts and textures to be rendered.
[/list]

There's lots of tidbits that still need to be tested and implemented all across the board, and in particular in the rendering, GUI and input parts. I feel it's getting closer to be usable as a game system, and I'm hoping to be able to implement a very basic game soon to make sure the engine actually makes things easier to implement.

I am still relatively unclear on how to handle input, both mouse and keyboard, however.  My current system is that whenever a key gets pressed, it is converted into a GameEvent that contains all types of actions it may represent. For instance, pressing "e" can mean either "open equipment screen" or "select item (e)", or lots of other things. The problem is that this interpretation is global, so the GameEvent with the open equipment screen and select item (e) gets propagated everywhere, which doesn't make a lot of sense. I am thinking that each GUI element should have its own way to convert keypresses.

But what about mouse stuff? Do I make every sprite a "button" and add listeners to everything for selection? What about drag'n'drop? What about drag'n'drop between two GUI elements? These things still have me a little baffled.

Anyway, I just hope this will spark some interesting discussion like the one in the rendering question thread :)

In particular, I am not entirely convinced that the entity system for a game as complex as roguelikes will make components as decoupled as they were meant to be... and might actually make things harder, as you try to send off events and counter-events (that might or might not happen depending on what components exist in an entity) and stuff instead of just calling a function! Besides, it seems like we're always going to be explicitly asking whether components exist, which kind of beats the point :\

27
Other Announcements / Re: Losing interest in roguelikes
« on: July 25, 2013, 12:40:46 AM »
Desktop Dungeons is also nice - definitely more of a puzzle game, but everything is easy to understand, it has some nice stuff that you can unlock and you feel like you are progressing as you win with more races in more places and unlock new stuff.

I've also never reached any of those epic mythical things, but I do still enjoy a bout of Crawl every now and then :)

28
Programming / Re: What's the best simple graphics library for C++?
« on: July 24, 2013, 11:23:22 PM »
That made me laugh out loud :D

29
Programming / Re: What's the best simple graphics library for C++?
« on: July 24, 2013, 03:32:28 PM »
I hadn't realised SDL2 was also about to come out and with hardware support and all that, but SDL just felt a lot more low-level than SFML ever did. It required lots of extra libraries to do stuff like rotations and so forth. I am sure SDL 2.0 is better, but I do really like SFML's API. I'm currently using PySFML. I have a major gripe in that it doesn't support drawing a line, which is annoying, but maybe SFML does?


30
Programming / Re: Races and roles
« on: July 23, 2013, 10:34:09 PM »
Point taken :)

I guess another example is european swordfighting and japanese swordfighting, two styles of melee combat. It's still unclear to me whether this involves genetics or not though - are Japanese or Europeans more physically adapted to their style of swordfighting? Can we claim that a couple of dozens of generations of natural selection through warfare are enough to ensure an entire population becomes better at that type of fighting?

If not, then it simply comes down to culture and preference. In that case there's no reason to have inherent aptitudes or ineptitudes. You would simply use what is available, and therefore become proficient at that. Which leads us back to the notion that everyone starts the same, and you simply level things that you use, without regard to innate abilities.

Anyway, from a gameplay perspective I feel it makes sense to have some choice determining aptitudes towards certain skills. Conceptually, I feel race explains this better than a faction or a "class", which just an arbitrary restriction. Ultimately, what matters it the gameplay though, so the explanation is sort of moot :)

Pages: 1 [2] 3 4 ... 25