Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Levi]

Is the A* being recalculated with every step?  If so you might be able to save some time by just calculating the path once, caching it, and then only recalculate if it encounters an obstacle.

Or maybe just calculate the routes between each destination ahead of time, then just let the ships follow those predefined paths.

[Skyrunner]

Is the A* being recalculated with every step?  If so you might be able to save some time by just calculating the path once, caching it, and then only recalculate if it encounters an obstacle.

Or maybe just calculate the routes between each destination ahead of time, then just let the ships follow those predefined paths.

No, the ships query for a route, then save it and follow the path to its conclusion.
Precalculating routes is out of the question, because what with 150 cities, there are 150*149/2 = 11175 destinations. I don't think I want to use that much memory, and also that much calculation time before each game session. :c

[Levi]

Hrm, yeah.  I guess optimization is all you can do then.

[Skyrunner]

At least the function I'm going to optimize has a 54% exclusive CPU time. Any optimization at all will effect large time benefits! It's practically low-hanging fruit. :3

[Anvilfolk]

Couldn't you develop a system where the entire world is partitioned into smaller areas, and then you do A* from area to area, and A* within each area? Something like that? That and/or using non-conservative heuristics should get you some optimisations going

[Skyrunner]

Couldn't you develop a system where the entire world is partitioned into smaller areas, and then you do A* from area to area, and A* within each area? Something like that? That and/or using non-conservative heuristics should get you some optimisations going

Low hanging fruit first :3
It's easy to change a data structure, but hard to redo the algorithm . Though HPA* would really be super effective in my case ...

[jhxmt]

So, I'm still nibbling around the edge of Python (which I've used a little bit previously).  I've moved away from libtcod and started using PyGame instead.  I've managed to get some sprites on screen from a sprite sheet, woo. 

I'm running into the (very broad) problem of how to structure my code.  I have an idea of what I want the general game flow to be like (start program, title screen, select new game, generate new game world, main game loop, call up main menu, save game, close menu, continue playing, call up main menu, load game, etc), but I'm coming unstuck over the best/most intuitive way to structure things.

I'm not entirely sure of the best way to deal with an openable/closable main menu that's available both outside of the main 'game' loop (i.e. when you first start the program) but can also be accessed from within it (i.e. by hitting Esc in-game, or whatever).  I'm wondering if I should be setting up my display engine as simply an entirely different class to my game engine, and calling it from there or wherever...and use it to distinguish between whether to display a menu, the normal game screen, the generate-a-new-world screen, etc.  But that starts to sound very complicated and spaghetti-like, and I'm wondering if there's a simple structural solution that my brain's choosing to ignore? 

Interested in how other people have structured their overall program flow!

[Levi]

Usually I've found the easiest way to go is to have a Game object that contains references to everything, such as UI, Map, item lists, etc.  Then you make sure every constructor takes a Game object, and suddenly everything is accessible from everywhere.  Does a monster need to know where to go in the dungeon?  Just use self.game.map.whatever.   

Probably not the "best practices" way, but it sure makes my life easier.

[Skyrunner]

I have a class TCODEngine that handles drawing and the game loop. It's pretty elegant because all the complex stuff is hidden in the base class, and only what I want for games is in an inherited Engine class. It also supports a game state stack. That makes handling popup windows and menus sooo smooth. You 'push' a state onto the stack, and said state has its own console which it blits to the root console. The state has all the functions Engine has. It can push other states onto the stack, or pop itself. Hard to explain until you actually try it though >_>

[jhxmt]

It also supports a game state stack. That makes handling popup windows and menus sooo smooth. You 'push' a state onto the stack, and said state has its own console which it blits to the root console. The state has all the functions Engine has. It can push other states onto the stack, or pop itself. Hard to explain until you actually try it though >_>

As a direct result of this post I have just spent the last hour and a half reading various detailed webpages about implementing game state stacks.  This is not how I had planned to use my evening...

...but it's incredibly absorbing and interesting, and exactly the type of thing I was looking for!  Thank you! 

Also interested in hearing about any other approaches to game state management people have taken.  Stacking seems ideal for my purposes, but I've also seen people using various task/process-type approaches too.

[Anvilfolk]

I recently read the relevant chapters of Gaming Coding Complete and it's led me to try to develop my own game engine in Python - which I really shouldn't be doing. Right now I'm bogged down with UI stuff, which is always a HUGE pain in the ****, but once that's done I think most systems are in place-ish, except for display stuff, which I am hoping is going to be relatively trivial.

Entity Systems (not Component-based systems), Process Managers, Event Managers, Views, etc etc etc. There's just so much! I do feel that after all of this base stuff is implemented, developing a game is going to go tons faster, and won't develop into spaghetti code. Right now I'm not entirely convinced Entity Systems are usually used for TBS games, but I think that you can get around it by having Systems that simply work as event handlers rather than real-time updater thingies.

But man, it's taken me a couple of weeks to wrap my head around this stuff

[EnigmaticHat]

So, after failing more than once to get libtcod to work (like, I've never actually gotten any scripts using it to run successfully, including scripts copied straight from the tutorial) I've switched to pygame, which is more what I want anyway.  The thing is I haven't coded anything in a while, and never in Python.  So the plan is to work on test projects I'm not attached to, until I'm confident I can make the game I want to make.

So far I've made a primitive clone of the game Snake using pygame.  Next up I'm going to try to make a basic TBS game, with a grid and stuff.

[Anvilfolk]

Nice progress for someone who hasn't used Pygame or Python!

I would suggest you look at PySFML, which is a little higher level than Pygame, and might be easier to work with

[alexandertnt]

Do we have a generalised  "Game Development" thread, or is this the de facto general game development thread?

[Anvilfolk]

A lot of the programming threads are back at Create Projects, I think. This is just an artefact that stuck...