Sign in to follow this  
  • entries
    8
  • comments
    10
  • views
    7451

A little housekeeping and a plea for advice.

Sign in to follow this  

235 views

Admittedly, this update comes much later than I would have liked. I have been working as much as possible on an asset management system for the Essentia Engine, but I've had a lot of distractions of late. Both the semester and my rotation at Cisco are coming to an end, so I've had a lot of tying up loose ends and final preparations to keep me busy.

Nonetheless, I did manage to get a little bit of work done on Essentia, though I don't have much to show for it. To begin with, I have created a CVectorMap class, which uses two std::vectors to create a templatized map container which performs an insertion sort as you add items to the container, and uses a binary search to access said items in a timely fashion. The identifier is a char* array, which lets you do cool things like order frames in a sprite animation simply by naming them something like "FRAME1", "FRAME2", etc. This also allows me to implement a global asset management system, which keeps track of all the assets via their string identifiers.

The asset system takes care of all of the memory management for all CObject, CSprite, and CImage objects. This is much simpler than what I'm currently doing - my placeholder Main.cpp is garbage. But we'll worry about that later.

The asset system is still highly in development and refinement, so I am loath to say anything about it because I guarantee that it will be completely rewritten several times before I'm happy with it. So for now, let's just say its a work-in-progress.

And that's about it. Now that I have enough of the engine finished that it is actually beginning to have some form, I realize that it needs a massive organizational makeover. First engine...lots of mistakes. But hey, at least I'm learning, right?

Hopefully, I'll get a lot of development time starting this weekend and extending throughout Christmas break. My little brothers are on my case, asking me when I'm going to "hurry up and finish the engine so [they] can make their game." So I'm under a little bit of pressure. :)

For now, I am focusing on organization - which is work enough in and of itself. I feel that I need to create some kind of outline for this beast, or else I'll get lost in the code and lose sight of the big picture. I'm hoping that sectioning everything off into dedicated modules will help things a bit. I'm thinking of creating an asset module, graphics module, physics module, application module, and eventually a sound module.

Who knows, I might just ought to diagram the whole thing out. If anyone has any suggestions, by all means please instruct me - I'll definitely take whatever advice I can get.
Sign in to follow this  


5 Comments


Recommended Comments

Quote:
Original post by PixelOcean
If anyone has any suggestions, by all means please instruct me - I'll definitely take whatever advice I can get.


Drop the 'C' prefix from class names.
It doesn't make things clear and really screws up things like Intellisense and other tools (certainly if you generate any docs from the source code).

If you have warts on your variable names as well then drop them, if not now then in the future; variable names should be descriptive of purpose and not contain any type information as they become invalid as soon as the type changes.

Share this comment


Link to comment
Wow...that's going to be a radical change. I've been using that naming convention since I started programming (a little over three years)...I always thought that was good practice.

It seems to me that appending the type identifier as a prefix is a quick way to just look at the variable and immediately know what you can assign to it. Is this not correct?

I guess I just never stopped to think about it...hmmmm....

Thanks for the input, by the way. If this is something I need to change, it's good that I catch it as early as possible.

Share this comment


Link to comment
Quote:
Original post by PixelOcean
It seems to me that appending the type identifier as a prefix is a quick way to just look at the variable and immediately know what you can assign to it. Is this not correct?


Back in the days of C this was probably a good idea, however these days it's considered pointless due to things like intellisense which will tell you the type quickly enough.

The type also shouldn't be a huge issue; decent naming convention can do more to aid you AND if you change the type you don't have to go searching all over your code to change the name. In some cases the compiler will catch the errors for a type change, but in other it will be more subtle (float vs int for example).

Share this comment


Link to comment
Quote:
Original post by PixelOcean
Wow...that's going to be a radical change. I've been using that naming convention since I started programming (a little over three years)...I always thought that was good practice.


I think it is a good practice -- both have their pros and cons. You'll find plenty of coders on either side of the fence when it comes to coding conventions. Those aren't the things you need to worry about.

Consider your engine in layers of abstraction, starting from the top. You're totally right in considering things like assets/graphics/physics/sound as separate modules, which is the first step to breaking the large notion of an engine up into several smaller components.

Try drawing up a specification for what these modules are supposed to do, in as much detail as you'd like. You could start with just general functionality that they should have, and move into actually considering what functions, classes, and data structures they will have.

These modules don't need to necessarily be fully independant objects, so also consider how these modules will need to work with eachother. Consider what dependencies Module A will have versus Module B. Will the Graphics module need to pull its drawing resouces from the Asset module? How will interactions between these two modules work, then? A common asset database shared between them? Should sounds also be assets? How will it integrate with the Sound module?

Keep asking yourself questions like this, thinking about specification and dependencies. Continue breaking these modules up into smaller pieces, slowly focusing on the inner details of how they should work. Try to consider more than one solution to each problem, and don't be afraid to throw out ideas that seem unwieldy.

Lastly, don't be afraid to look at existing code. There are tons of 2D and 3D engines with source code freely available, so take a look at how established engines do what they do. Looking at existing code is an excellent way to get a feel for how you might want to design your own.

Best of luck with your engine! [smile]

Share this comment


Link to comment
Quote:
Original post by phantom
Back in the days of C...


You make it sounds like the days of C are over!

Funnies aside, there is something to be said for being able to glance at some code and get, in the very least, a general idea about what a variable represents.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now