My tutorial series: #2 is up.

Started by
14 comments, last by PnP Bios 19 years, 12 months ago
I finally took a glance at your tutorials as well. If you would have created them about 3 years earlier, I''d have been really really really REALLY very grateful .
Seriously, I bet someone can make good use of your tutorials. If you change the layout (already mentioned in previous posts, so I won''t repeat it here), there''s nothing left to improve. Also, the "printer-friendly" version is extremely useful, I always like that, since I prefer to print articles.

Nice work, just go on like that!

The triangle thingie sounds nice, I''m sure there''s demand ''round here...



Indeterminatus

--si tacuisses, philosophus mansisses--
Indeterminatus--si tacuisses, philosophus mansisses--
Advertisement
I can see this tutorial being useful to people who are new to game development, and resource management in particular. I''ve seen a lot of questions on the boards about "how do I store all the things that go in a game"...

However, I strongly disagree with this statement: "Because a monster is so different from a bullet, or a shield pack, I highly recommend against having a common interface for game objects."

At a glance this makes sense, but you''re painting yourself into a corner. What if, later on in the development, you decide that a bullet should be able to interact with a shield pack too, not just the monster? Now you''ll have two kinds of things to look at for collisions, and it becomes a nasty hack as your game becomes more complex.

A better idea is to have a base entity class that contains all the common parameters like location, velocity, size, whether it''s solid or not etc. All entities are derived from this base class, with their unique parameters (the things that make a monster different from a bullet) added. Any entity can then physically interact with any other entity, while their reaction to that interaction depends on what they are. What''s more, the same bit of code that moves the player will also move the bullets and monsters. Ideally you''d then only need to change that one part to plug your game into a physics engine of your choice...
I see some reason to your logic, Fingers_. I am working on a clone of missile command, and too many of the objects have similiarities to ignore. I do like your idea for a base entity class, if only for working with physics. But for the tutorial, I will have to stand with my point of view. If I were to incorperate that into the tutorial, it could have easily doubled in size. At the bottom I believe that I told the reader to go ahead and do a base class if they feel comfortable.

To everybody:
Other than the damned red text, what other changes do you specifically reccomend? I have a 20 meg limmit, and I want it simple for quick load times.

thanks
HxRender | Cornerstone SDL TutorialsCurrently picking on: Hedos, Programmer One
I see you''ve made some changes to your code-text now, and it looks much better. Some things you may want to keep in mind are:
*subheadings (only really if you do any longer tutorials, the current ones dont really need it).
*glossary (some people find these helpful, but its not a neccesity).
*references (if you use any in the writing, sometimes it helps people to understand more if they can read these).
*further-reading links (not a neccesity, but nice to have).

- Jason Astle-Adams

updated the site again. I made it even more simpiler. There are some issues with the internal hyperlinks, but that will get worked out eventualy. I have decided that my next tutorial will be an introduction to pointers and how to use them.

Why did I make my site so simple? Content should be the main atraction, not purty graphics. Plus, I have a heart for anybody still using Dial up. I will fix the links when I put up the next tutorial.

peace!
HxRender | Cornerstone SDL TutorialsCurrently picking on: Hedos, Programmer One
I like the simplicity - the focus on content is a good idea, as is the decreased loading-time for dialup users.

One thing... your table seems to be only using up part of the screen (presumably for readibility 800x600 resolution screens). While this readibility is good, it means that extra space on the right is going to waste on higher resolutions. By using percentage values, you can have the table cells stretch out to use up all avaliable space. Note that you could still use a fixed value for the navigation bar on the left, so that only the main content is resized.

Once again, this isnt actually something necessary, but it might help increase readibility on higher resolution monitors.

Oh, and if you want, you could consider using an externally referenced Cascading Style Sheet for your site. This would allow you to have nice formatting (still nice and simple), without a performance hit, and loaded only once for your whole site (56k friendly ), as well as to help maintain a nice consistent look throughout the site as you add more pages. You can make changes to a CSS file linked in this way and update the look of the entire site from one place, and you wouldnt have to put so much formatting information within the document itself (WHOO!! less coding ). A decent CSS tutorial can be found here, and CSS doesnt take very long at all to learn and implement, and can save you plenty of time in the long run as your site expands. [/CSS plug]
(heh, and I''m not saying you must use CSS, or even should, just presenting it as an option (but trust me its a pretty good one )).

- Jason Astle-Adams

This topic is closed to new replies.

Advertisement