• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Oluseyi

Members
  • Content count

    20657
  • Joined

  • Last visited

Community Reputation

2103 Excellent

About Oluseyi

  • Rank
    Contributor
  1.   Stick with PyGame. There is a tremendous amount of value in learning to solve problems in your given environment. There is also a tremendous amount of value in learning how to iteratively prototype and develop in languages like Python that offer a REPL (Read-Evaluate-Print Loop). Thirdly, there is a tremendous amount of value in learning different approaches/techniques embodied by different languages. A language like Python is deeply, trivially introspective, whereas a language like C# requires more elaborate reflection libraries to approximate the same; or Python's structural flexibility and preference for composition over inheritance versus C#'s object orientation orthodoxy. Over the course of your studies and, should you continue to pursue this professionally, career, you will need to work with and learn many different languages. Completing reasonably complex projects in different languages is a great way to build competence. Finish your current project in PyGame, then reevaluate and see if you want to move to Unity or something else for your next project. Good luck!
  2.   I did exactly this using what is now libav for MPEG/H.264 encoding 5+ years ago. What encoder are you using, @amtri, x264?
  3.   Ah, I see what you mean. Is this a 2D strip or a full 3D "tube"? I'll tackle the 2D solution now, and then we can extrapolate to 3D as necessary.   The key is that the red points define a line through the center of your strip, and that at each joint the red point is the center of a cross-cutting line whose adjacent angle is precisely half the deflection between the segments. So, starting from the left of your diagram and numbering the red points p1, p2, p3 and p4: at p1 there is no previous segment, so our strip's ends are perpendicular to the vector <p2 - p1>; at p2 the cross section is at an angle relative to <p2 - p1> that is precisely half the angle between <p2 - p1> and <p2 - p3>; at p3 we have no next segment, so our strip's ends are again perpendicular to the vector, this tome <p3 - p2>. Remember that perpendicular lines have slopes that are the negatives of each other.   Using the above, you should be able to generate the points in your strip. Be careful in your algorithm to maintain the correct vertex order. I'll check back in a couple of days to see how you made out.
  4. Unfortunately I can't run your demo because PyGame on OS X relies on X11, which I won't install, and my Linux box is temporarily out of commission. Nevertheless, I know what your problem is.     In your main loop, you do two things. You update the player position: player_pos[0] += player_speed player_rect.center = player_pos and you update the frame time, setting an upper bound on refresh frequency: frame_duration = clock.tick(FPS) # 1 frame -> ca. 16 milsecs The former assumes that frame_duration is constant, so it uses a constant increment for player position. The latter obtains the actual duration of the frame, which the PyGame docs tell us: "Note that this function uses SDL_Delay function which is not accurate on every platform…"   Your problem is that you are applying what you think is a constant displacement per constant time, yielding constant velocity, but in actuality your time is variable, making your velocity variable. To smooth it out, normalize your displacement by your actual frame time: FPS = 60 player_speed = 0.8 # pixels per frame basis_frame_time = 1.0 / FPS while 1: # ... frame_duration = clock.tick(FPS) frame_displacement = player_speed * (frame_duration / basis_frame_time) player_pos[0] += frame_displacement #... That should do it.
  5.   The fate of these causes is never "decided," anywhere. Change is individual, aggregated. That's why discussion about them is so important: because it's the vector for that individual change.         The rules are the rules. I shall abide them.
  6. Isn't that what is the accepted answer here?   Yours is a dictionary wrapped in a function, isn't it? If you're writing configuration purely for a Python program, why not make Python itself the configuration language? It's only worthwhile to invest in a different configuration format if you have to share it with other environments.
  7. I'm confused. Per my understanding, a polyline is a series of connected line segments—a polygonal chain. It can exist in 3D space, but it does not intrinsically define any surface, let alone volume. To want to make one out of triangles them strikes me as impossible, nonsensical (in the literal, non-disparaging sense). I'm sure this is a communication breakdown, so can you elaborate some more on what exactly you are trying to say?
  8. He's talking about beta versions of iOS, not beta versions of apps via testflight. And yes, they did remove the ability to rate any apps while running a beta version of iOS, but they only did so about a week back, in response to the wave of one star app reviews Oluseyi mentions.     Yep.
  9. First off, it's generally bad form to embed print statements inside a function that returns a value. What if I want to call it in a non-console context? Given Python's native tuples, you can return both the constructed object and an error string—or, even better, raise an exception on error.       The general use for keyword arguments is cases where some of them are optional. That way you don't have to provide a bunch of None values for parameters you don't care about.
  10. I've never liked these rules, and I've never liked the US-centric tech industry's cowardice about tackling them head on. I'm going to go out on a limb and say that 90% of the time the root reason for locking down discussions on identity issues, on these forums and elsewhere, is simply people's "discomfort" in talking about them. That's really convenient if the status quo doesn't actively harm you, but for those of us who do face constant risk and threat of various kinds, it's not a very impressive reason. I have a three-year old son. Just about every week in America, someone who looks vaguely like my son might when he gets a little older is killed by (sometimes self-appointed) authority figures. I look around my technology organization and virtually no one else who looks vaguely like me is in a position of core technology implementation, decision making or strategy. They're all in sales/marketing, QA or occasionally design. Every time I see a picture of a startup or technology firm's "technical braintrust," I count the number of faces that look vaguely like mine. 95% of the time the answer is zero. You're telling me that all of that is irrelevant, that it doesn't affect the products we create, the games we make? That the homogeneity of perspective in the creators doesn't bleed into the product? That critiquing the oversights in the product is not valid because it makes some people "uncomfortable"?     Let me tell you a story that involves GameDev.Net people—staff—whose names will be withheld. One year I brought my then-girlfriend with me to GDC. At this point I had been involved with GDNet for about 5 years, and attended GDC and met the other staff at least once or twice Sitting at a table with a bunch of GDNet people, one of them, A, started talking about my skin, and how "black" I was, and how you could only see my teeth. Now this is a problematic, often offensive characterization even within the black community, because darkness of skin has been used as a pretext for all kinds of discrimination (see: brown bag parties, for instance). My girlfriend was furious, but it was her first time meeting them so she didn't want to create a scene. Another staffer, B, has some black ancestry, and they were clearly uncomfortable as well, and at the next available opportunity they chipped in their 2 cents about identity and bias.   To insist that we can't talk about these things because they sometimes get uncivil strikes me as choosing the easy way out. Plugging your ears and claiming the silence means nobody is complaining. The ways that people act are often fundamentally uncivil, and we need to be able to point that out and grow, collectively, as a consequence.     I've been talking about race, but it's the exact same thing for gender or sexual orientation (where I am of the dominant class). The furor over Anita Sarkeesian's Feminist Frequency project suggests staggering ignorance not even about feminism and gender issues, but about media criticism. (Seriously. Read Mulvey.) How do we rectify that if we can't talk about it? And saying that, "Well, THIS isn't the place for it" just makes this a refuge for those who don't want to talk about it. The nature of a community is that it creates the familiarities in which people are willing to extend to each other the benefit of the doubt necessary to make contentious conversations potentially profitable. Absent that context, you get Twitter's instant devolution to death threats. This is exactly the place where these topics can be discussed productively.   »shrug«
  11.   You have to look at distribution per unit area. In this case, what percentage of shapes have more than 50% of their neighbors being the other shape. In the real world it's the high degree of ethnic concentration you see in some cities/neighborhoods, plus the low degree of interaction between adjacent ethnicities.   In any case, the essay/experiment establishes its own criteria for "diversity," and so the question is whether the above board fulfills it.
  12. In that case, you are agreeing with the Parable of the Polygons that the absence of bias is not sufficient to increase diversity. Whether those "other factors" are an explicit demand for diversity by members of the population or legislative requirements or quota systems—passing no judgments on the morality or efficacies of those approaches—they represent more than the absence of bias as a means of engendering diversity/fairness correctives, even in a world where bias is still routine.     Bias is not inherent negative, it is merely a distinct preference for one outcome. We can consider some biases negative, such as being shape-ist in this example, or racist/ageist/colorist/sexist/etc in the real world. We can consider some biases permissible, as long as they are disclosed, such as my bias toward believing in systemic and structural defects in our society that lead to unequal outcomes.
  13. You both make the same argument, but you both gloss over the fact that our communities are, and remain, highly segregated, and that "white flight" remains a very real, present phenomenon. Sure, it's a simplified model, but if its correlations are that strong, perhaps the other "outside forces" that you imagine (which we should enumerate and discussion, if you're up to it) aren't as impactful as you might think?   I freely admit my biases here: my own life and experiences incline me toward believing that the status quo is not just a random outcome of unrelated constraints, that intent and reaction are factors. If you have even a simplified mathematical model that argues otherwise, I'd love to see it.
  14. ... that phrase makes no sense. duck-typing is an _application_ of polymorphism, not an alternative to it. It does if you understood swiftcoder's phrase as taking a C++-centric notion of "polymorphic" as "concrete types sharing the same inherited ancestor, which is the locus of said polymorphism," as opposed to "types fulfilling Liskov Substitution Principle for the given context." Above all I was trying to say that these types need only share the interface(s) exercised in the aggregated dispatch context (loop body), and no others. If that wasn't his intent, however, then I apologize and you can ignore my comment.
  15. Not exactly. Remember that Python is an aggressive/enthusiastic user of duck typing, so non-polymorphic types that nevertheless expose the same interface can be operated on as a coherent collection.   #Python 2.7 is still my system default; i should change that... L = [(1, 2, 3), "four", [5, 6], {'seven': 8, 'nine': 10, 0: 11}] for item in L: print len(item) # valid for any sequence type print i[0] # valid for any subscriptable object: implement __getitem__() Presumably you have aggregated your objects into a list because they are somehow conceptually related. That relationship should inform your naming. Their concrete types are not exactly irrelevant, but by far a secondary concern.