Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›2 »

Pollyanna: Mar 5, 2005; Milk's on them.

How should you approach designing a game idea and structuring a project? Completely separate from actually programming the game, how do you know what parts to split the project into, what kinda file structure would work best, how to develop game mechanics and ideas, etc.? Could I get a basic example of the design flow for a simple game?

I know this is more of a design question than a coding question, but it seemed appropriate for this thread.

# ¿ Sep 25, 2013 18:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 20, 2024 02:47

Pollyanna: Mar 5, 2005; Milk's on them.

How does that work for a one-man project, though? Do simple, non-AAA games go through much the same process, or is it more streamlined?

# ¿ Sep 25, 2013 19:54

Pollyanna: Mar 5, 2005; Milk's on them.

I'm looking to make a simple 2D game in Javascript. What recommendations are there for a basic JS game engine? I know of Crafty.js, and it seems pretty good - although the component system kinda throws me off. Has anyone else here used it, or done any sort of game development in Javascript/HTML5?

# ¿ Nov 27, 2013 04:02

Pollyanna: Mar 5, 2005; Milk's on them.

I'm looking to do something new for my next app, and I want to try learning web game development. Is there a recommended beginner framework, or a well-liked tutorial website?

# ¿ Mar 9, 2014 06:41

Pollyanna: Mar 5, 2005; Milk's on them.

duck monster posted:

what are your language preferences?

Well, I doubt I have much experience with the languages that are typically used...I'm most familiar with Python (which I doubt is used much in HTML5 games), but I can get around in Java and Javascript well enough. TypeScript looks interesting too. Are there other languages that are used?

# ¿ Mar 9, 2014 23:01

Pollyanna: Mar 5, 2005; Milk's on them.

What kind of data structure should hold a character's stats? I'm creating a character generator that's meant to be part of a larger project later on, and I was wondering whether I should hardcode all the stats and fields (like class, level, skills, HP) as individual attributes, or if they should be kept in a hash or something under a generic "fields" attribute.

# ¿ Sep 27, 2014 03:05

Pollyanna: Mar 5, 2005; Milk's on them.

Is there a particular "approach" to drawing up a game idea? I kinda feel like there should be some sort of science or art behind making a simple yet fun-to-play game. As far as I tell, the idea is to come up with a basic mechanic, and build on it from there. How are games "thought up"?

# ¿ Dec 19, 2014 00:36

Pollyanna: Mar 5, 2005; Milk's on them.

I could go ahead and go by an idea generator or just sit at the terminal and play around, but that won't necessarily lead me to make a good game idea. I want to make something that's fun and enjoyable, and not just something dinky that inevitably gets tossed away.

# ¿ Dec 19, 2014 17:02

Pollyanna: Mar 5, 2005; Milk's on them.

Suspicious Dish posted:

OpenGL is a horrible API from the 80s. You want to ignore most of it, use all of the GLES subset that you can, and then use DSA because holy poo poo DSA owns.

Pyglet only offers a 1-to-1 API with OpenGL if you want to make graphics in it and holy hell I tried to use it once and got incredibly sad.

Hmmm, DSA you say.

# ¿ Jan 12, 2015 19:43

Pollyanna: Mar 5, 2005; Milk's on them.

This may be where I got it from - but I found a really cool book on games programming design patterns that's been a really, really helpful and interesting primer to the very basics of creating a game. Sharing it so everyone else here has access to the resource too :3:

vv I haven't read the Goff yet. An online class I'm currently taking uses it and the class is so bad that it's sort of soured me on reading it. (I might actually drop that program for good this time.)

Pollyanna fucked around with this message at 05:06 on Feb 9, 2015

# ¿ Feb 9, 2015 04:58

Pollyanna: Mar 5, 2005; Milk's on them.

Is there a particular pattern that works well for creating menus? I had originally thought of making a Menu class:

code:

class Menu
  def initialize(submenus = [])
    @submenus = submenus
  end

  def add_submenu(submenu)
    @submenus << submenu
  end
end

But that hasn't worked very well, since I don't know how to go up a menu, or back. I understand that it's basically a tree structure, but aside from that I'm a bit lost.

Alternatively, if there's a book or resource I can be pointed to to get me to shut up, that works too. :v:

# ¿ Feb 12, 2015 00:23

Pollyanna: Mar 5, 2005; Milk's on them.

Joda posted:

I tend to use stacks for menus that have submenus. I.e. having every menu add a new menu to the stack if the user entered a submenu, and popping the top of the stack whenever the user goes a step back. The update loop just calls the update function of whichever menu is at the top of the stack.

You can still use a Menu class for this, but submenu instances won't be members of the previous menu, but rather an overall stack data structure that contains all menu states.

So...it'd be something like this?

Ruby code:

class World
  def initialize
    @menus = []
  end

  def load_menu(menu)
    @menus << menu
  end

  def update
    menu = @menus.pop
    menu.update(self)
  end
end

class Menu
  def update(world)
    submenu = Menu.new
    world.load_menu(submenu)
  end
end

world = World.new
menu = Menu.new
world.load_menu(menu)
world.update

If I ran this, it would continually pop and push a Menu onto the stack of menus. Is this basically the behavior I'd need? In which case, I'd just have to have each Menu add a specific menu whenever it does its update method...but then don't Menu instances become members of other Menu instances anyway?

Praseodymi posted:

To add on to this, have a pause and unpause function for each state that you enclose sections of the update loop in so you can still render previous layers and even perform some update stuff if you want. I made a state manager like that and not only did it solve all the state and menu related problems I'd had but it's the most reused piece of code I've written.

Could I have an example of this code, please, so I know how it's structured? It helps a lot for me to see how it's implemented.

# ¿ Feb 12, 2015 15:48

Pollyanna: Mar 5, 2005; Milk's on them.

I have a couple of questions.

How would you model a tile-based game world? When I think of a tile-based game, I imagine a collection of Maps that are all made of an n-by-m 2D array of Tiles, and the Player would be "in" one of those Tiles. Thinking of it in an object-oriented manner, would a Map object basically have a nested array of Tile objects, while one of those Tile objects has a Player in it? How would you handle the Player moving from one tile to another? Would it be a method on the Player, the Tiles, or the Map?

Unrelated to the above, how do you do Test Driven Development when making a game? It seems a little difficult to pull off, since there's complex interactions between the player's controller, the state of the AI, and graphics rendering. Do you only do unit tests and forego integration testing/simulating user input? How do you deal with the input -> update -> render loop?

# ¿ Feb 22, 2015 01:08

Pollyanna: Mar 5, 2005; Milk's on them.

That does sound like code that would jive well with TDD/BDD, though. If we have clearly defined classes and expected behavior, but don't really know what kinds of algorithms to write, that's prime material for testing. That, and I found this one article about automatically testing a game with a server dedicated to jamming random inputs into it.

edit: I think a lot of my problems stem from the fact that all I've got is Gosu and Sublime. A lot of low-level implementation details are being left up to me, and I don't know how to code, like, an input controller or a rendering system from scratch. I'm basically trying to create a game engine all on my own. :pwn:

Which is a little out of my league at the moment. I might just move to Unity to get the basics down, and actually tackle something more low-level like Gosu or Pyglet once I have game development experience of any kind at all.

Pollyanna fucked around with this message at 08:06 on Feb 22, 2015

# ¿ Feb 22, 2015 07:16

Pollyanna: Mar 5, 2005; Milk's on them.

^^^ YAML sounds like a great tool for data-driven development, especially for the Prototype pattern.

So I've decided to start some game-dev exercises using a framework called Gosu, for Ruby. I've just pushed an MVP for my input test exercise: https://github.com/rpazyaquian/input-test

I'd like comments and refactoring advice on this and any other exercises I do! It helps a lot to see people's changes in action. In particular, I have a question about this exercise: I managed to write a working input, but what happens when I want to reuse this in another exercise? I have to copy all the code from input-test, and that's a pain...is there a way to split it out into its own thing, like a library of some sort?

(If this seems naive, that's intentional. I overcomplicate things by trying to go for clever solutions right off the bat. Why not help me improve it? :3:

)

# ¿ Feb 25, 2015 21:16

Pollyanna: Mar 5, 2005; Milk's on them.

How do games use JSON for anything other than stuff like

code:

{
  "name": "goblin",
  "hp": 10,
  "attack": 2
}

where it's simply descriptive data, instead of actual logic? How do you specify logic as data?

# ¿ Feb 27, 2015 04:55

Pollyanna: Mar 5, 2005; Milk's on them.

What 2D frameworks are recommended for OSX/Linux? I know of Love, Gosu, and Pyglet, but they're not quite as full featured as I'd like. I know you can use Unity/UE4 for 2D games, technically, but they still have the complexity of a 3D engine, and I'm looking for the sweet spot between that and the former engines.

# ¿ Mar 6, 2015 01:16

Pollyanna: Mar 5, 2005; Milk's on them.

I'm reading Learning 2D Game Development With Unity, and it's interesting, but also kind of disappointing. The book isn't very well organized: the (required!) assets and files aren't included nor is it clear where you can get them, the book never actually tells you about critical components such as how to check if the player is on the ground, and there's a whole lot that's either skipped (e.g. aforementioned ground check component) or outdated because of changes in Unity 5. Plus, the editing is kind of mediocre.

It's kind of disappointing, really. What books on 2D game dev like this one (but better) are recommended? Unity-specific is ideal, since that's where I'm starting.

# ¿ Mar 18, 2015 16:15

Pollyanna: Mar 5, 2005; Milk's on them.

e: wrong thread

Pollyanna fucked around with this message at 17:22 on Mar 26, 2015

# ¿ Mar 26, 2015 15:01

Pollyanna: Mar 5, 2005; Milk's on them.

How feasible would a fully-or-mostly functional approach to games programming be? All the resources I've read out there say that FP is awful for games because there's a lot of changing state and memory/processing power is at a premium.

I'm not sure I agree with the first assessment, because the way I see it, game state is really just a function of previous game state, user input, and miscellaneous config (current and previous system time, world map size, number of players, whatever), so in theory it should be possible to make a primarily FP game loop, if not fully FP. Game state is totally doable for a functional approach, just by the definition of it. Rendering might be different, but the core of the game doesn't have to worry about rendering - it just needs to output the data that the rendering pipeline needs.

As for the second, I concede that it's a concern, and immutable data structures would on the surface seem to make that a problem. However, I've learned that Clojure has optimizations to minimize the memory effect of immutable data where the changes between data structures are recorded rather than them being completely reinstantiated. That appears to help solve the big-O problem of your memory getting hogged to pieces by many variations of the same data, although I haven't proven that.

Of course, traditional OOP or MVC approaches may not work terrifically well for FP games programming, but entity-component systems seem promising, and have been in use for a while, so I think it's totally possible to make a decent game using FP approaches in a language like Clojure. (As a bonus, Clojure is also a JVM language, so it can use all the Java libraries!)

Even if it's pie in the sky thinking, I'm going to see how far I can get by sticking as purely FP as possible (or even just reasonable) in making a game. It's not gonna be a big one, but it'll satisfy me.

# ¿ Jul 13, 2015 13:34

Pollyanna: Mar 5, 2005; Milk's on them.

No, not Haskell, I don't know anything about Haskell. And I might be confusing "functional programming" with immutability, minimization of side effects, entity-component systems, and separating game logic and state from input and the rendering pipeline, anyway. Point is I want to see if I can make a game that I can comprehend from top to bottom.

Yodzilla posted:

Go the Naughty Dog route and program everything in LISP.

Hence Clojure. :eng101:

If I need a library, I got all of Java at my fingertips.

# ¿ Jul 13, 2015 18:07

Pollyanna: Mar 5, 2005; Milk's on them.

poemdexter posted:

If you fully embrace and know how to work within the Entity/Component pattern, you can easily do big projects in Unity. Just my two cents based of experience. I find most people want to take a more strict OOP pattern with Unity and struggle because Unity is designed around E/C.

I actually really like ECS, cause I think it's a lot easier to comprehend cognitively and is a lot more flexible than typical OOP approaches. I was always under the impression that Unity was all OOP, mostly because of being C#-based, so maybe I should give it another chance.

I'm still curious about ECS itself and I want to try my hand at my own implementation of it, too, though.

# ¿ Jul 20, 2015 12:26

Pollyanna: Mar 5, 2005; Milk's on them.

Open-source MMOs, maybe? :eng101:

Although I have no idea if that'd be a security problem or something.

# ¿ Jul 23, 2015 18:44

Pollyanna: Mar 5, 2005; Milk's on them.

I've been putzing around trying to create a basic game loop, and I'm beginning to wonder where exactly all the pain points in modern game development are. From what I can tell, the high level view of a game is simple enough: get input, pass input to game state processor, pass game state to renderer, repeat. It doesn't seem too complicated, but then I look at Unity and realize yes, it is really that complicated. However, I'm under the impression that the most complicated parts of game dev are auxiliary things like toolchains and devops, performance concerns, and flexibility in game design (making it easy to add new data and behavior).

What do you feel are the biggest problems in game dev these days?

# ¿ Aug 4, 2015 00:19

Pollyanna: Mar 5, 2005; Milk's on them.

May I ask why you overloaded to_string?

# ¿ Aug 7, 2015 21:07

Pollyanna: Mar 5, 2005; Milk's on them.

I wrote this up in my project.log thread, but I figured it was interesting enough to share in this thread.

So I'm trying to figure out how to handle communication between components in an entity-component system architecture. The whole deal with components is that they only store data, and the systems are what handle logic and all other code. That means that my components don't have "render" methods or subscribe/notify mechanisms. Still, I need a way to handle events and triggers for the cases where a change in one component affects another. Systems are the only way to coordinate this kind of process, so the systems have to handle triggers and effects.

Let's say we have a collision system. The collision system processes the components of all collideable entities - collideable in this case implying Position and Size components. Let's say we have three entities, entity1, entity2, and entity3. Entities 1 and 2 collide, as do entities 1 and 3. Entities 2 and 3 don't collide. There are also three triggers associated with those entities: a trigger between entity 1 and 2, 1 and 3, and 2 and 3, each of type "collision". This means that the effects associated with these triggers should be applied when an event matching the targets and the trigger type occurs.

What I'm figuring is that a collision system has three steps:

Compile a list of events, in this case something akin to "COLLISION between ENTITY1 and ENTITY2".
Based off the list of events, compile a list of triggers that are associated with those events, such as the trigger associated with entity1 and entity2, of type "collision". This would not include the trigger associated with entity2 and entity3, of type "collision", because there would be no "COLLISION between ENTITY2 and ENTITY3" event - it didn't happen and is not in the list.
Based off the list of triggers, compile a list of effects associated with each "tripped" trigger. In this case, the entity1-2 collision trigger says the effect is "delete entity 2", and the entity1-3 trigger says the effect is "delete entity 1".
Apply all effects to the game state. So, the end result of a collision between entity1 and entity2, and a collision between entity1 and entity3, is that entity2 is destroyed, and entity1 is destroyed.

Does that make sense? Again, to summarize, in a "pure" ECS architecture, a system does three things:

Compile a list of events that occurred.
Compile a list of triggers that trip on the occurrence of those events.
Compile a list of effects associated with those triggers.
Apply each effect in that list to the game state.

Actually implementing this is a bit of a mind-bender. The steps are right there, sure, but then there's details like "how do you apply the effects" and whether those events/effects should be forwarded to the systems that should deal with those associated components, and how to make sure they get processed in the right order. This isn't as simple as an OOP approach, nowhere near as such, but I believe it is much more efficient and extensible.

That entails actually making the drat engine, though, which I will probably never get around to. :downs:

Pollyanna fucked around with this message at 17:54 on Aug 15, 2015

# ¿ Aug 15, 2015 17:52

Pollyanna: Mar 5, 2005; Milk's on them.

Godot is apparently pretty good for that, too. I might look into it when I'm done with my current project.

# ¿ Aug 21, 2015 15:08

Pollyanna: Mar 5, 2005; Milk's on them.

Why not learn to write an SNES game itself?

# ¿ Aug 21, 2015 23:06

Pollyanna: Mar 5, 2005; Milk's on them.

Maybe create a bunch of basic geometry "tiles" and randomly create a level from an assortment of those tiles?

# ¿ Aug 26, 2015 16:42

Pollyanna: Mar 5, 2005; Milk's on them.

This is rich coming from me, but you should start by making a simple game like moving right to pick up a duck. It's got input handling, position and velocity, collision detection, and a win condition.

# ¿ Aug 26, 2015 22:50

Pollyanna: Mar 5, 2005; Milk's on them.

TheresaJayne posted:

Just saw a game advert with a nod to Black Annex.

Satellite Reign video trailer on steam starts by showing a street with a club called "Black Annex Club"

So even if everyone is doing stealth hacky games it also appears that it was all started by Black Annex

I wonder if this is true of Watch_Dogs.

# ¿ Aug 31, 2015 17:29

Pollyanna: Mar 5, 2005; Milk's on them.

So, I've gotten to the point in FP Breakout where I need to consider a smarter way of storing my entities and components. At the moment, I have a struct-of-arrays keyed by "entities" (array of strings) and component types ("positions", "velocities", " rectangles", etc.). I get a list of movement-related components by running a set join on positions and velocities keyed by entity, which gets me the typical array-of-structs that systems/processors expect. This works, but is a bit of a pain cognitively and I'm wondering if there's a better way to solve this problem.

ECS goes well with database-like approaches (either relational or fact based), so something akin to that would work. There's a few things I need to do: get components by entity ID, get components by type, join components types by entity key and then search for a join by entity key, and more. It's trivial with a database, but standard data structures don't have that built in...

# ¿ Sep 3, 2015 13:55

Pollyanna: Mar 5, 2005; Milk's on them.

Unity is terrible and I disliked working with it. In fact, I've had nothing but frustration with trying to make a game in any framework like Unity. Maybe I'm impatient or just plain dumb, but I've had more success with a Processing wrapper and self-grown code (which is not saying a lot).

Once FB is finished, I'll knuckle down and seriously tackle a larger project in something like UE4, LibGDX, or Cocos2d-x. I'm only interested in 2d game dev right now, so at least it will be simple.

Which leads me to ask: are there any good books on developing a 2d, hell even a 3d game in UE4, LibGDX, etc.? Tutorials only go so far and just confuse me further. I need something good and structured that exhibits a good coding and organizational style, best practices, and isn't written in mangled English.

I'm seriously considering writing one of my own once I actually know what I'm doing. That won't happen for years, though.

Pollyanna fucked around with this message at 13:56 on Sep 9, 2015

# ¿ Sep 9, 2015 13:00

Pollyanna: Mar 5, 2005; Milk's on them.

SupSuper posted:

It's really a shame how little resources there are on actually building things to last, as opposed to just building things. Anything engine-specific will be focused on selling you on the engine, so you're better off getting design/organization tips from general coding books.

Though if you care too much about code, one book I always heartily recommend is Game Coding Complete. It's probably too complex for an indie-scope game, but it really makes you think about all the architectural decisions that can go behind a game that nothing else touches on. Game Programming Patterns is always a nice addendum as well.

Game Programming Patterns is great and I love it. It's actually what got me seriously thinking about doing game dev.

And I agree that books about specific engines are pretty much useless since they change so much. Tutorials, maybe, but I can't help but feel like all engines and frameworks differ way too much in terms of project organization, assumptions, and opinions, so knowledge really doesn't transfer between them.

Just tried for way too loving long to turn an array of facts into a hash I can render a rectangle from. :gonk:

This is incredibly sad for me.

# ¿ Sep 12, 2015 00:51

Pollyanna: Mar 5, 2005; Milk's on them.

You know what, I'm curious. I'd like to take a survey of everyone's approaches to game dev:

1. Do you use a particular framework to develop your games, or do you roll your own engine? If the former, which one(s)? If the latter, what drove the design and development of that engine?

2. Do you have any formal training in game development, such as a college degree, or are you primarily self-learned?

3. Do you work in the gaming (as in video games, not gambling) industry? If not, would you want to work in the gaming industry?

4. Have you studied design theory in the context of game design? If so, how have you incorporated it into your games? What resources have you used?

5. Are your games open source? If not, are they at least publicly available on version control sites like Github?

6. Have you studied the source code or design documents of other games, e.g. the Quake 3 source code? If so, what have you learned from doing so?

7. What do you feel is the largest problem (or problems) in game dev these days? What do you feel could help alleviate these problems?

8. Do you follow a design and iteration process, formalized or otherwise, for developing your games?

I'll go first:

1. Do you use a particular framework to develop your games, or do you roll your own engine? If the former, which one(s)? If the latter, what drove the design and development of that engine?

I have dabbled in various frameworks and engines like Unity and Cocos2d-x, but I am not satisfied with any of them. I feel like game engines and frameworks are too convoluted, do not clearly communicate the application flow of the game's program, and are not very discoverable on their own, requiring you to refer to outside tutorials and articles which can become (and often are) outdated.

My dissatisfaction with game engines means that I've decided to start from scratch instead. I am currently rolling my own engine in Clojure for educational purposes, as well as to have complete understanding of the game's application flow and development methodology.

I've learned that it is in fact really loving difficult to put a game engine together, not just due to the complexity inherent in generating program state but also to the complexity in creating a good API and canonical development methodology for the engine.

In fact, I believe that the biggest problem with game engines these days is that they all have their own methodologies and interfaces - so there is very little transfer of knowledge between them. Creating a game in Unity is very different from creating a game in GameMaker or by using Libgdx, even if you're ending up with the same game itself.

2. Do you have any formal training in game development, such as a college degree, or are you primarily self-learned?

I do not have any formal training in game design or game development, but I do have experience in software development in general. Everything I know, I've read about or learned by messing around with an engine or framework. I also read a lot about the design theory behind game development, and find it fascinating.

3. Do you work in the gaming (as in video games, not gambling) industry? If not, would you want to work in the gaming industry?

No, I do not work in the gaming industry. I have heard that the gaming industry is not a good place to work, and the anecdotal evidence I've picked up over time seems to corroborate that. I will likely never make game dev my primary job, and keep it to a hobby - but still one I want to do well at!

4. Have you studied design theory in the context of game design? If so, how have you incorporated it into your games? What resources have you used?

I have read a book or two on game design theory. I read A Theory of Fun recently and loved it, and I just started reading Designing Games: A Guide to Engineering Experiences, which is great so far. For general design theory, I found The Imagineering Workout to be genuinely fun to read, and the exercises are very engaging. I've had good success in generating ideas from working through the book.

I haven't actually made a game yet because I'm a total poo poo, but I definitely think about what kind of game I'd make if I ever did! I often approach my ideas for games by incorporating the lessons and knowledge I've gained from the design theory resources I've consumed.

5. Are your games open source? If not, are they at least publicly available on version control sites like Github?

I intend to at the very least make some of my games open source, for the purpose of allowing other developers to read their source code and understand the methodology behind the software's development, and to learn why they were designed that way.

I believe that in the game development realm, we learn a lot about how to develop games, but we never actually learn what we need to do and why. We desperately need to cover that weakness if we want to make game development less painful.

6. Have you studied the source code or design documents of other games, e.g. the Quake 3 source code? If so, what have you learned from doing so?

I've delved into the Quake 3 source code a bit, but that's a huge codebase to start with, and I didn't learn much.

I feel like it'd be best to start from the basics and learn by analyzing progressively more complex games. I have yet to find a series of open source games that satisfy this need.

7. What do you feel is the largest problem (or problems) in game dev these days? What do you feel could help alleviate these problems?

Related to my answer to question 1, I believe that the largest problem in game dev these days is the lack of a commonly-accepted "way" of designing a game, and of how a developer interacts with an engine/framework. In my opinion, we've reached a point where we need to take a higher level approach to developing and specifying a game, much like how other domains of software development have formalized their own common design patterns.

It would be extremely helpful to have engines focus less on how things get done and more on what needs to get done and why. I imagine in the future that there will be a sort of design language for game dev that takes a top-down approach to development, similar to test-driven-development or behavior-driven-development common in other dev domains.

8. Do you follow a design and iteration process, formalized or otherwise, for developing your games?

Nope. I'm still in the exploratory phase when it comes to game dev, and quite frankly I have no idea what I'm doing. Maybe someday, once I get more experience, but right now I don't even know exactly what has to get done.

Feel free to respond on your own time if you wish.

# ¿ Sep 12, 2015 15:25

Pollyanna: Mar 5, 2005; Milk's on them.

everyone posted:

Holy poo poo, I didn't think I'd get these many responses. Thank you! I'm realizing now that there's a hell of a lot I don't really know about the gaming industry and game dev in general. I thought I had my finger on its pulse, but that's clearly not the case. I've learned a lot from this!

# ¿ Sep 15, 2015 05:28

Pollyanna: Mar 5, 2005; Milk's on them.

Anyone here use Tiled with libGDX? I'm having trouble figuring out how to render my object layers. I get that classes like OrthogonalTiledMapRenderer render the tile layers for me, but I'm blanking out on how to do the same for object layers, especially for objects that have associated tiles (i.e. tile objects). Is there no out-of-the-box support for rendering tile objects? Am I supposed to make my own class and extend the abstract classes that OrthogonalTiledMapRenderer does? :psyduck:

I'm so confused.

edit: jfc

That is in fact what I had to do:

Java code:

package com.mygdx.betterbreakout;

import com.badlogic.gdx.graphics.g2d.Batch;
import com.badlogic.gdx.maps.MapObject;
import com.badlogic.gdx.maps.objects.TextureMapObject;
import com.badlogic.gdx.maps.tiled.TiledMap;
import com.badlogic.gdx.maps.tiled.renderers.OrthogonalTiledMapRenderer;

public class LevelRenderer extends OrthogonalTiledMapRenderer {
    public LevelRenderer(TiledMap map) {
        super(map);
    }

    public LevelRenderer(TiledMap map, Batch batch) {
        super(map, batch);
    }

    public LevelRenderer(TiledMap map, float unitScale) {
        super(map, unitScale);
    }

    public LevelRenderer(TiledMap map, float unitScale, Batch batch) {
        super(map, unitScale, batch);
    }

    @Override
    public void renderObject(MapObject object) {
        if (object instanceof TextureMapObject) {
            TextureMapObject textureObject = (TextureMapObject) object;
            batch.draw(
                    textureObject.getTextureRegion(),
                    textureObject.getX(),
                    textureObject.getY()
            );
        }
    }
}

Pollyanna fucked around with this message at 02:05 on Jan 11, 2016

# ¿ Jan 11, 2016 01:52

Pollyanna: Mar 5, 2005; Milk's on them.

I would rely more on communication between parts of your system than on those parts of the system reading and writing to a common file. Meaning, your current approach is probably best. Aside from that, I'm libgdx-retarded even though I like it so much, so v :shobon:

v take my advice with a grain of salt.

# ¿ Feb 5, 2016 16:48

Pollyanna: Mar 5, 2005; Milk's on them.

Crosspost from the Doom 2016 thread, but: Is there a comprehensive guide to or review of the original Doom source code, such that a relative newbie (~1year professional software development) can understand it? I've never delved into a large C project before, and the lack of a directory structure is throwing me off on where the endpoint into the application is, what the program flow is, what everything even is, and how it's organized.

# ¿ May 18, 2016 13:28

Adbot: ADBOT LOVES YOU

# ¿ Apr 20, 2024 02:47

Pollyanna: Mar 5, 2005; Milk's on them.

Cool, thanks! That covers a good chunk of what I was wondering about re: rendering. I'm not sure how much I need to worry about assembly level RAM-cache optimization in modern development these days, but I'm guessing I'd need to worry about it if I'm trying to replicate this in Clojure or something...?

I also have a kind of related question. When rendering game state, do you want to do rendering concurrently with updating the game state, or do you want to wait until the rendering is finished before advancing the game state, accepting input, etc. Basically, do you want the update->render->update loop to be sequential, or should rendering be a process that's called separately?

Pollyanna fucked around with this message at 15:22 on May 18, 2016

# ¿ May 18, 2016 14:52

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›2 »