New answers tagged

3

A rational approach might be to simplify your problem. This is a game, so most of the time there is no need for 100% accurate physics. Instead of tracking every single component that makes your ship, you can instead prepare several damaged ship models and swap then on the fly as it gets more and more damage. When you swap the models, you could spawn some ...


2

The theory will tell that you're likely to get less cache misses (so 'more efficiency' w.r.t. response time) if your objects are close one to another in memory. This means that if you use an array, and your objects are contiguous, and you access each of them in a in-memory-sequential fashion, it will be more efficient than if you hop from here to there and ...


2

Based on your description, I would make each card effect verb a class & then use composition to combine them into cards as needed. E.G. the draw cards action would be an effect class, its parameters might be # of cards, source drawn from & type of draw. Damage player might be another effect class & its parameters might be amount & ...


0

First your organization of data is pretty good. Using arrays or objects does not really matter much although an object is cleaner, as it provides a clean interface and avoids simple problems like unset properties. I don't think that verbosity of yours a bad thing. unittypes[unit['type']]['movecost'][tile['type']] can easily be encapsulated, so you need it ...


1

In Javascript, a property can also be a function. Don't make enemyType a string. Make it an object which has multiple methods for different interactions. violetThing = { name: "violet", sprite: "violetThing.png", onTouchFunction: setMagnetic, color: '#ffdd22' } yellowThing = { name: "yellow", sprite: "yellowThing.png", ...


2

You could use a hashtable with a key which consists of both the x-coordinate and y-coordinate. Finding the tile at a specific coordinate is then a constant-time operation. When you want to cache the "outline", you could store it in another hashtable. Whenever a node is added, follow this algorithm: the new node is removed from the "outline" hashtable for ...


1

Assuming you'd like your game's levels to be edited by either a non-technical game designer or QA team, I would actually recommend none of what you suggested for the actual level editing portion. Because the parameters of these levels are relatively simple, I recommend you make the editor a part of the compiled application, not part of the Unity editor. In ...


1

(Sorry for poor formatting - I'm on my phone) There are a lot of valid options. If I were tasked with this, I would probably do one of two things: Save the level data in Google Sheets and use one of the google sheets assets available on the asset store to pull it into the game either at design time or run time. Or: Save the level data in ...


-1

There is no conventional approach in designing a game really. You do whatever works for you. You can have full physics in your game, or you can fake it all. Back to your question though, since the levels of a game like this are all random and also proceduraly generated, then just use one scene with a camera only. Switch from main menu to game type ...



Top 50 recent answers are included