Welcome to the bikiniverse!

Dev diaries
#55

So,

my project has taken a little bit of a beating! I spent a lot of time learning lua and defold in order to get it into the competition, and it didn’t win, and i had convinced myself that I was going to win, so that was a downer. And then I found out that my concept has already been created, and this was especially annoying because the originality was a key thing for me on a personal level, apart from the fact that I don’t want my game to be known as a link-twin clone (…and it looks like link-twin is going to get at least a little bit famous, because they have a publisher and some kind of endorsement from Samsung). They even made it character-based when it would have been much easier to do a block-sliding game!!! damn!!!

So this month I’m moving to a new flat, and I’m going to have a think about what I want to do to finish this project, although I am less motivated now.

#56

Don’t worry. What you experience is quite normal in game development because there are so many great minds with cool ideas that it’s very hard to find totally new concepts. For example, this link-twin is probably not the first released game of it’s type either, because i remember playing such a game about 5 years ago on a flash-games site like kongregate.

In fact many, many indie-games i played in the last few years have been inspired by those small flash-games without anyone noticing. For example, you were able to play the core mechanics of Angry Birds in a browser-game at least one year before it’s release. All they did was streamlining those mechanics, add cute, mass-compatible graphics and adapt it to a platform better suited to the mechanics.

And that’s not a bad thing. In my opinion game development often is more about evolution rather than revolution. Even the most renowned developers like Blizzard have never created anything truly new. Warcraft was an evolution of Dune II, Diablo was a pimped Rogue/Hack-Clone (initially it was even turnbased), WoW had multiple ancestors like Everquest and Overwatch is very similar to Team Fortress (BTW: The Overwatch-producer took this comparison as a compliment, and not as blaming for being a clone).
Blizzard has mastered the art to just pick a game or genre and evolve/streamline/polish the heck out of it.

This of cause doesn’t mean we should not try to find totally new concepts. But i think it helps to see the positive things when you encounter a game similar to yours:

  • Very important: It’s a proof of concept that your idea has potential! You are not the only one who thinks that the world needs your game.
  • You can play and analyze the other game to determine features you could apply to your game to make it better. And on the other hand what your game could implement the other game may be missing.

So i suggest to not see your game as a clone just because you share some mechanics, but rather as a quest/challenge to find the one key-selling-point that distinguishes your game from the other. It can be anything: New mechanics, artstyle, story, easier controls or a new platform (currently AR and VR are quite popular).

If you just add only one thing that’s different (maybe you already have) you will probably find people who are at least equally or even more interested in your game than the others. And if you don’t find the secret ingredient, it’s not a shame to just start the next game. I have thrown away countless prototypes and half-finished games, but i guess i learned something from every single one.

And as you experienced by yourself you always have the possibilty to reactivate old projects if you stumble upon the missing ingredient months or even years later. You can even simply finish and release your game as it is now and add any new ideas you find later to a sequel.

See it this way: Your first game is very solid and already has some fans. For comparison: My first 5 or so games have all been unfinished crap no one ever played. So you have all the right to pat yourself on your shoulder. :slight_smile:

10 Likes
#57

This is a really great answer @Daggett ! I totally agree with you. Discovering a game similar to the one you’re working on does probably mean that your idea is good and worth pursuing. It can really act as motivation to make your game even better. Don’t give up @88.josh!

4 Likes
#58

I am back in the bikiniverse!

How can I animate a local variable?

1 Like
#59

You can use go.animate() to animate script properties defined with go.property(). It should be possible to animate numbers, vector3 and vector4, but I’m not 100% sure.

#60

I did a test. You can only animate numbers. You will not get an error when you try to animate a V3 or V4, but nothing happens. This is tracked in issue DEF-1311 and discussed on the forum in this thread.

2 Likes
#61

So what am I doing wrong then?!? !?!?!

go.property("offsetter", 0)
go.property("scrolling", false)
go.property("camera", vmath.vector3(0, 0, 0))



function update(self, dt)
self.camera = go.get_position("levelselect:/camera") 
	if self.camera.y ~= 0 then
		self.scrolling = true
		self.offsetter = self.camera.y
	elseif self.scrolling == true then
		self.scrolling = false
		go.animate(go.get_id(), self.offsetter, go.PLAYBACK_ONCE_FORWARD, 0, go.EASING_LINEAR, 2, 0)
	end	
	self.selfpos = go.get_position()
	self.selfpos.y = self.selfpos.y + self.offsetter
	go.set_position(self.selfpos)
end

(nb. i know i still have to make it lerping and not just set position, but right now i get a message “doesnt’ have a property called offsetter”)

EDIT: Okay, got it: it is not the GO but the script that has the property, so instead of using “go.get_id()” in the animate part, i should use “#”. What a pain in the ass. I’ve spent hours on this problem. It’s crazy how quickly i forgot everything I learnt just a few months ago.

1 Like
#62

Exactly. It’s the script component that has the property, not the game object. That’s why you have to do go.animate("#sprite", “tint”, …) to animate the tint of a sprite component. It’s the sprite component that has tint property, not the game object.

2 Likes
#63

Thank you for your help @britzl as usual it has proved invaluable.

Thanks also to @Daggett for his palabras de animo.

2 Likes
#64

A question:

i have had to increase my factory buffer to 512. Although i actually use the factories very rarely. Unless the player is shaking the mouse around very fast (very unlikely), there will only be 1 object generated every second at the absolute most. All of the game objects that are created are deleted almost instantly. Is that a problem?

(I just realised as i was writing this that this is the EXACT REASON that particle effects exist… but anyway, humour me. Is what I am doing okay?)

#65

No, it should not be a problem. And if you’re worried about performance then my recommendation is to test on your target platform and check with the profiler. Do you get 60 fps consistently? Are you well within frame budget? What if you disable the feature and check again? Is the difference significant?

#66

@britzl those are all great questions but it was quicker for me to just to change everything to a particle effect, it was a much simpler way of getting what i wanted. Thanks though.

Can anyone tell me the code to simulate a mouse release? I can’t find it anywhere.

#67

Hmm, how do you mean? There is no proper way for you in code to call the on_input() function yourself.

Perhaps you can move your input handling to a separate function that you can call manually as well as from on_input() and in the case of simulating a mouse release you’d build your action table with the released variable set to true.

#68

Yes, I suppose changing the table would be one way of doing that. In the end I just put all my release behaviour in a local function and called that.

#69

Today the thing that is annoying me is the fact that collection proxies automatically updated themselves if you change the name of the collection they used to refer to. So If I have levels called 1.collection, 2.collection, 3.collection and I decided to swap 3 and 1 around, I have to change their names and then change their proxies as well. I do not think it would be exaggeration to say this is the most frustrating thing in all possible universes

1 Like
#70

Designing levels in bikiniverse is the most satisfying thing in the world. I am literally shivering with pleasure.

(also i am using the company’s air conditioning right now and it is heaven on earth).

5 Likes
#71

Hi Everybody!

It’s nice to see the new website looking so great!
I have a quick coding question. I want to animate the position of every object in a table. Each object’s address is stored in the table. So printing v gives you “DEBUG:SCRIPT: url: [default:/instance2#script]”

for k,v in pairs(self.objects) do 
		--msg.post(v, "ender")
		print(v)
		local pos= go.get_position(v)
		pos.y = pos.y-750
		go.animate(v, "position", go.PLAYBACK_ONCE_FORWARD, pos, go.EASING_OUTBACK, 5, 0)
		go.animate(v, "scale", go.PLAYBACK_ONCE_FORWARD, 0.8, go.EASING_OUTBACK, 1, 0)
		end

this code gives me an error because v refers to its URL rather than the object itself (…right?). So, my question is, how do i correctly use go.get_position() and go.animate() to move an object only using that object’s URL from the table?

2 Likes
#72

Hmm, I would have guessed that it should work. Are you sure it’s not working? What’s the error you’re getting?

#73

V refers to the address of the SCRIPT rather than the object, scripts do not have a position!

#74

You can do msg.url(v.socket, v.path, nil) to get the url of the parent game object.

1 Like