• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Whirled Peas

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

104 Neutral

About Whirled Peas

  • Rank
    Newbie
  1. Unity

    This thread has been very informative to me. I've personally been looking to use an engine for a project of my own, and until recently I was set on using Panda3d, however I've hit a bit of a dead end with the physics engine as using either ODE, or the native Panda3d physics engine seems to be lacking in detailed documentation, doesn't like meshes other than the pre set collision meshes(spheres. boxes, capsules, etc), there also seems to be a lack of making the physics geometry visible for debug purposes which is a pain. I like just about everything else about panda but the physics has proven to be a deal breaker for me. So I've been looking for a different engine, another alternative is Blender's engine as it, like Panda3d is open source, and uses panda as the scripting language which is a strong preference for me. However Blender has the problem that I feel incredibly limited by the logic brick system that they use, I much preferred the freedom allowed by the straight up ciode setup of Panda3d. I'd be willing to go back to Blender if I absolutely had to, being as it's physics simulation and graphics capabilities seem to fit my needs the best, but like I said I don't like the logic bricks. Cost is a bit of an issue as I don't have tons of money, but if necessary I could pony up the cash on the scale of C4 or Torque. My main requirements are: [u] Deal Breakers[/u]: decent physics engine, doesn't have to be too advanced, but needs to be able to reliably handle more complex geometry than basic shapes like cubes and spheres, they don't have to be really hi poly meshes though at least mediocre particles, again nothing too fancy, I'm actually going for a retro sort of look so uber fancy particles won't be necessary, though they would be nice some post processing effects, like bump mapping and some basic lighting effects, normal mapping would be nice but not a killer, and some kind of basic shadows but again doesn't have to be too crazy Obviously cost, I can't go in with some real high end priced game engine that costs thousands of dollars per license, like I said before torque and C4 range pricing as about where I wanna go networking ability must be present [u]strong preferences [/u] python scripting as well as the possibility to fiddle with the actual engine source itself, I'd be willing to use C in stead, but really feel comfortable using python, plus i'm a bit rusty with C free licensing, like zlib or BPL, free is always better, but I'd be willing to pay a price if the engine had everything else I wanted I'm working on making a Descent/forsaken style shooter with a sandbox element involved, so any game engine which is too married to traditional FPS style gameplay is a nonstarter for me. I've been seriously considering Irrlicht and C4, obviously Irrlicht I prefer because it can use panda for scripting and is free, and I gather it can reliably and relatively easily use Bullet physics engine which is the same as blender uses and seems to be able to use user created meshes quite reliably. So what are others' thoughts? Thanks in advance
  2. ok, well I did some poking around and determined that if the width of the beam mesh is bigger it will be able to stretch further, perhaps the problem is related to hos small the geometry is, any ideas on that? thanks in advance.
  3. I've been working on this method of generating a laser beam without using particles. The idea is to use a collision ray to do all the work of collision detection and whatnot. The beam meanwhile will be a polymesh, or procedural mesh. You make it a really skinny box or cylinder and place all the geometry on one side of the mesh's pivot point. then the beam mesh is made a child of the thing that shoots the laser beam. When the fire button for the laser is pressed, it tests for a collision, if there is one it returns the collision location. Then I take the distance between the location of the laser gun and the collision location and scale the beam mesh along only the Y axis by the distance between the two points. Because the mesh was made to be exactly one unit in length, scaling it that way makes it go to exactly the length needed to get to the point of the collision and no further. So I put together a small program that implements this, and it seems to work properly, but there is a but. When getting to a distance that is further from the camera than 20 units the beam mesh "drops off". Now it still keeps scaling, but for some reason all geometry beyond 20 units drops off suddenly. there is also a strange aliasing effect on the beam. I was wondering if maybe it was some kind of culling bug, but am not sure. any thoughts?
  4. ok, well aparently for some reason when I was calling pygame.image.load directly within the sprite class to load the image file, it was causing the slowdown. In stead I am using a function which sets up the file path and loads the file for me, strangely though it uses the same statement to actually load the image. I'm not sure why it would make a major slowdown when directly using pygame.image.load as opposed to calling it indirectly through a function, anybody have any ideas? this is the function [source lang="python" #function for loading an image file def load_image1(name,colorkey = None): #determine the path for the image files to be loaded fullname = os.path.join('data', name) #try to load the specified image file try: image = pygame.image.load(fullname) #if the file is not found, show an error and exit the system except pygame.error, message: print 'Cannot load: ', fullname raise SystemExit, message #convert the image file for the screen, allow for alpha information image = image.convert_alpha() #return an image file return image
  5. Hi there, I'm new here, and somewhat of a noob to boot, so bear with me. Anyway, I have been working on a strategy game and have hit a snag with trying to optimize loading of graphics files for the game by only loading each image only once, not each time a sprite class is instantiated that uses the same image as others. So after making several different attempts, and going through a number of google searches I am at a loss. My problem is not that I cannot load the needed files only once each, the problem comes when I run the program with the code that loads the images only once, it gets massive FPS slowdowns, something like 10 FPS. Strangely enough when the program uses code which loads the image files each time a sprite is instantiated, it runs just fine. I have come here with this problem, because in my journeys, I have come across a thread in this very forum with deals with the issue of caching image files. the thread is here: http://www.gamedev.net/community/forums/topic.asp?topic_id=554090 I even used the exact same cache class in my program, yet I still get major FPS slowdowns as a result. here is an example of the cache class: class ImageCache: def __init__(self): self.images = {} def getImage(self, filename): if not self.images.has_key(filename): self.images[filename] = pygame.image.load(filename) return self.images[filename] and here is the code for the terrain tile class: #define the class for the terrain tile class Hex_Tile(pygame.sprite.Sprite): def __init__(self, EX, WY, pic): #initialize the sprite operator pygame.sprite.Sprite.__init__(self) #load the desired image file self.image = pic self.rect = self.image.get_rect() #create a surface for the tile to go on screen = pygame.display.get_surface() self.area = screen.get_rect() self.rect.center = X_Pos, Y_Pos #these set the grid coordinates of each tile which are assigned to each #instance as it is created by the map creation loop self.gridx = EX self.gridy = WY and here is the code used to place the tile instances, it just randomly chooses which kind of tile it is for each instance, the difference is only cosmetic so far, right above the loop is the creation of an instance of the cache, and the act of caching of the three needed image files: cache = ImageCache() Img1 = cache.getImage('data/hexterrain1.png') Img2 = cache.getImage('data/hexterrain2.png') Img3 = cache.getImage('data/hexterrain3.png') #this loop places all the tiles on the map randomly while X_Loop <= 10: #do one vertical column while Y_Loop <= 10: #generate a random number tile_desig = random.randint(1,3) #add the random number to the list of tile numbers #the tile number corresponds to the terrain type and the image file Terrain_num_List.append(tile_desig) Terrain_X_List.append(X_Loop) Terrain_Y_List.append(Y_Loop) #pick the image file based upon the random number generated if tile_desig == 1: Tile_Choose = Img1 elif tile_desig == 2: Tile_Choose = Img2 elif tile_desig == 3: Tile_Choose = Img3 #tell the tile where to go, due to the nature of a hexmap, the tiles #cannot simply go straight up and down or straignt left and right #so the tiles must be offset to make their edges line up X_Pos = (X_Loop * 84) + 80 if (X_Loop + 1) % 2 == 0: Y_Pos = (Y_Loop * 90) + 90 elif (X_Loop + 1) % 2 != 0: Y_Pos = ((Y_Loop + 1) * 90) - 45 #create an instance of a hex tile sprite and add it to the terrain list Terrain_List.append(Hex_Tile(X_Loop, Y_Loop, Tile_Choose)) #add the X and Y values of the current tile to the lists of coordinates TerrainX.append(X_Pos) TerrainY.append(Y_Pos) Y_Loop = Y_Loop + 1 #also due to the nature of a hex map, the vertical columns cannot all #be the same length, every other one is one tile shorter than its neighbors #as such this ensures that this happens if (X_Loop + 1) % 2 == 0 and Y_Loop == 10: Y_Loop = 11 #once we reach the end of this particular vertical column, go back #and start a new one if Y_Loop >= 10: Y_Loop = 0 #if Columntest == 0: #Columntest = 1 #elif Columntest == 1: #Columntest = 0 #move over to the left once X_Loop = X_Loop + 1 I cannot figure out why the game is slowing down so much when I institute this change, and according to others on the thread I mentioned, that caching method seems to work for them. Can anyone tell me why it won't work for me? Thanks in advance. [Edited by - Whirled Peas on May 18, 2010 11:28:44 PM]