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


  • Content count

  • Joined

  • Last visited

Community Reputation

100 Neutral

About mickd

  • Rank
  1. I would go for the first method, but with the modified class bollu suggested. Are you planning to store the stats of the weapons in a text file? or a database? or an xml file? Seems the first method would work nicely with any of those.
  2. @YogurtEmperor Not only did I find that useful, I read it when I found it on google from an old post you made! Thanks! @Postie Yep, sometimes I feel as if I just need a confirmation from others that what I'm doing is within reason. Thanks as well!
  3. Thanks for the replies! I've already change my design slightly (still feels a bit off, but it's slowly getting better). I'll definitely just keep working on it to help discover more design flaws that I can work into fixing in the next iteration of the engine. It's been a great learning experience already. Did you guys have any comments specific to storing textures? How would your draw functions in your various game entity classes access the textures? Should each class be storing a reference to it's own texture for binding and rendering? Should they be centralized in any specific way? Is it a bad idea to have a single class with static variables and functions to hold the texture files and control binding?
  4. [quote name='Postie' timestamp='1331778279' post='4922150'] I'm not sure why many of your classes would need a reference to the Key or Mouse handlers. To my mind, there should be a single part of your code concerned with handling mouse or keyboard input (somewhere in your user interface layer), which then sets gamestates or something similar to act on that input. It'll be easier to maintain if all your input is centralised somewhere. [/quote] Oh, I should have probably been more specific about this but the keyHandler and mouseHandler classes just hold a hashmap of which keys were pressed (for the keyHandler) and which location on the screen was clicked (for the mouseHandler). They don't handle the events (the JPanel uses key bindings and a mouse listener to do this), more so just store what event was triggered. Every game state would need access to these since I have to be able to processEvents in each game state. Same with each component of the screen (inventory, etc).
  5. Thanks for the replies everyone. It really does help get me thinking. The resource manager initially also had the player class in it (which I moved to the entity manager), but at the moment I have the world class, the game engine and mouse/keyboard handlers. I'll have a think how I want to redesign things to hopefully make more sense. I really don't like the way I've done things (which is why I decided to ask here), but for the time-being that was the simplest way I could think of doing it. So at the moment it does kind of include both system resources and game resources. Does this mean in general when writing a game people pass references of what each class needs as they create the class? It gets pretty messy since I feel as if so many different classes need access to so many different other classes (but that's probably a huge design flaw I currently have). Are there classes that you guys (when writing a game, simple or complex) generally have shared with the whole system? What about with texture handling? At the moment I have a texture manager which basically just holds a public static reference to the sprites atlas for binding and getting the correct texture coordinates in the sprite atlas.
  6. Thanks guys! I think that answers my first question completely! Just one follow up on markr, is tick() another way of saying update(dt)? For my purposes, I think I'll keep it as simple as possible for now, and if I do come by any problems, I'll implement a system similar to your suggestions. Also, I would love some extra input on the second question ;)
  7. I'm working on a very simple 2d tile-based game for educational purposes and have a question about how the game entities should be stored and drawn, and a question about the design of a state based game. For the first question: The simplest way seems to be just to store them in a List structure (for example, a list of Monsters) but my concerns start to arise when you potentially have a list of thousands of monsters on the map. When displaying the monsters, you would only need to draw the ones that are visible on the screen (within a set amount of tiles from the player). Would there be a better way than to iterate over the list every frame to calculate which monsters are close enough to the player to be drawn, then draw them? For the second question: I currently have a ResourceManager class which has a static reference to a KeyHandler and a MouseHandler class, amongst other things. This is currently allowing me to easily call the key and mouse handlers from any of my states, since I can just go ResourceManager.getKeyHandler(). Is this bad practice? If so, any suggestions? I've actually got a very similar thing with an EntityManager which has static calls to retrieve things like the current Player class and list of Npcs/Monsters, etc. Thanks for any input, it will be greatly appreciated.
  8. Hi guys, I've stumbled across a bug in my code. A few of my friends and i have all had a look through it, and still cant figure it out. I also posted this on the opengl official forums a while ago, but since FloatBuffer is a java implementation, i thought it might be more appropriate to post it here! Any help greatly appreciated! [b]The program:[/b] I'm creating a flame in a simple particle system. It has the ability to do the bezier calculations on the cpu or through the shader (toggle-able). Adding particles while its rendering without using the shader works perfectly. [b]The problem:[/b] When i turn on the shader, adding particles to the FloatBuffers behave unexpectedly. Say i have my current floatbuffer, which can hold 3000 floats (before it buffer overflows), and i have exactly 3000 floats in it. While not using the shader, if i increase the number of floats to 4500, my code creates a new floatbuffer that can hold double the previous one (6k floats), copies the old 3000 floats into it, and adds the new 1500 floats ontop of it. The result is i have a float buffer that can hold 6000 floats, and has 4500 in it currently. When i do the same thing when the shader is turned in, instead of adding the 1500 extra floats ontop of the 3000, it seems like its wiping the buffer clean, and adding the 1500 new floats. The result is i have a float buffer that can hold 3000 still (since it never tried to add the 3001st float, the function never creates a bigger buffer), but with only 1500 floats (the new floats i think) only. I hope that makes some sense. The weird thing is, its the exact same createParticle() code that is being called when the cpu calculated flame or the shader calculated flame is running. All attributes are bound and passed successfully into the vertex shader this time! Here's hopefully all the relevant code... The drawing code: drawParticles is called in display() [code] double lastRendered = System.currentTimeMillis(); protected void drawParticles(GL gl) { gl.glColor4f(0.7f, 0.2f, 0.1f, 0.8f); gl.glPointSize(20); if(useShader) { GPUrenderer(gl); } else { CPUrenderer(gl); } if((System.currentTimeMillis() - lastRendered) >= 30) { time += 0.03f; lastRendered = System.currentTimeMillis(); } if(time > 1) time = 0; } private void CPUrenderer(GL gl) { gl.glUseProgram(0); gl.glBegin(GL.GL_POINTS); FlameParticle particle; Vector3D particleLocation; for(int i = 0; i < particleList.size(); i++) { particle = (FlameParticle)particleList.get(i); particleLocation = particle.currPosition(time); gl.glVertex3f(particleLocation.x, particleLocation.y, particleLocation.z); } gl.glEnd(); } private void GPUrenderer(GL gl) { gl.glUseProgram(shader.getProgram()); gl.glUniform1f(gl.glGetUniformLocation(shader.getProgram(), "time"), time); // System.out.println(cp1.capacity()); cp0.rewind(); gl.glVertexPointer(3, GL.GL_FLOAT, 0, cp0); // bezier cp0 cp1.rewind(); gl.glVertexAttribPointer(BEZIER_CP1, 3, GL.GL_FLOAT, false, 0, cp1); cp2.rewind(); gl.glVertexAttribPointer(BEZIER_CP2, 3, GL.GL_FLOAT, false, 0, cp2); cp3.rewind(); gl.glVertexAttribPointer(BEZIER_CP3, 3, GL.GL_FLOAT, false, 0, cp3); startTime.rewind(); gl.glVertexAttribPointer(START_TIME, 1, GL.GL_FLOAT, false, 0, startTime); gl.glEnableClientState(GL.GL_VERTEX_ARRAY); // bezier cp0 // gl.glEnableVertexAttribArray(BEZIER_CP0); gl.glEnableVertexAttribArray(BEZIER_CP1); gl.glEnableVertexAttribArray(BEZIER_CP2); gl.glEnableVertexAttribArray(BEZIER_CP3); gl.glEnableVertexAttribArray(START_TIME); gl.glDrawArrays(GL.GL_POINTS, 0, particleList.size()); gl.glDisableClientState(GL.GL_VERTEX_ARRAY); // bezier cp0 // gl.glDisableVertexAttribArray(BEZIER_CP0); gl.glDisableVertexAttribArray(BEZIER_CP1); gl.glDisableVertexAttribArray(BEZIER_CP2); gl.glDisableVertexAttribArray(BEZIER_CP3); gl.glDisableVertexAttribArray(START_TIME); } [/code] setting up the floatbuffers initially, called in init() [code] protected FloatBuffer cp0, cp1, cp2, cp3, startTime; protected void setupBuffers() { cp0 = BufferUtil.newFloatBuffer(3 * 1000); cp1 = BufferUtil.newFloatBuffer(3 * 1000); cp2 = BufferUtil.newFloatBuffer(3 * 1000); cp3 = BufferUtil.newFloatBuffer(3 * 1000); startTime = BufferUtil.newFloatBuffer(1000); } [/code] addParticles(amount to add) called when i press + on the keyboard [code] private void addParticles(int toAdd) { int count = 0; while(count < toAdd) { createParticle(); count++; } } protected void createParticle() { FlameParticle particle = new FlameParticle(); particleList.add(particle); FloatBuffer temp; if(cp0.remaining() < 3) { System.out.println("here"); // cp0.rewind(); temp = BufferUtil.newFloatBuffer(cp0.capacity()); temp.put(cp0); temp.rewind(); cp0.rewind(); cp0 = BufferUtil.newFloatBuffer(cp0.capacity() * 2); cp0.put(temp); // cp0.position(temp.position()); } if(cp1.remaining() < 3) { // cp1.rewind(); temp = BufferUtil.newFloatBuffer(cp1.capacity()); temp.put(cp1); temp.rewind(); cp1.rewind(); cp1 = BufferUtil.newFloatBuffer(cp1.capacity() * 2); cp1.put(temp); // cp1.position(temp.position()); } if(cp2.remaining() < 3) { // cp2.rewind(); temp = BufferUtil.newFloatBuffer(cp2.capacity()); temp.put(cp2); temp.rewind(); cp2.rewind(); cp2 = BufferUtil.newFloatBuffer(cp2.capacity() * 2); cp2.put(temp); // cp2.position(temp.position()); } if(cp3.remaining() < 3) { // cp3.rewind(); temp = BufferUtil.newFloatBuffer(cp3.capacity()); temp.put(cp3); temp.rewind(); cp3.rewind(); cp3 = BufferUtil.newFloatBuffer(cp3.capacity() * 2); cp3.put(temp); // cp3.position(temp.position()); } if(startTime.remaining() < 1) { // startTime.rewind(); temp = BufferUtil.newFloatBuffer(startTime.capacity()); temp.put(startTime); temp.rewind(); startTime.rewind(); startTime = BufferUtil.newFloatBuffer(startTime.capacity() * 2); startTime.put(temp); // startTime.position(temp.position()); } // System.out.println(cp0.position()); // cp0.position((particleList.size()-1)*3); // cp1.position((particleList.size()-1)*3); // cp2.position((particleList.size()-1)*3); // cp3.position((particleList.size()-1)*3); // startTime.position(particleList.size()-1); cp0.put(particle.cp0.x); cp0.put(particle.cp0.y); cp0.put(particle.cp0.z); cp1.put(particle.cp1.x); cp1.put(particle.cp1.y); cp1.put(particle.cp1.z); cp2.put(particle.cp2.x); cp2.put(particle.cp2.y); cp2.put(particle.cp2.z); cp3.put(particle.cp3.x); cp3.put(particle.cp3.y); cp3.put(particle.cp3.z); startTime.put(particle.startTime); System.out.println(cp0.position()); System.out.println("remaining " + cp0.remaining()); System.out.println("capacity " + cp0.capacity()); } [/code] I hope that's everything relevant. To recap: when i toggle "useShader" to true, adding to FloatBuffers seems to "clear" the buffer before adding particles. When "useShader" is false, FloatBuffer's work as intended. Once again, any help would be greatly appreciated!!
  9. Hey guys, I'm using jogl2.0 b10 testing an extremely simple program that's supposed to well.. just display a square in the center. I'm not sure why, but only certain screen size ratios display the square (only if the screen height is greater than the width by a margin). If anyone could have a look for me, that would be great! import javax.media.opengl.GL2; import javax.media.opengl.GLAutoDrawable; import javax.media.opengl.GLCapabilities; import javax.media.opengl.GLEventListener; import javax.media.opengl.awt.GLCanvas; import javax.media.opengl.glu.GLU; import javax.swing.JFrame; import com.sun.opengl.util.FPSAnimator; public class Loader extends JFrame implements GLEventListener { private GLCapabilities glCaps = null; private GLCanvas glCanvas = null; private FPSAnimator animator = null; private static final long serialVersionUID = 211350059027795801L; /** * @param args */ public static void main(String[] args) { new Loader().run(); } public Loader() { super("Test"); glCaps = new GLCapabilities(null); glCaps.setDoubleBuffered(true); glCanvas = new GLCanvas(glCaps); glCanvas.addGLEventListener(this); animator = new FPSAnimator(glCanvas, 25); getContentPane().add(glCanvas); } public void run() { setSize(800, 600); setLocationRelativeTo(null); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setVisible(true); animator.start(); } @Override public void display(GLAutoDrawable drawable) { GL2 gl = drawable.getGL().getGL2(); gl.glClear(GL2.GL_COLOR_BUFFER_BIT | GL2.GL_DEPTH_BUFFER_BIT); gl.glLoadIdentity(); //gl.glTranslatef(-1.5f, 0.0f, -6.0f); gl.glBegin(GL2.GL_POLYGON); gl.glVertex3f(-0.5f, -0.5f, 0.0f); gl.glVertex3f(-0.5f, 0.5f, 0.0f); gl.glVertex3f(0.5f, 0.5f, 0.0f); gl.glVertex3f(0.5f, -0.5f, 0.0f); gl.glEnd(); gl.glFlush(); drawable.swapBuffers(); } @Override public void dispose(GLAutoDrawable arg0) { // TODO Auto-generated method stub } @Override public void init(GLAutoDrawable glad) { GL2 gl = glad.getGL().getGL2(); // set smooth shading gl.glShadeModel(GL2.GL_SMOOTH); // set clear colour to black gl.glClearColor(0.0f, 0.0f, 0.0f, 0.0f); // set the depth buffer on gl.glClearDepth(1.0f); gl.glEnable(GL2.GL_DEPTH_TEST); gl.glDepthFunc(GL2.GL_LEQUAL); // gl.glDepthRange(0.0f, 1.0f); // set perspective correction gl.glHint(GL2.GL_PERSPECTIVE_CORRECTION_HINT, GL2.GL_NICEST); } @Override public void reshape(GLAutoDrawable glad, int x, int y, int width, int height) { GL2 gl = glad.getGL().getGL2(); GLU glu = new GLU(); // prevent division by 0 on height if(height == 0) height = 1; gl.glViewport(0, 0, width, height); gl.glMatrixMode(GL2.GL_PROJECTION); gl.glLoadIdentity(); glu.gluPerspective(45.0f, width/height, 0.1f, 100.0f); gl.glMatrixMode(GL2.GL_MODELVIEW); gl.glLoadIdentity(); } }