Advertisement Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    34
  • comments
    36
  • views
    15805

About this blog

The journal of nano size but tera quality. Sometimes.

Entries in this blog

 

3D engine? Panic not!

So, its been a few hours since I last made a post in my journal but screw it; its a new day here in england and I still feel as shit as hell (interesting concept there).
On monday I picked up a really nice virus from my Deli-Krew-Mate Vicky- i think its a subset of flu because it has acheing limbs and temperatures. I keep sweating the damn temperatures down but then they come back. Oh well, means I got time to sit home reading up on random crap instead of going off to work.
After quite a bit of (legit for once) drugs I do feel better and can manage some coding [smile].

Anyway, I'm gonna stop complaining.

I was looking at a few other blogs and reading through their engine woes and stuff. It got me thinking how I was actually approaching such a complex project as a 3D engine. I wondering if anyone else followed this idea with their engine (if this is their first engine):

I don't look at the engine as a whole- ofcourse I have an idea of what I want out of it in the end and the features I need. However since this is my first engine I don't know how to do every feature. So instead of overloading my brain and thinking 'shit, how am I going to code all this' and panic and then lose interest I am taking each section as it comes. For instance, first I wanted to load up levels but what type of level? a 3D level. What type have alot of documentation and a loader/renderer already in place to base ones code on? BSP- its quite simple to load the initial level but collision detection can be a real pain in the arse. Luckily there is code in place and I can go back to collision detection and properly understand it when I need to.
This tool also taught me fonts and how to display different kinds of fonts on the screen and how to make a font code base.

So now I have my level and loader/renderer sorted out- thats now my 'world view' tool. A complete program in itself. What next? Well, I wanted to get the mesh code sorted out so I went to look through one of my Game Programmers books and found MD2 code for meshes- its good because theres documentation and I can update it to MD3. So I made a seperate tool called 'Model View' that loaded MD2 meshes (havn't upgraded it yet). This app also used the font code base from the 'World View' tool to display information.

So I had a mesh view tool, a world view tool, what next? I felt I needed more control over the engines environment (change system variables, load meshes and BSP levels etc.). What better way to control the engine from inside the engine than a developers console. So I made some graphics for it and decided what the initial commands would be for the console. I came up with an input method and a logic system for the console that allowed full control over the environment. So now I had a fully working, independent, class based code base for a console that I then incorporated into my other tools to display debug information, dump error messages and allow me to contol the world.

So now I wanted to make a fully working GUI to easily display information and edit information. Once I got a basic window system with a button widget and label widget to display and work as it was meant to in the 'World View' app (since thats the main basis for the rendering of levels) I wanted to make it more powerful. I wanted to be able to control windows in an external resource to import into the engine since engines are meant to be totally modular by their very nature. So I created a file type that had a template on loading in information for the window to display so the engine could just query the resource instead of having it hard coded. This had many benefits including not having to recompile the engine everytime I wanted to change a window and also allowed for the next stage.

Now I had made the initial primitive GUI system work on a modular resource engine I decided to make the creation of windows easier. So the next natural step would be to make a GUI editor which is where I'm at at the moment (see my pervious post). I can edit windows with my GUI editor and have my World View tool import them when needed.

I'm sorry it was a bit long winded; I got a little carried away. What I am thinking is, is my method the same as most of you out there on their first engine. I take each section of the engine, make it into a little program and in that way I am making it into a whole learning experience. Before I started, I had no idea how to display fonts, make GUI etc. but because I'm taking every aspect of the engine, no matter how small, as one little code base and one little application I am breaking it down and making it easier to learn and code. I am not looking beyond the current section of the engine since it is a project unto itself. However, once I finish a code base I incorporate it into all the other tools of my engine so I know they all work together without problems.
This way i'm not in a panic that I have so much to learn.

Just to lighten the heaviness of this entry...heres a manga hitlar (created by the Face Transformer and Rob Loach's hand picked image of Teh Hitlar Himself)


MotionCoil

MotionCoil

 

uber-optimize me!

Hey all

I have just finished doing a bit more to my GUI Editor. I have currently got it so the edit box widget will only display enough characters within the widget to fill the display area- a bit like windows edit boxes when you have a string longer than the edit box can display so it cuts off the end. Anyway, difficult to describe but very useful.

Once I finished that, i started on the tool bar for my GUI Editor- naturally I started editing it within the editor itself to make life easier.
The toolbar consisted of 7 labels and 7 edit boxes and the normal sys.Stak window style. However after about 3 minutes of using the editor with those widgets loaded it crashes and tells me i'm out of memory. I wanted to investigate further; I opened up Task Manager when it was running and was shocked by a peak memory usage of around about 350MB. Jesus Christ Almighty in a satin nighty!

Anyway, this has urged me to get down to some heavy optimizations!

nothing much else happening. Just a load of work and programming and I got some guy stalking me but thats about it.

-kYm

MotionCoil

MotionCoil

 

Mission: Slimelight

Hey dudes

Well, I have been up since 0530hrs (I was doing the Deli open up at work) and I got slimelight again tonight.

Slimelight is an alternative club up in london full of Cybers like me (Yea, i'm a freak of fashion and have a shed load of cyberdog clothes [smile]). This club is open from 2230 till 0730 which means you need a hell of alot of caffeine or in my case a few other things [wink]. So its a long day for me.

Anyway, i'm gonna request loads of hardcore from DJ Promo and Neophyte and stuff. Do any of you have any other suggestions?

Well, if I'm still alive tomorrow I'll update on how it went [smile]

Catch you later people!

MotionCoil

MotionCoil

 

oh no!

Just said goodbye to my gf. shes going for 2 weeks to the british virgin isles. I'm gonna be a wreck without her :(

The plus side is, I will actually be able to really work on my engine for the next 2 weeks [smile]

oh, and I treated myself to a new mobile phone to keep my spirits high: T-Mobile MDA Compact
I've seen it in action and its a beautiful beast[smile]. Apparently it will arrive tomorrow...cannot wait!

Engine Update: I've done pretty much nothing apart from start writing a wrapper for MD3 models.

MotionCoil

MotionCoil

 

Boot.stem

Boot.stem


Like I said in my last post, I am getting the foundations to a C-Like scripting language in place as the native scripting language for the engine. There are several reasons why I decided to go head first into a making it C-Like:
1- Its easier to write scripts in since it looks a bit like the rest of the engine
2- Its easily imported into Visual Studio with the formatting
3- I wanted to make something familiar in general

Anyway, heres the first CellScript stem file (insane terminology, but i'm having fun- Language is CellScript, each file is called a stem file... cell... stem... stemcell (haha)). This shot shows it happily imported in Visual Studio (and the script works which is a bonus). This script is the custom boot script that is executed when the engine runs through its boot up:


Heres the joy- anyone used to C will be able to follow whats happening [grin]

The language is quite basic at the moment but is progressing faster than I expected. At the moment its parsed directly but I do have plans in making it so you can semi-compile it into op-codes in the future.

I'm quite pleased with it so far though

MotionCoil

MotionCoil

 

Behold

Been a very, very long time since I last posted. I've been too wrapped up in my degree.

However, my mate and I have decided to work on a game. I've scrapped my old engine and started on a new one and hes doing most of the models and art.

Anyway, I always get a rush when I first get the blinking cursor of a console.

Heres the NanoStem Platform, first blinking cursor:


I'm using a lot of the technology I created when working on my old engine. The console is the same for instance, but I have been rewriting it so its far more efficient code wise.

(Oh, the console's background is mine- I'm quite proud of it actually [smile])


Anyway, good to have my journal back up and running

-Charlie

MotionCoil

MotionCoil

 

Reformatted

Reformatted


Welcome to my reformatted journal!

Reformatted? It looks like my other entries. That may be true from a cosmetic point of view, however I have changed the way I view my journal- thats the reformat.

From now on I'm not going to update the journal every now and then based on Nanostem developments but also from what I have personally learnt about the whole development process from experience with Nanostem but also from other sources.
Yes, you may well be saying there are lots of journals on here that do just that and there are loads of developer blogs but from my point of view this is for me to look back on. Partly to see progress and also to review and re-establish knowledge.

The one achievement I have taken great pleasure in retelling is the fact I changed my girlfriends view of games and their development as something that is void of creativity and results in something of a pointless nature. From that point of view (which, might I add, was almost unmoving) to a view that yes, games are an artform in themselves, in their own right. That was a proud turning point and hopefuly I will bring that, along with my fellow GDNet'ers, to a far wider demographic. I have no doubt that many if not all of us are wanting to see games respected; not from the units sold to the unwashed masses but as something as critically viewed as movies, novels and paintings.

Along the same vein, I regularly discuss the latest things I have learnt and appreciate in games design and implementation with my mother on dog walks (what better place?).
Recently I played HL2:E1. Then I replayed the entire thing with commentry nodes on. I really like this idea since in a small way its provocing peoples ideas of games as an artform. I learnt ALOT from the commentary nodes in Episode 1 (if you haven't replayed it with commentry nodes- Do. It.).
One commentary node stays in my mind- when you come out of the subway thingy (with the missing handle to open the door) and you emmerge to a scene of apocalypse with the citadel dead centre. The node explains how nothing in that one player view wasn't postioned willy nilly. It was 'painted' to make sure the players eye gazed over the destruction, a strider jerkily negotiating the rubble it created at its feet. with the once forbiding icon of fear and endless power, the citadel, now a decaying shadow of its former self dead centre with Dr kleiners voice echoing out with messages of hope. It was instrumented so the player would see all this and appreciate what it was trying to say. That is a work of art.
The thing I learnt from just that one scene is two-fold:

I knew design was intense, for want of a better word, but that really brought me to a new level of what it involves. Ok, it didn't cover every avenue of design but it opened a door for me and understand a little more which can be brought onto other aspects. Many of you may be looking at that and thinking 'well yea, thats stating the obvious. Of course thats the level that design involves'. Well lets not forget- I'm using this to look back on and lets me place the ideas and theories I have learnt for later review.

The other thing I learnt is if people understood how much goes into one little thing like this they will begin to appreciate games beyond the button mashing. Thats why I like the commentary nodes that Valve do.



The thing I brought up with my mother on the dog walk was the fact, ok this may be a leap, that epic game sagas are a culmination of so many, if not all, forms of art. She did agree, by the way.

As far as Nanostem platform is going- well I have full collision detection, a basic form of troop movement and the foundations of a relatively sophisticated C-like scripting languages (parser within the engine- I know, not the most speedy way of reading scripts). My next plan is to get a decent level of control over the CellScript language and get the rest of the team to start with content building- thats long over due [smile]

Anyway, just 2 weeks worth of thoughts and about 2 months of development spat out into one Journal.

Hopefully see you soon back here

/Charlie

MotionCoil

MotionCoil

 

NanoStem Migration Update

NanoStem Migration Update


As I said previously, I initiated a group decision to migrate all the old OpenGL code to DirectX.

Well, for the past 3 days I have been very busy rewriting pretty much everything and I'm still not there.
Basically, I had the implementation in my head but inorder to do it with DirectX I had to rewrite the main base of the engine. Once I had my fundementals in place (DirectX Graphics Manager, Vertex Buffer Manager, Texture Manager etc) I could start rewriting the next level of the engine.

Now, with all my projects I always like to have some form of interaction with the inside of the engine as the first step (I find its easier that way). So I always implement a console system- its invaluable in the early build/debug stages of the engine.
However, my old console class was a bit clumsy and bloated so I decided to write afresh, infact I decided to go a little deeper and make the console class out of objects of the UI I am going to work on soon. So I wrote some fundemental bare-bone UI classes, like CUIPanel and CUIImage, and used them to construct the console. Whereas before, I had constructed the console out of its own bits and bobs- this way I feel it is more integrated.

I have also looked at all the old classes and made them far more OO and writing them so they can easily be plugged into other classes without much hassle.

I have also started writing up official reference documentation, which makes me happy. Along with that, I spent 45 minutes doing a new logo- I'm really pleased with it since it is more clean and professional looking.

Anyway, heres the first blinking cursor of the Console:



I have actually really enjoyed the migration so far. It went off to a bumpy start but I have got a vision to follow now [smile]

/Charlie

MotionCoil

MotionCoil

 

Map editors are a bitch. Unreal Inspiration at han

Ok, i have got the most basic element you can work with being a face, like a standard polygon. This made my simple editor a bitch to use and quite frankly impossible to make anything.

I loaded up UnrealEd to see if that could inspire me as to how to make editing a bit simpler.
It seems that UnrealEd allows you to add a simple polygon but also a cube and things which means I was onto the right idea before. The only thing that is different as far as cubes are concerned with my old build of ZnO/S Ed and UnrealEd is that you are able to control the vertices. Since I have already got a system in place for loading up individual verticies I have no probs with that; just means changing the map format. Also I have in place a system for just putting in bog standard 1D polygons so I have 2 primitives already in place.

I also plan to bring all the views into one viewport so I have:

_______
| t | f |
|___|___|
| s | 3d|
|___|___|


but I am not totally sure If I will have a 3D view.
However, I will slowly bring this feature in when I have time- at the moment, the mechanics of the editor are far more important.

Also, I have to have a proper look at the map format. At the moment I don't think I still have enough power and flexability. This is the most important aspect of the whole editor.
What I'm going for is quite an iso-pers 3D platform style world. Thats it in a nutshell, however its slightly more complex than that and the game I intend to have at the end is not cute or cuddley but for adults. As far as mechanics are concerned, the levels are going to be, as stated, iso-pers platform but with full Y axis camera control (Otherwise I would do an Isometric engine. Although I did try that at one stage and found it impossible to do collision detections. Got very confused[smile]).
I have what I want in mind but its just a case of translating that to a map format and a map format I can actually write an editor for.
So thats two concerns I have to deal with in the context of the map format.

Sorry, this is a bit of a random update but I am trying to keep a history on how I did this editor for my own future reference. Also a current reference.

Honestly, I'm going to have to start writing down plans for my applications since I'm getting myself into a total muddle here.

Over and Out

MotionCoil

MotionCoil

 

GUI Editor

Just done a bit more to my GUI Editor for my engine.

Heres a screenie if you're interested. Ignore the broken graphics; I havn't got around to fixing that since I have been concentrating on the mechanics of the editor.

Currently you can:
-Load up previously created windows from SWD (Stak Window Descriptor) resource files for editing
-Save your current window to an SWD resource file
-drag labels around using the cursor by selecting their 'pin' (little green things)
-Drag buttons around by just dragging the button widget
-Move/Transform the window using the cursor
-Change all the captions using the console (havn't yet got a GUI for the GUI Editor per se, just the standard sys.Stak console)
-Use most of the other console commands that are used with the GUI
-Add new labels (through console)
-Add new buttons (through console)
-Remove labels (through console)
-Remove buttons (through console)


Todo:
-I will add a GUI (other than the console) once I have a complete GUI system setup
-I will add the feature of linking script events to buttons clicks once I have a stable scripting language sorted out
-Make more widgets! (Edit boxes, memos, lists etc.)

Screenie:



[EDIT:
Just incase you were wondering how the windows look without broken graphics (This is from in the engine not the editor):



Not quite as bad :)
/EDIT]
Over and out, mofos

-kYm

MotionCoil

MotionCoil

 

I have seen the (Basic) Light!

Hey, hope everyones good

I havn't updated in a bit since I have had quite a bit on but I have been scoping out other peoples journals and been keeping an eye on the journals I have become a regular to [smile]

Anyway, I have decided not to go into advanced lighting quite yet. I got basic lighting up and working (not that amazingly) but it still gives the illusion of depth to the level.
I am going to get back to lighting at a later date, its good enough for me at the moment [smile]. I am actually working out what aspect of The Engine I want to go onto next.

I am eager to start making content for game the engine is being built for. My gf and I have already started planning the content which is always a good start. So my next effort will probably be content, so that includes all the basics of character movement and things. Just get a basic interactive system working (Then get back to the lights [smile])

Oh, heres a quick shot of the test level in the world view of the editor:



Over and out

MotionCoil

MotionCoil

 

The 6 legged donkey from jupitar...

Hey all

That title got your attention [smile]

I'm feeling alot better since my last entry. The flu-esque virus I had has subsided somewhat. If i don't take any medicine I do feel like hammered shit though.

I've been doing a bit more to my GUI Editor. Just got a few more things sorted out in my head as far as the mechanics of the tool are concerned and also been thinking ahead a bit :0!
I have been thinking how my GUI will interface with my engine in the most efficient and easy way. What I have decided (i'm not sure if this is the norm for engines) to have events (bit like windows) and with those events, eg OnClick for buttons, I have a script file and function within a script file linked to that button. When the button is clicked, the GUI pushes the function onto the engines 'script stack' which means that events script will be processes first (kinda reverse to a message queue). How I figure it, GUI events take priority over other aspects of the engine. I'm sure this view will change the further I develop sys.Stak, but thats my view at the moment.
This way I can have the whole GUI events driver completely modular to the engine so I can edit it outside of the engine.

My overall aim, as you may have noticed, is to make my engine as modular as possible and have the main driving unit of the engine as bare-bones as is can be.
This way, I have far more control to develop outside of the engine.

As far as programming is concerned, i've started on my Edit Box widget. I have always dreaded this and, I now know, with reason. Label, window, icon and button widgets are so easy since they don't require their own input method or removal of text to only display a section within the widgets area. I know how I'm gonna do it, its just gonna be really laborious to implement. The GDNet lounge has not helped me the past few days since I find myself frequenting there when I have intentions to do more to my GUI Editor. Madness.

In other news, i now have a really nice new small T-Shirt from Cyberdog.
My camera has run out of batteries so heres a description:
As with everything from Cyberdog, it is a cool club scene t-shirt with circuit pattern all over it on black material.The circuit pattern is dull gray until you shine direct light on it, at which point it shines up. Its really nice!

I also have quite a decision infront of me-
spend some of this months wage on a Geforce 6600LE from XFX (~200) or a new camera (~280).
Cannot for the life of me make up my mind...!

anyway,
over and out

-kYm

MotionCoil

MotionCoil

 

Lights Updated

Hey

Just a quick update. I was a bit disillusioned in my last post about the lights mainly because they were just not working correctly. I just fixed it and it was too simple. I just had to note this down incase it helps with other people and also to act as a reminder for me to actually read the code I have written.

The thing is, my maps are scaled down defined by a scalar value in the map format (I know, its not a good idea to use scaling but I find it easier). Anyway, having read NBs about normals having to be one unit long otherwise lighting screws up I remembered to add glEnable(GL_NORMALIZE) (The one that requires more computing). This makes sure that the normals are 1 Unit, no matter what. So I did that but the lighting was still mucked up and looked like a normal bulb light over a model village (So the normals were still the same size- See screen shot in previous post- that was diffused on .2 ...no chance that it should illuminate to that level). Anyway, I was looking through the code and couldn't find anything that was wrong.

I left it a day or so. Then I read through the information in 'The Red Book' and scoped out something that might be the root of my problems- the lighting is calculated using the model view matrix. Whats that at the top of rendering each singular entity of geometry? glPushMatrix(). The thing is I was pushing/popping a new model matrix everytime I rendered a primitive but my ModelLighting(int LightType); function was well before I Pushed the matrix which means the lighting was being based on a non-scaled model view matrix and that meant no matter what the lighting would be screwed.

Hazzah! another problem solved.

Lesson of the day- Always read your code and keep track of the times you push/pop matricies.


[Disclaimer- Do not comment on my bad over complex programming style [smile]]

Now I have a whole load of cycles wasted on iterating through the list of lighting in my level every time I render a single primitive. Major optimizing is required! I say again- Major optimizing is required!

[wink]

Anyway, thats how not to program [smile]

Catch you later, dudes

MotionCoil

MotionCoil

 

Behold the glass

Hey all

I have been working on another feature on my editor.
I didn't quite finish off all the control over the texture coords yesterday so I finished it off and integrated it fully into the editor. I also added the feature to set transparency on polygons which is always good for glass and stuff.

So now I have full control over:

+ Change the texture image
+ Change the U/V coords of the texture by increments specified by you in the editor
+ Flip the texture on the horizontal axis
+ Flip the texture on the vertical axis (Heres were Lazyfox (my gf)helped work out the coord changes for me while I did other things. Shes becoming really useful [wink])
+ Increase/Decrease opacity of texture


I have yet to sort it so you can scroll the texture along on the either u or v axis.



Anyway, heres a quick screenshot of it all in action (sorry about the abundance of 'Orange' texture [smile]):
(Note: All textures used are single 256x256 textures- the tiled walls are from the coord changes)



As you can see, I have started to slowly texture up the level so its beginning to actually look like a level rather than a building site of coloured plywood.

Next to do-

+ Fiddle around with the texture controls a bit more
+ Add a lighting model (Still gotta read up lightmaps- I feel these will be a better idea than dynamic lighting)
+ Go clubbing in SlimeLight in London


Over and out y'all

MotionCoil

MotionCoil

 

Migration

Migration


Hey all

After about 1 month of development and having sorted out quite a few of the native formats for the engine we had a team discussion, initiated by yours truely, and we have come to an agreement that I will migrate all the current code over to DirectX. We came to this dicision for a number of reasons, including the intuitive structure of modern day DirectX. Thankfully it is only a months work and most of that has been a load of fiddling rather than anything too new.

So anyway, you probably won't see a huge amount of updates for the next week or so as I migrate the current progress over to the DirectX platform.

I'll tell you how easily or how sketchy the migration was when its done.

It may sound like an unprofessional decision to change platforms but this is our first project so the beginnings are bound to be a bit wooo bit waaaay [wink]

Anyway, I hope I will be more comfortable working with DirectX- will have to get my head round it again :)

take it easy

/Charlie

MotionCoil

MotionCoil

 

Quick ZnO/S Update

Hi de hi all!

just a quick update on my editor.
I now have control over how the textures are presented on primitives. It took me about 3 hours to change the map format to enable me to change the coords on textures and to implement a feature to flip textures, change their coords ect.

So yet another feature is added.

I would like to add that my girlfriend (codename: Lazyfox) quickly sorted out some of the texture coords that were going wrong. So thanks LAZYFOX!!!!
[EDIT]
I would like to point out that no she can't program, it was just easier to quickly draw a diagram and have her work out the coords while i worked on another aspect of the editor. But I would like to teach her how to program one day [smile]. I got her onto computer games and by god that was a task and a half[wink]
[/EDIT]

I would also add that she won a game on unreal tournament (for the first time)... in the words of 'Purepwnage.com'- she has uber-micro.
(Albeit on novice [wink])

over and out!

MotionCoil

MotionCoil

 

My Editor finally makes a bid for freedom (of the

Hey all

Well, I'm quite pleased with my editor so far [smile]. The mechanics have not been improved yet but I have got a world camera working now so I can actually look around the levels I create from within the editor.

I had quite a bit of trouble with the camera system until I asked a question in the forums and the answer was embarrassingly easy and something I had already tried but didn't seem to work previously. Anyway, thanks JavaCoolDude for you help [smile].

So now I can show you the top down view of E1L1:


and a look in the level (with the default texture):


I am quite pleased with the progress so far.

Next thing to do, all for texture on each surface of the primitive. As I said before- I already have the flexability for that in the map format and the renderer but its just a matter of implementing a method to change it within the editor.
I also need to look into full control over texture mapping. Time to dig my teeth into the infamous 'Red Book'(!).

I'll keep y'all posted!

MotionCoil

MotionCoil

 

Steam Drive

Steam drive is making slow but steady progress. At the moment I am making a small multi-format model viewer as a tool for the main engine. This tool is allowing me to write all the basic engine routines like the console, model loading etc. in a small easy program. This will make it easier to write aspects of the engine without getting bogged down in the rest of the code.
Its just my way of learning...start small.

The model viewer is coming along well. I'm currently writing the logic for the console.

MotionCoil

MotionCoil

 

Design Tip #476: Make sure every team member is designing the same game

Design Tip #476: Make sure every team member is designing the same game

In answer to the query I received from Mushu on my last entry:

Its not that bad migrating code since there is only about a months worth of development in the engine. It may seem quite a bit but most of it is tweaks an things. Having said that, there has been alot of converting.
How I started out the migration initially, or rather what I had in mind, was just to change all the OpenGL specific code to DirectX. In reality many factors arose, like a slightly different process to actually rendering items and the whole 'wow, the engine so far could be a hell of alot better in structure' thing.
So the migration was, like I said, initially rewrite the classes to directX which meant basically rewriting the base classes of the graphics engine, which did get a bit 'icky' since the base required enough of a change in structure to be a pain in the arse. From there, most of my previous code could be plugged in- in theory- however, I took this as an opportunity to clean up the more 'complex' (read- sloppy [smile]) code I had written before. So yea, in short, the first stages were icky but from there I could just plug in all my old code with a change here and there.


As far as our game design has progressed (Yea, I havn't touched on that before since it has been a real mess) We have finally got a back story in place and the sides you play integrated into the story.

Its been quite fun, but a bit tenuous at times, designing this game. I'm doing it with 3 of my college mates and my gf.
It started with an idea of having an epic RTS in the same manner as the legendary TA but since then it has... evolved.

We have finally sorted out our main objectives. They are quite high but plausible:

8 multiplayer gaming at maximum
No single player
Full mode: long play times (4+ hours)
Lite mode: short play times (2 hours maximum)
Ability to save sessions to resume play later
2 tactical play areas- Surface and inter-planetary
3 different sides to pick: The Humanitarians, The Corperations and The Cult
Gorgeous shader effects!!!111!1!


Well, thats our engine/game objectives. The network code will be hell [wink]
The full mode is basically for the people among us who enjoy long thought out tactical play but always found skirmishes to finish too quickly. The lite mode is for the quick destruction of thine enemy.

Thats all i'm going to say as far as design is concerned. We have got alot further with the design, like the nitty gritty balanced play, we have designed the factions you play and we have a vivid vision to follow. But if I go into all that, its going to bog down this post more than it already has been [grin]

/Charlie

MotionCoil

MotionCoil

 

I'm back (not that you noticed I'd gone)

Hey all

The Story So Far...
God, its been a long...long time since I put anything into my journal.
I've been quite busy just getting stuff for college sorted out in the past few months and havn't really had the time and/or motivation to work with my game engine.

However, i've had my first few weeks at college for the foundation year before uni-proper and I'm really enjoying it (granted, i'm wishing I had actually turned up to my last year of A-Levels a bit more since I would be AT uni by now if I had). That aside I have a good bunch of mates at college now and will try and keep them as mates since we are all going into Halls of Residence next year at Sussex Uni.

Engine
Now I'm finally settled I'm getting back into programming and into my game engine.
I think the reason for me not working on the engine is because I have come to the ever fun obstacle of collision detection. I'm diving and taking no prisoners; I will get my characters bouncing off the walls (...in a good way).
After that I plan on getting the lighting a bit better and starting on a basic scripting language. again. Also I have in my mind to refine the map format a bit and add more flexability.

In Other News
An e-mail caught my eye today and guess what...? I love the new look to gamespot; everything is just a few clicks away. They have made it look far more professional and the integrated player looks sweet. A bit better than Windows Media Player style buttons. Fresh Tuesday is quite informative for a quick overview of the latest happenings of out mad-cap industry.

On the downside are Gregg Kasavin's awful sarcasm/quips/jokes on the redesign overview video. Have rotten tomatoes at the ready[wink]

I also got 'My First Car'- its a Ford KA that came with an OldSkool tape deck for a sound system. Blink and you'd miss how quickly i replaced that a Kenwood CD/MP3 player and Fusion Sub and Amp. I can pretty much roll my car from the vibrations.

Anyway,

peace out y'all

-Charlie

MotionCoil

MotionCoil

 

New Map format...new editor...1 days work

Hey all

been a while since I last posted on here.

Since I have, I decided to scrap Quake 3 BSPs in favour of my own map format.
I feel this was a good decision since I now have far more control on the way the map looks and works. It also means I can add and remove different things from the file.

Once I had the basic map format sorted out and a renderer written for it I decided to write an editor. Keep in mind the map format is VERY basic at the moment and only supports cubes but does support multi-texturing and stuff. However it does have the ability to expand to allowing just about everything. Also the editor is very simple as well- it kinda reminds me of the good old days of doom map editing. At the moment it works on one viewport by 3 views- top/front/side. You just scroll round them. You have full control over the cubes but at the moment they are controlled by the keyboard and as of yet has no ability to assign textures. You add primitives through console commands. Having said that, not bad for one days work [smile].

heres the editor in 'Edit' mode:


And heres a shot of the editor in 'World Preview' mode (With engines default texture):


Anyway, I am going to continue with this full on in my spare time. I am much happier now I have my own custom map format.

MotionCoil

MotionCoil

 

And so the world is that bit more colourful...

hey GD'ers

I had about 4 hours yesterday before I went out (hence the fact I left it till now to update) to go uber hardcore on my map editor. I managed to get one of my To-Dos done! I implemented a suface texturing function- basically you can edit the texture on the individual surfaces of the cube. Sorry, the following is a bit tedious but its really for my future reference [wink]

I have been thinking for a while how to implement a system to easily (or as easily as one can get for their first editor) texture the individual faces of the primitives. After writing down many different ideas I decided on what I feel was the simplest concept- to have a property window. Nothing to fancy- just a window that allows for keyboard input. Well, that was the first design until I decided to have as a multi-paged panel. This allows for catagories of properties- Polygon properties, Vertex properties and Texture properties. The joy of this concept is the ease of which to add new properties or catagories.
When you see the property window you may note it is very similar to the console; it is essentially a copy of my console code but modified for this purpose.

Anyway, I'm really proud of the following [smile]-

Here is your overall polygon property panel. At the moment it has nothing you can edit:


Over here, you have the vertex property panel. The vertex highlighted in red is the currently selected vertex in the world and the one highlighted in green is the one selected in the menu. You edit the 3 values using the 'SET:' command line:


And finally the whole point of the property window (The other bits were afterthoughts)- the face texture editor. Basically you scroll through the different faces of the polygon and then you can scroll through the 'texture pool' to select the texture you want on that face. The texture pool is the list of textures that the map uses that you load at 'edit-time' (to coin a phrase [smile]):


Heres the world view to show off a bit of multi-texturing within the world rendering [EDIT: I have fiddled around (Read: Followed a tutorial) with photoshop to create a slightly better texture, so heres the new one[smile]]:


And last but definitely not least is a quick view of the world in wireframe to show a bit of the basic geology my editor is capable of creating:


Sorry, quite a bit of the same thing as my other posts but I really wanted to update with my face texture editing [smile]

Anyway, its coming on ok. You may notice that the textures are mapped really crapply at the moment...this leads me onto the next section (Again, mainly for my benefit[smile])-

ToDo:
-Have more control on texture mapping (type of mapping, scewing, coords etc)
-Setup a multiple view port for the editor mode so you can see different views all at once.
-Get started on a lighting model (Lightmapping?)
-Drink Pimms

Over and out

MotionCoil

MotionCoil

 

My First Level!

Hey all!

I got to the point with my editor that I can actually make basic levels. You have no idea what kinda buzz i'm feeling right now [smile]
Anyway, yea, so they are basic levels and the editor doesn't have the ability to add textures to the different faces of primitives quite yet- basically I'm only showing you the top view of the editor mode. If I showed you the world mode, all you would see is the default orange texture my engine uses for untextured faces.

Anyway, here is my E1L0 level (random name, nothing to do with iD softwares stuff [wink]) [smile]- it is floored and walled but no ceiling since my engine has no need for ceilings:


MotionCoil

MotionCoil

 

Forgot that I had a journal feature

Dunno how people but I forgot that GDN+ has a journal/blog feature (even though I have already added one entry).

Anyway, sys.Stak engine is coming along nicely- just started on the GUI after hacking around the problem with falling through or 'ghosting' through the floors of Q3BSP maps (I did it without a FPS limiter). So now I can concentrate on the interface which is what i'm doing now.

I have decided to take the bog standard approach to the interface with a main interface object and all widgets derive from this object. I have the CStakInterface as the base class for all derived objects, then I have CUIWindow, CUIButton etc.
So I have it all sorted programmatically but what happens when I come to properly implementing an interface with multiple drag/drop windows etc? Only time and hacking around will show results.

Yea, I enjoy hacking around my code. Its cos i'm lazy ;)

Have a good one,

-Kym

MotionCoil

MotionCoil

 

starting a well worn path again. Wish me luck

hey
Long time no update again.

Well, thanks to all those who have helped me with collision detection. I have used that information in conjunction with some good tutorials and realised that my current LD map format is crap and is too mangled to actually perform collision detection happily and successfully.

Taking that into account I am about to venture on a journey but this journey has already been done before. I'm rewriting HUGE amounts of my level format (thats quite a few months of work) and try and make it neat as possible. My idea is to integrate the level class around a tutorial I have read. I understand the theory behind collision detection but my level format is stored in such an obfuscated way that its almost impossible to do vaguely complex maths on it.

I may even go so far as to scrap the current format and start anew.

I can almost feel the fresh air sweeping over the age old cobwebs of my code [smile].

Well, here I go- starting some calm DJ Shadow and starting up Visual Studio...Wish me luck.

MoCo

MotionCoil

MotionCoil

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!