Jump to content

Game week - development of Lenga

AggrorJorn

1,293 views

So now that game week is over lets have a look back at how things went.

 

Game play

Gameplay itself was done really quickly. The idea for Lenga is basically Jenga with a twist of colors. I thought of creating an AI that would remove blocks based on a calculation. However I though it would become really boring. So instead I let the player remove a block of a specific color.

 

Scripts on the wrong entity

At some point during testing I came across a script error. I lost a good hour trying to figure out what I was doing wrong in my script, but as it turned out it was something else: a lua script was somehow attached to a different entity even though I never attached a script to that object. It did turn out that I am not the only one experiencing this.

http://www.leadwerks.com/werkspace/topic/7275-script-properties-showing-different-script-properties/

 

Lua script editor

A very annoying thing about the Leadwerks 3 script editor is that every new line starts without any indenting or tabs. This is really frustrating. Whether you enter for a new line or when you want to move your function one line lower. It breaks the flow and you are wasting a lot of time making sure that every line is aligned correctly.

 

Physics

The performance of the physics is just bad. There is not much else I can say about it. The newton 3 demos that you can play show a lot more physics activity and that without any fps drops or weird behavior. On my laptop I can barely run the game (For the record: I can play GTA 4 on my laptop). As soon as the tower falls over (24 blocks), the game slows down to 3 fps.

After the game was finished I recreated it in C++, just to see if the physics performance would be better. Unfortunately that is not the case. I even went back to Leadwerks 2 (with newton 2) to do the same test. The performance is so much better. I can have 200 boxes in a tumbling tower without any fps drops.

 

I am 100% certain that there is something wrong with the integration of Newton 3 into Leadwerks 3. Ofcourse this is really difficult to pinpoint but it sure is a showstopper. It isn't the first time this happened in a project with Leadwerks 3.



5 Comments


Recommended Comments

Part of a competition is understanding what you are working with. If the physics were something you weren't sure about, then you probably shouldn't have made a physics based entry. You could have worked with a part of the engine that you felt more confidence in.

 

Don't get me wrong. It's great to test things out and report them to Josh, but I'm not sure why you would choose a competition to do that.

 

Edit: What else I wanted to add is that the entry seems less like a game and more like a Leadwerks stress test. Which I'm not sure if the purpose of the competition is to try to showcase problems with Leadwerks, but I would think it isn't.

 

I don't get any pleasure out of being critical. But I don't see the game in this demo. Jenga is nothing without the physical, tactile element - 50% of Jenga is preventing your hands from shaking.

Share this comment


Link to comment

@You obviously have not read the blog correctly.

 

1. This game is not Jenga, The idea of having a tower and removing blocks looks like it. So why you are using 'shaking hands' statement? That is not at all a factor in my game.

2. The game is not a stress test. It is a simple game where you remove blocks from a tower. A stress test would be testing out 1000 blocks or rendering 10.00 static blocks.

3. Who says I made this game to demonstrate problems? I have a game idea that I want to create and these are my findings.

4. "..that you have more cofidence in". First of: So according to you I should stay away from making games that have any physics in them? Second: If you stay away from things that you are not comfortable with using, how on earth are you supposed to learn about it.

Share this comment


Link to comment

Some things in life never change ... there are those who do and those who don't ... and the irony is that it's inevitably those who don't who criticise the most.

 

Anyone who entered the competition and managed to complete a mini game in just one week deserves respect. The fact that they have highlighted possible issues with the game engine too is an added bonus.

 

Kudos to you Aggror ... innovative entry (the winning one in my estimation) and interesting blog.

Share this comment


Link to comment

Don't take account of what i reported for swept collision fail (can abandonn my WipeOut game prototype ).

 

OK LE3 physics are fine, no problem.

Share this comment


Link to comment

We switched to an exact solver recently, which provides more stable results but can take a lot of iterations. Will look at it more closely. I would expect it to perform the worst in a stacking situation.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 4
      Here are some screenshots showing more complex interface items scaled at different resolutions. First, here is the interface at 100% scaling:

      And here is the same interface at the same screen resolution, with the DPI scaling turned up to 150%:

      The code to control this is sort of complex, and I don't care. GUI resolution independence is a complicated thing, so the goal should be to create a system that does what it is supposed to do reliably, not to make complicated things simpler at the expense of functionality.
      function widget:Draw(x,y,width,height) local scale = self.gui:GetScale() self.primitives[1].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) self.primitives[2].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) --Tabs local n local tabpos = 0 for n = 1, #self.items do local tw = self:TabWidth(n) * scale if n * 3 > #self.primitives - 2 then self:AddRect(iVec2(tabpos,0), iVec2(tw, self.tabsize.y * scale), self.bordercolor, false, self.itemcornerradius * scale) self:AddRect(iVec2(tabpos+1,1), iVec2(tw, self.tabsize.y * scale) - iVec2(2 * scale,-1 * scale), self.backgroundcolor, false, self.itemcornerradius * scale) self:AddTextRect(self.items[n].text, iVec2(tabpos,0), iVec2(tw, self.tabsize.y*scale), self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end if self:SelectedItem() == n then self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos, 0) self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) + iVec2(0,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 2].color = self.selectedtabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,-1) self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,0) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,0) else self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) self.primitives[2 + (n - 1) * 3 + 2].color = self.tabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,2) if n == self.hovereditem then self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor else self.primitives[2 + (n - 1) * 3 + 3].color = self.textcolor end self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 3) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,2) end self.primitives[2 + (n - 1) * 3 + 3].text = self.items[n].text tabpos = tabpos + tw - 2 end end  
    • By 💎Yue💎 in Dev Log 5
      The prototype of a four-wheeled vehicle is completed, where the third person player can get on and off the vehicle by pressing the E key.  To move the vehicle either forward or backward, is done with the keys W, and the key S, to brake with the space key.  And the principle is the same as when driving the character, a third person camera goes behind the car orbiting 360 degrees.

      I don't think the vehicle is that bad, but I'm absolutely sure it can be improved.  The idea is that this explorer works with batteries, which eventually run out during the night when there is no sunlight.
      Translated with www.DeepL.com/Translator
       
      Mechanics of the game.
      I'm going to focus on the mechanics of the game, establish starting point (Landing area), after the orbiter accident on Mars where all your companions died, now, to survive, you will have to repair your suit, oxygen runs out, good luck.  This involves replacing the oxygen condenser that is failing and the suit is stuck.

      On the ground and performance.
      The rocks, the terrain and the vehicle kill the SPF, but there is a solution, and everything is related to the chassis of the vehicle. That is to say that if I put a simple collision bucket for the vehicle, the yield recovers, something that does not happen if I put a collider of precise calculation for the car. This has the advantage of better performance but is not very accurate, especially when the car crashes with an object in front, because the horn of the car has no collision. And the solution to this, is to put a sliding joint, as was done with the area in which the player climbs the car and descends from it.


       
      On the rocks, I am trying to make them with the slightest polygons and the most distant from each other. 
      Obviously on Mars I can not create canyons, high mountains, is because the terrain does not produce shadows on itself, that's why the terrain tries to be as flat as possible, simulating a desert with dunes. 

      That's all for now.
       
    • By 💎Yue💎 in Dev Log 9
      The prototype is finished, and the mechanics of the game can be given way.  It has established a desert terrain in the form of dunes, this implies that there are no cannons or anything similar, because Leadwerks does not allow a terrain to cast shadows on that same terrain and this looks visually rare.
      So the terrain is like low-slope dunes. On the other hand, I think the texture of the terrain is already the definitive one, with the possibility of changes and suggestions on the part of those involved in this project.
      On the other hand we have taken the model of a habitat of the nasa, which certainly looks very nice. 
      The next steps, are to establish the starting point of the player, this must start near the capsule return to Mars somewhere on the map of 2024 x 2.
      And think about the first thing you should do, repair your suit? Seek a shelter? things like that.  


×
×
  • Create New...