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

Outworlder

Frontier:First Encounters(or FE2)

4 posts in this topic

For anyone that knows one of these games, I have some questions. First, they ran fine in a 386, at 320x200 (a ridiculous resolution nowadays, but more than enough for the time) and have textures, flat shading, some transparency effects, and a huge galaxy, with very complex solar systems. Not to mention the physics... My question is, how the hell they have managed to do that? I''m pretty certain that, If I could implement the same thing in OpenGL, without a powerful hardware accelerator(mind you, at a higher resolution, like 640x480) I would not get a decent performance. But they did that in software! I know they sacrificed resolution, texture detail (after all, the original game took 3 discs) and probably used a palleted mode. Another question... the near and far clipping plane. If I have a planet 60AU away(I''m using Frontier units, think of this as veeeery far away...) the planet should be invisible. So far, so good. But I cannot draw the planets this way. When the planet get closer, It should get bigger on the screen. But wait, the planet has been clipped by the far clipping plane, so it is invisible. Only when its extremely close to you it''s polygons will start popping on the screen. How to avoid that? I believe you can put the planet very near to you (in opengl coordinates) and resize the planet as needed. But this is a complicated solution. Is there another one? Gaiomard Dragon -===(UDIC)===-
0

Share this post


Link to post
Share on other sites
Assembly... lots of and lots of assembly. It can do wonders.

For your next question, just set the planet as far away as possible without it getting clipped, and if it doesn''t grow the way you want it to when you get closer, just scale it.

------------------------------
Trent (ShiningKnight)
E-mail me
Shining Darkness- A division of Chromesphere Studios
0

Share this post


Link to post
Share on other sites
Humdinger of a question ...

Firstly, due the the sheer distances involved, using built in (c/c++) data types is insufficient. for example:

int 64 = +/-9.7 lightyears, with a resolution of 1 millimeter

Now, in terms of galactic scales, this is totally insignificant, depending on what you are trying to achieve.

I''m doing a similar thing right now, but i want to be able to use one coordinate system for an entire universe, so it''s possible to fly from one star to another, without the need to ''hyperspace'' between them. It will also show accurate star positions from any position in the universe.

the only way to do this, is to use your own large data types. I''m going to be using signed 96 bit itegers, which give a universal scale (accutare to 1 millimeter) of:

+/- 48,873,004,216 lightyears

Now that''s accurate enough for everyone!

However, serious clipping problems can come into effect if you''re not careful. To avoid these problems, disable all depth buffering when drawing stars, and distant planets, and re-enable it for close planets. just make sure you draw the furthest planets first. To further enhance depth buffer usage, you can also change the near and far clipping planes to suit the distance a planet is away from you.
0

Share this post


Link to post
Share on other sites
ShiningKnight,

Well... I''ve seen what assembly can do, in the hands of an experienced programmer... just take the game Frontier is based upon (Elite). It ran on my MSX, who had a memory capacity of 64kb total, powered by a less than 4 Mhz Z80 processor (8 bit registers), 16 kb of video memory(it used a graphics processor, so the cpu wasn''t on charge of updating the display every refresh). It was the first time I saw 3D graphics on a personal computer (Polygons, no filling). Ah! Even particle systems!

Shag,

Fly from one system to another? In your universe, does the lightspeed barrier apply? Even a flight from our position to the nearest star at lightspeed would take more than four years...

As for the clipping problem, Frontier uses bitmaps for objects very far away... "popping" is very noticeable, but it gets the job done quite nicely.


But what if I want to make things more on a scale? I''ve noticed that the stations on that game are not as big as one would expect, compared with the size of the ships (but they still look convincing). The stations could be so big that I couldn''t fit one inside the view frustrum. Of course, this is not an issue with just this kind of game; if I make an 3D RPG and I want to render a big landscape I may not be able to display it all. Of course, fog in space is not an option



Gaiomard Dragon
-===(UDIC)===-
0

Share this post


Link to post
Share on other sites