• 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.

Archived

This topic is now archived and is closed to further replies.

javanerd

[java] Reinventing the Wheel, Anyone Interested?

17 posts in this topic

I've been aware of the problem with programming for different Java versions for quite a long time (I've followed Java from its first 1.0 alpha releases)... But just recently it hit me that I'm writing a game programming library that is supposed to allow you to program for different Java versions. That means that I should propably somehow offer a unified class library for all these different libraries, right? And after that came the obvious realization that one could actually make better (faster & less memory consuming) implementations of many of the default Java library classes. E.g. one article in Gamasutra website ponders around this subject: Dirty Java - Optimizing Pure Java. And lot of the statements made there are true: multithreading under Java games is overkill due to expensive synchronization, Unicode strings are huge and slower to process than the simple ASCII ones. So how about it, anyone interested in participating in this endeavour? We could make this library a separate package from my GameFrame library just to make it usable to larger audience, but I'd like to keep it open source so that anyone can go ahead and integrate it to their game or customize the thing to their hearts content... This project would go where no-one has ever gone and it would offer great opportunity to familiarize yourself with the dark side of Java programming: optimization. Which actually should happen before any code has been written I've got a few links (besides the one above) to sites offering Java optimization tips and tricks. I'll post them here if we get a big enough group behind this. Edited by - javanerd on 2/16/00 12:48:33 PM
0

Share this post


Link to post
Share on other sites
Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).
0

Share this post


Link to post
Share on other sites
I''ll have to disagree with much of what was in that article, yes unicode is going to be a bit more cpu intensive to process, but the overhead in threads is far outweighed by the performance boost they give you. And there are unsynchronized data structures in java, you just have to use something besides Vector.

As for rewriting java source... not for me.
0

Share this post


Link to post
Share on other sites
Unicode strings are huge and slower to process than the simple ASCII ones.

I read somewhere that *they* will make dual ASCII/Unicode, but hell, i''m not sure if it was somewhere on "JavaMegaSpeedBoosterMCXIV the most reguested implementation to Java" web pages, there is many of them, too ;-)
0

Share this post


Link to post
Share on other sites
Unicode is not the real problem with Java strings. On most modern architectures, dealing with 16 bit characters instead of 8 bit characters is not going to break the bank.

The problem with Java strings is that they are immutable objects - every modification done to a Java String object causes a new instance of a String object to be created.

so for example the following line
String a = "one" + "two" + "three" + "four";

involves the creation of 7 string instances:
"one", "two", "three", "four", "onetwo", "onetwothree", "onetwothreefour"

But Sun has a solution in the JDK - the StringBuffer class. If you are doing heavy string manipulation, you should use the StringBuffer to store intermediate results. It''s syntax is not as convenient but it performs better.

The overhead of threads is more of a platform-specific and VM-specific kind of thing. There are different implementations (green/user and native), and each platform has its own overhead for thread creation.

Generally, the overhead of synchronization also depends on the VM''s implementation. Clever implementation of monitors can make the overhead of the noncontested case as little as one instruction.




-vince


0

Share this post


Link to post
Share on other sites
I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.

But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.

Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.

Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.

Just my humble opinion.
0

Share this post


Link to post
Share on other sites
If you''re going to do it, I would suggest finding a site that is devoted to custom java implementations and post about it there. I''m not saying don''t post it here, I''m saying that it might help keep you motivated. Something like www.gnu.org or jfa.javalobby.com
0

Share this post


Link to post
Share on other sites
quote:
Original post by joeG

Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).


"STL-like package"? Are you referring to the collections framework that is included with Java 2 or is there another package thingie I haven''t heard about?

Datastructures are a good starting point. I had in mind some of the classes in java.util and java.lang packages that are essential to game programmers, but have been changed between JDK 1.1 and 1.2.
0

Share this post


Link to post
Share on other sites
quote:
Original post by Jerry Lynn

I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.

But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.

Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.

Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.

Just my humble opinion.


Hmm, your message really gives me something to think about.
But if you look at the way the Java VM has changed during the last five years, it really hasn''t. SUN has kept it their goal to NOT change the VM if it isn''t mandatory. The bytecode is still the same, just some class file flags have been added, but even then backwards compatibility is preserved. So if I wrote my own set of classes from the ground up I think I could rest assured that they''d work on the future Java VM''s.

The idea of these replacement classes would be to make the game programmer free of the runtime JDK version problems. Of course that would mean settling to some subset of the JDK classes, but that is to be expected. What this would mean is that the programmer wouldn''t have to worry about the tiny (and oh so annoying) differences between the JDK classes.

The idea behind GameFrame (as it is provided) is to offer easy access to game programming and to enhance the experience under some runtimes. That means I''m targetting the hobbyists, beginners and the like that don''t want to spend half a year just making some graphics engine to work. And believe me as a hobbyist myself, half a year is quite a short time for this kind of thing and you need one more half-a-year to make sound work both under JDK 1.1 and JDK 1.2. Many of my own projects have ended prematurely just because I got fed up with making the low level things to work. The only reason GameFrame exists is that I haven''t been aiming at making a game, but a library and I''ve had my previous source codes to draw upon. Trying to reach both targets (game+engine) is too heavy requirement for many. Doing a game is difficult task in itself (idea development, planning, graphics, sounds, logic etc.).

If someone wants to use GameFrame with e.g. Magician or Java 3D they can do that if they just get inside the source code, but that really requires a whole different level of knowledge. As is required by the aforementioned APIs anyhow. It would be next to impossible to implement as flexible game library that one could use it with everything under the sun (no pun intended ).
0

Share this post


Link to post
Share on other sites
Yeah, that's what I meant: "collections" Okay, so you want JDK-cross compatability, right? If the amount of dependencies of these collections classes is minimal (i.e. helper classes, inner classes, etc...), than it should be easy to just include those classes in your distribution, allowing you to use what has already been made. But say that the extra dependency classes will make the distribution too large. Then I guess I'd understand the need to redo the wheel.

BTW I am still interested in the project ('course I don't want to spend too much time on it either )

JoeG

Edited by - joeG on 2/17/00 1:55:35 PM
0

Share this post


Link to post
Share on other sites
The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM
0

Share this post


Link to post
Share on other sites
Hey JavaNerd, I am just a newbie, but I like the sounds of your project. I don''t know if there really is anything I can do but if I can help you I''d be glad to.



-The beatings will continue until morale improves!
0

Share this post


Link to post
Share on other sites
Just e-mail me if you are going to do this project.

BTW I already have some Java data structure classes based on the publisher Bailey's Java book. Can't think of its name right now. Vector, Queue, Stack, Binary Tree. They are all structured together very nicely. I think the best part of the project will be figuring out how all these 'different' classes will work together: i.e. some generic interfaces and classes.

Keep all of us informed,

JoeG

Edited by - joeG on 2/18/00 1:11:48 PM
0

Share this post


Link to post
Share on other sites
Great! It''s good to know there are some interested persons out there. I''ll have to delay the startup to next weekend, but I''ll inform you then (via eMail).
0

Share this post


Link to post
Share on other sites
quote:
Original post by Jerry Lynn
The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM

Yep, you definitely sound a "bit" pessimistic but then again I''m often a "bit" too optimistic.

But I''ve just got to say that many of the classes I''m talking about are not interdependent. E.g. Vector and Properties are quite stand alone classes. Vector uses arrays internally which in my opinion might not be the fastest choise (because array access is so slow under Java). Properties has changed inbetween JDK versions annoingly. These are just two classes, but they are good examples of what is has gone wrong IMHO with Java. It has grown to be a Jack Of All Trades and thus many of it''s classes aren''t that usable for game programming or aren''t usable for multi JDK (1.1 - 1.2 - 1.3) programming.

I chose the "black box" approach as it really is the only way to approach making of several implementations of the same thing. So my game programming library doesn''t allow the user to subclass the concrete implementations. Heck, the user doesn''t even know which implementation the application is going to use at runtime. But that is just the beauty of it, you can have several (even native) implementations specific to different platforms and get the benefits of increased speed or fullscreen graphics etc.

The original reason why I started with all these different implementations was that I just wanted to have fullscreen graphics and ended up doing an Asteroids emulator that used different sound & graphics engines under JavaSoft JDK 1.1 and Microsoft Java 3.0. Then Java 2 came around and I noticed that the sound API had been changed (from the application point of view) and I had to implement a sound engine for that also. And so I noticed that maybe I should do all this stuff in some generic way and publish it as a simple 2D game programming library for the masses.
0

Share this post


Link to post
Share on other sites