So, I’m trying to think out a very simple game design.
Basically, it’s like a shooting gallery, although I picture it in thick fog and on a 3D plane. But the player doesn’t move, it’s fixed POV.
There are maybe 5 or so different little goblin-y things to shoot, and before playing you can check off which ones you’d like to see. Then you just kind of sit there and look at the fog and once in a while one of them passes in front of you. And you shoot it.
So my first thought, of where to start, is to go look at the 3D demo with the big blocks, and try to pull it apart to set up a ground plane.
That would work I think but I’m also thinking of it as a stepping stone project to get my feet wet with 3D environments. But the goblins can totally be 2D.
I wonder if I should continue asking for feedback on other design ideas here or if I should start a new post. I’ll try it here so as not to clutter the forum.
I’m trying to conceptualize an overall class structure for my game. Here’s my broad concepts for how my game would set up its environment.
The setup() function in the main class tells a class called Graphics to execute a function like Graphics:make3Dplace().
Inside that function in Graphics is a set of default parameters for defining a 3D space. The method packs those parameters into a table and send them over to a Data class.
The Data class takes that table and puts it inside its own set of thingsToDraw.
Back in main, when we get to draw(), draw iterates through the Data class’s thingsToDraw and draws them.
Is that a reasonable design structure? Any comments welcome.
Hi. Have you looked at the ‘mesh’ definition? If you want to do 3D, the mesh is the object to be filled. A mesh is then rendered by a single draw call. However its a bit complex to handle. If your objects are really 2d in a 3d environement, then maybe a table of images with translate, rotate, scale parameters is simpler to manage. Then in the draw you should loop over the table elements and sprite() them (in the good order: from far to near).
@Jmv38, I’d like to learn about meshes, even if they might be overkill for this project. It seems like that might be a good way to start.
I’ve done a little looking at it, but I’m not clear: does every triangular piece have its own mesh, or is the mesh what you call the whole environment?
A mesh Is an object: an object is a variable with properties and method, you access them by :
Object.xxx for properties.
Object:xxx() for methods.
The mesh has several tables properties: the .vertices is a table that define all the triangles of the mesh, by their 3 summits, so it is a table of vec3 objects. Read the doc of the mesh if you want to know more. You can also look at this thread http://www.twolivesleft.com/Codea/Talk/discussion/comment/14700#Comment_14700 where i have posted my first code with mesh as a tutorial, when i was in the beginning of my learning curve.
@Jmv38, thanks. I don’t need to go quite that basic–I understand objects and methods–but I do appreciate your taking care not to go too fast.
I think I can get my head around meshes, probably, but what throws me for a loop is all these terms like “identity matrix” and “model matrix” and “current view transform”.
There is a thread where @Andrew_stacey has put a link to a web tuto he wrote on those subjects. Anyway there is a full glass of indigest potion you’ll have to swallow if you want to master meshes (but thanks to Simeon, it’s just a glass, not a full bottle…)
Thanks both of you! This is slow going but I’m trying to get it. I think I get “model matrix” and I think I can puzzle out “current view transform” – at least, I understand what the terms refer to. I’m still in the dark about “identity matrix” though. It seems like the last thing that the in-app documentation refers to about which I have no clue.
Hi. ‘identity matrix’ is a very usual term in matrix world, this is like ‘1’ for usual calculations. When you multiply a matrix A by the ‘identity matrix’, A is kept unchanged. Usually It has 1 on its diagonal elements and 0 elsewhere.