Jump to content
  • Advertisement


Popular Content

Showing content with the highest reputation on 03/14/19 in all areas

  1. 3 points
    Once I had the basic AI working I have been doing a bit of housekeeping but much closer to finishing, I have taken my menu, sound and music code from my Frogger game and tried to make them into a generic framework I can slot into later games. At the moment the menus are pretty identical to Frogger but I can change them. The AI is also a bit better with the heuristic since last time, you can see it a bit better here: Next stop is: Put in more than 1 move lookahead improve the heuristic further En passant, castling and recognise Checkmate Once that is done it should almost be ready for first alpha release. Then I'll want to improve the looks, make it easier to recognise pieces, change the background and put in some more helper graphical indicators to better show threats to pieces.
  2. 3 points
    I usually distinguish between continuous collision detection (CCD) and continuous physics (CP). CCD is about computing the first time of impact (TOI) between two moving objects. A common approach for this is called conservative advancement (CA) which was initially introduced in the PhD by Brian Mirtich (s. link below). Erin Catto introduced an improvement which addresses some problems of classic CA in the talk you mentioned above. The integration into a physic engine is what I call CP. Many different approaches exist for this. E.g. some people use an additional inner sphere collider which prevents object falling out of the world. Another popular approach is called speculative contacts (s. links below). The most comprehensive approach which goes along with your description is actually found in Box2D. This is the most generic CP that is publicly available which can handle fast static vs dynamic and dynamic vs dynamic collisions. I recommend having a look there (s. link below). This is your best learning resource! I agree with your observation. A lot of the common knowledge of both CCD and CP is proprietary. This is not surprising since these are among the hardest problems I know. The common approach is not to implement some general solution, but something specific to your game. E.g. do you maybe only need some simple tunneling prevention. Hopefully the resources below will provide useful. Brian Mirtich PhD: https://people.eecs.berkeley.edu/~jfc/mirtich/thesis/mirtichThesis.pdf Speculative contacts: https://wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/ http://twvideo01.ubm-us.net/o1/vault/gdc2012/slides/Programming Track/Vincent_ROBERT_Track_ADifferentApproach.pdf Box2D continuous physics starts here: https://github.com/erincatto/Box2D/blob/master/Box2D/Dynamics/b2World.cpp#L943
  3. 2 points
    What people think is beyond your control. What you say about your game is entirely in your control. Educational games don't "have to" be boring.
  4. 2 points
    Godot 3.1 has been released with a number of features and fixes from a year of contributions. Major changes include: OpenGL ES 2.0 renderer Optional typing in GDScript Revamped inspector Revamped 2D editor New TileSet editor Revamped filesystem dock KinematicBody2D (and 3D) improvements Revamped animation editor Revamped AnimationTree New axis handling system Visual shader editor 2D skeletons 2D meshes Improved 3D editor 3D softbody support Ragdolls and Skeleton IK Constructive Solid Geometry (CSG) OpenSimplex and NoiseTexture CPU-based particle system Greatly improved C# support Networking improvements Custom classes registration MIDI and microphone input More VCS friendliness Check out the full announcement here. View full story
  5. 1 point
    Yes. What you say about your game is in your control.
  6. 1 point
    This vacation week was nice for me. Gained some knowledge from the community so tonight I'm giving back. When I'm playing with my toy 3D frameworks, I like to have mesh data in an easy to read format. When I load, all I want to see are two integers at the start for how many vertices to read and how many face indices tightly follow, and do the bulk read. Easy fast data in engine side. Generating that data I use Blender as my modeler of choice and this export file format has worked well. I'd like to share my custom export script supporting vertex position, texture coordinates and face indices as an export add-on. It's a nice jumping off point for your own custom export requirements. Currently it's sensitive to the object mode selection, triangulates mesh data, flips or not the v texture coordinate and writes optionally a binary or ascii format mesh file with a .geo file extension.. Use as you wish. bl_info = { "name": "Geo Format Exporter", "description": "Writes geometry format to disk", "author": "Mark Kughler (GoliathForgeOnline)", "version": (1, 0), "blender": (2, 79, 0), "location": "File > Export > GEO", "warning": "", "wiki_url": "", "tracker_url": "", "support": 'COMMUNITY', "category": "Import-Export" } import bpy import bmesh import struct #https://docs.python.org/3/library/struct.html from bpy import context def triangulateObject(obj): me = obj.data bm = bmesh.new() bm.from_mesh(me) bmesh.ops.triangulate(bm, faces=bm.faces[:], quad_method=0, ngon_method=0) bm.to_mesh(me) bm.free() def writeObject(self, context): ob = context.object uv_layer = ob.data.uv_layers.active.data vertBuff = [] uvBuff = [] faceBuff = [] #rebuild vertex, uv and face indices excluding duplicates for poly in ob.data.polygons: for index in poly.loop_indices: thisVertex = ob.data.vertices[ob.data.loops[index].vertex_index].co thisUV = uv_layer[index].uv #check if already in the list i = 0 found = 0 for v in vertBuff: if(abs(v.x-thisVertex.x) <= max(1e-09 * max(abs(v.x), abs(thisVertex.x)), 0.0)): if(abs(v.y-thisVertex.y) <= max(1e-09 * max(abs(v.y), abs(thisVertex.y)), 0.0)): if(abs(v.z-thisVertex.z) <= max(1e-09 * max(abs(v.z), abs(thisVertex.z)), 0.0)): if(abs(uvBuff[i].x-thisUV.x) <= max(1e-09 * max(abs(uvBuff[i].x), abs(thisUV.x)), 0.0)): if(abs(uvBuff[i].y-thisUV.y) <= max(1e-09 * max(abs(uvBuff[i].y), abs(thisUV.y)), 0.0)): faceBuff.append(int(i)) found = 1 break i+=1 #otherwise stash a new vertex if(found==0): faceBuff.append(len(vertBuff)) #index vertBuff.append(thisVertex) #float, float, float uvBuff.append(thisUV) #float, float #write to file if(self.format == "OPT_A"): with open(self.filepath, 'w') as ofile: ofile.write("%d " % len(vertBuff)) #num unique vertex/uv pairs ofile.write("%d " % len(faceBuff)) #num indices for v in vertBuff: ofile.write("%f %f %f " % v[:]) for t in uvBuff: ofile.write("%f %f " % t[:]) for p in faceBuff: ofile.write("%d " % p) ofile.close() return {'FINISHED'} else: with open(self.filepath, 'wb') as ofile: ofile.write(struct.pack('H', len(vertBuff))) ofile.write(struct.pack('H', len(faceBuff))) for v in vertBuff: ofile.write(struct.pack('3f', v.x, v.y, v.z)) #v[:])) #"%f %f %f " % v[:]) for t in uvBuff: ofile.write(struct.pack('2f', t.x, t.y)) #t[:])) #"%f %f " % t[:]) for p in faceBuff: ofile.write(struct.pack('H', p)) #"%d " % p) ofile.close() return {'FINISHED'} class ObjectExport(bpy.types.Operator): """My object export script""" bl_idname = "object.export_geo" bl_label = "Geo Format Export" bl_options = {'REGISTER', 'UNDO'} filename_ext = ".geo" total = bpy.props.IntProperty(name="Steps", default=2, min=1, max=100) filter_glob = bpy.props.StringProperty(default="*.geo", options={'HIDDEN'}, maxlen=255) use_setting = bpy.props.BoolProperty(name="Selected only", description="Export selected mesh items only", default=True) use_triangulate = bpy.props.BoolProperty(name="Triangulate", description="Triangulate object", default=True) format = bpy.props.EnumProperty(name="Format", description="Choose between two items", items=(('OPT_A', "ASCII ", "Text file format"), ('OPT_B', "Binary", "Binary file format")), default='OPT_A') filepath = bpy.props.StringProperty(subtype='FILE_PATH') def execute(self, context): if(context.active_object.mode == 'EDIT'): bpy.ops.object.mode_set(mode='OBJECT') if(self.use_triangulate): triangulateObject(context.active_object) writeObject(self, context); return {'FINISHED'} def invoke(self, context, event): context.window_manager.fileselect_add(self) return {'RUNNING_MODAL'} # Add trigger into a dynamic menu def menu_func_export(self, context): self.layout.operator(ObjectExport.bl_idname, text="Geometry Export (.geo)") def register(): bpy.utils.register_class(ObjectExport) bpy.types.INFO_MT_file_export.append(menu_func_export) def unregister(): bpy.utils.unregister_class(ObjectExport) bpy.types.INFO_MT_file_export.remove(menu_func_export) if __name__ == "__main__": register()
  7. 1 point
    Thank you so much! :D
  8. 1 point
    Esenthel Engine http://esenthel.com/ a high-performance cross-platform game engine is now Free. Grab the source code here: https://github.com/Esenthel/EsenthelEngine Enjoy!
  9. 1 point
    Okay my friend. The pain is unbearable, it hurts to the core that we are a four page discussion and as a norm, very little content. What this needs is a kick in the, right direction. Are you getting a feel for what my impression is tending? I thank you for your trust and yes, I did look at your new code. A little disappointing. We fell back to an earlier exercise that should not have been applied here instead of following a natural progression of new ideas. Please don't ever Sleep() again. And I think since we're a .net application, we let the system handle invalidation. Someone please correct me if I'm wrong. Please. Let's take a break for a moment and try something different. Forget about code. I'm going to pretend to be the one looking for input on well, my problem. My problem is similar to yours but I don't know what your exact problem is. What I want to do is shoot a bullet at my bug and when the bullet hits, display a collision image (on top of and or instead), wait for a time period (and or allow a sequence to run) and then clean up(deactivate). A fairly simple idea right. All of this happening as a simulation, so we have to imagine our solutions tracking points(game state) in time. What we do is organize ourselves so that we can make common tasks logically grouped. All game related tasks that have some dynamic purpose is dealing with a timer. I feel it was also a mistake to dismiss the advise of @Daniel Ricci someone who has clearly been deeper behind the scenes. I think we're past the point of evaluating the technology and dumping our test code into the overload. I think it's time to actually think about what you want to build, start grouping your ideas into similar tasks. Think on how the heartbeat of your game will be. How often do I want to make changes to my world? And what ever I choose, will it run the same on my friends computer? Chances are low unless you understand time(fixed time step). well, now I'm tired. I'm sorry I didn't litter my words with url links to relevant writings, but I did try to give you google keywords inside (curve brackets) in a lot of cases. Yes your code is cleaner. That's a plus. I urge practicing using this tick callback scheme to see what you come up with... no more calling Sleep()
  10. -3 points
    In other words, no, you have no actual experience making a game, you just like talking about it a lot. No shame in that. Just don't expect to be taking seriously when you use terms like "already implemented functionality". Or perhaps in your endless wisdom you could kindly explain how one would use unimplemented functionality? Would it be possible to use already unimplemented functionality?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!